[OPS-DIR] Review of draft-ietf-idnabis-protocol-16.txt

[Margaret Wasserman]

Hi John,

On Oct 14, 2009, at 12:46 AM, John C Klensin wrote:
>
> But, independent of explanatory quality and coming back to your
> question, a registry shouldn't be doing anything specific to
> 'detect "Fake-A-Labels"'.  It should be performing the
> validation and processing steps described in the specification.
> Those steps will either yield one of:
>
> 	* A traditional, ASCII, LDH-label with no prefix
> 	* A U-label
> 	* An A-label
>
> or whatever the registry is looking at is bogus (or "outside the
> specification", if you prefer).  Categories of bogusness
> (bogosity?) don't help much (or at all) operationally, no matter
> how useful they may be descriptively.

Vint indicated that FAKE A-labels can be detected by running
a Punycode decoding step to convert to a U-label.  If it fails,
then the A-label is FAKE.  That seems fairly clear.  I am not sure
that any of the documents actually state that one can use that
procedure to detect a FAKE A-label, although it may be implied
by the definition of a FAKE A-label.

However, section 4.2.1 of the idnabis-protocol document starts
with:

"If only an A-label was provided and the conversion to a U-label
is not performed,..."

and then goes on to say:

"FAKE A-labels, i.e., invalid strings that appear to be
A-labels but are not, MUST NOT be placed in DNS zones that
support IDNA."

Which seems incompatible, given that the only way we know
to detect a FAKE A-label is to perform the conversion to a
U-label.

I think there are two reasonable choices for how to fix this:

1) Remove the MUST NOT, and only require registries to
detect the cases that are specifically mentioned (trailing
hyphen-minus or non basic characters before the delimiter,
etc.).  I'd select this case if there is some reason why we
do not want to require registries to perform the conversion
to a U-label before registering IDNs.  Is there?

2) Leave the MUST NOT in the document, and say that
registries should perform the conversion to a U-label
and refuse the registration if it fails.  This seems like the
best choice, in the sense that it will result in registration of
fewer FAKE A-labels.  Is there some reason why we do
not want to require registries to perform this step?

I am not sure I care which of these options is chosen, but
the way it is now seems inconsistent.

>>> See Rationale for the best advice currently available.
>
> While I agree with Vint's answer above, there is another
> slippery slope problem that is a little bit like the IETF's
> giving people advice about how to construct user interfaces.
> The main reason for not doing that isn't that we are
> collectively incompetent in the area (although that claim has
> certainly been made and may be true) but because those who
> design UIs are fairly unlikely to pay any attention to us unless
> whatever we say agrees with whatever they've figured out on
> their own.
>
> Ultimately a registry has to make decisions about tradeoffs
> between functionality and safety.  One that wants to maximize
> safety, even if it means excluding functionality entirely will
> not get involved with IDNs at all -- there are just too many
> things that can go wrong, many of them just as a consequence of
> increasing the effective character repertoire from 37 to several
> tens of thousands.  Such a safety-maximizing registry would also
> prohibit the digits 1 and 0 in labels to avoid confusion with
> the letters "l" and "0", might prohibit labels with "r" and "n"
> next to each other (easily confused with "m" in some fonts and
> sufficiently small type), and so on.  Probably no one is going
> to go that far (nor would I personally recommend it), but
> everyone else is making tradeoffs and policy decisions.

IMO, the Security Considerations section should outline these
trade-offs (or reference documents that outline them), so that
a registry can make an informed choice about what point they
want to occupy on the functionality vs. safety curve.  Currently,
the document does not include this information, either
internally or by reference.

> Most of what Rationale has to say on the subject is in Section
> 3.2 (which is referenced from Section 4.3 of Protocol).  Some of
> the choices about the breakdown of the material into separate
> documents led to instructions from the WG to me to avoid
> normative references to Rationale and that is why there is no
> pointer from the rather brief Security Considerations of
> Protocol to it.   But, if you think it would be helpful, adding
> a sentence there that pointed back to either Protocol Section
> 4.3 or to Rationale, or both, for discussions of registry and
> permitted string policies for registries, that is certainly
> easily done.

I think that would be desirable.  I am not aware of any
rule that requires references from Security Considerations
sections to be normative.

Margaret