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

[John C Klensin]

--On Tuesday, October 13, 2009 23:01 -0400 Margaret Wasserman
<mrw at sandstorm.net> wrote:

> Hi Vint,
>> 
>> Use the Punycode decoding step to convert to U-label, if this
>> fails,   it isn't valid Punycode
> 
> Would it make sense to say this in the idnabis-protocol spec?
> I don't   think it is necessary
> to explain how to decode Punycode, but a statement that
> indicates that   this is the method
> that registries should use to detect "Fake A-Labels" would be
> good to   include, IMO.

Margaret,

This is a sort of odd situation for which there are no ideal
solutions.  With the understanding that I'm speaking mostly
personally, a little bit as editor, and not at all for the WG
right now...

One problem is that the WG was faced with a lot of tradeoffs
between the "one big, comprehensive document" and "several
smaller documents, broken up by functions" strategies and
intersecting issues about how, or whether, to supply tutorial,
rationale, and explanatory material.  Where we ended up is with
one of those "just about everyone is equally unhappy"
situations, not some hypothetical ideal solution.  The
relationships are explained in draft-ietf-idnabis-defs (referred
to as "Defs" below and elsewhere); the other documents are
pretty much impossible to read correctly without understanding
that one. 

Nonetheless, a lot of work went into making sure that there are
cross-references or, when needed, copies of material to make
things clear.  Could more be added to make it easier to enter
the documents at any point?  Absolutely.  Would that increase
the risks of inconsistency and/or clutter that would actually
obscure meaning?  Also yes.   Have we found the right balance
point?  I certainly no longer know and I'm not sure I ever
thought I did.

In that context, the answer to "would it make sense to say this
in the XYZ document" is almost certainly "yes, but let's be sure
we aren't on a slippery slope.

The second problem is that it has been our tendency to write
protocol specifications (or things like them -- as you or
someone else pointed out, since most of IDNA does not go over
the wire, it really isn't one), especially in the applications
area, so as to specify correct behavior and just treat
everything else as unspecified and non-conforming rather than
trying to define the tests for the failure cases.   Most of the
terminology categories in Defs are there for purely explanatory
purposes: we tried, several times and in different ways, to
simply talk about the two types of labels that IDNA actually
deals with ("A-labels" and "U-labels") and discovered that we
kept tying ourselves in knots over states of validity and
validation.  So we ended up with all of those categories and the
figures because they were the least bad solution (and still not
a perfect one) for clarity of description.

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.

If you can figure out a better way to say that and where, I'm
certain open to advice and assume the WG would be too.

>>> This document does not contain a material Security
>>> Considerations   section, instead
>>> referring to the Security Considerations sections of other  
>>> documents.  However, it
>>> doesn't appear to me that those Security Considerations
>>> sections   completely cover the
>>> security topics related to a registry that accepts IDNA  
>>> registrations.  For instance,
>>> should a registry consider rejecting registrations for
>>> domain names   that contain
>>> mutliple scripts?  Is there anything that registries need to
>>> do (or   even can do)
>>> to (help their customers) avoid the problems described in
>>> section   4.3 of idnabis-defs draft?
>> 
>> 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.

What Rationale says in that regard is limited because the WG
could not reach consensus on stronger recommendations (or
whether stronger recommendations were even within scope, since
they are mostly a policy matter.

> The idnabis-protocol Security Considerations section does not
> cite the   Rationale
> document.  Should it?  Is there a particular section that
> contains   this advice?

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.

    john