LDH-label terminology

[John C Klensin]

--On Saturday, 26 July, 2008 01:21 +0200 Frank Ellermann
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com> wrote:

> John C Klensin wrote:
> 
>> I sent a note off earlier today whose purpose is to dump much
>> of this terminology stuff (and the 1123 clarification and
>> related issues) onto the DNS experts and/or WG(s) or at least
>> get them to work with us on it.  Don't know if that will be
>> successful, but I'm  going to feel better for having tried.
> 
> Good, if they don't answer -- busy to fix DNS worldwide -- we
> can take this as carte blanche to define the minimum we need
> for IDNAbis and to introduce "real" IDN TLDs as it pleases us.

yes. But, for several reasons, I do expect some sort of answer.
And it doesn't quite work that way -- under IETF rules, although
not common courtesy, they could refuse to play at this stage and
then tie things in knots because they didn't like out solution.

> In another article you mentioned RFC 2673 for the difference
> between "binary" and "octets".  IMHO we can ignore RFC 2673
> for IDN.  The SPF folks also ignored it for RFC 4408 back in
> 2005.  You could mention that in theory any octets goes (in
> prose) somewhere.  That is relevant if folks try to use UTF-8
> U-labels directly without first converting them to A-labels.

I'd rather avoid as much of that as possible, probably for the
same reason SPF did.  I was just trying to clarify Eric's
taxonomy picture a bit so we were all sure we were talking about
the same thing.

Even the UTF-8 bit doesn't seem to me to be something we need to
discuss.  There are many ways to violate any protocol, this
among them.  I don't think we need to catalog the violations (or
bypass attempts).  A UTF-8 string in the DNS presumably would
not start with "xn--" and could not be a conforming A-label in
any case, so we don't care (the protocols that _do_ enforce
LDH-compliance would deal with such strings in their own way.

> Of course using UTF-8 U-labels directly will fail, but if it
> *happens* to be a valid octet label the corresponding domain
> could be controlled by the bad guys => security consideration.
> 
> Apart from that facet octet labels are irrelevant for IDNAbis;
> and we can focus on "LDH" vs. "A" in some ways.  Without the
> z-label business mentioned by Eric.  And without SRV-labels -
> or is there something about IDNA and SRV I've never heard of ?

The fact that one can't have the protocol part(s) of an SRV FQDN
be IDNs will, I suspect, come back to generate complaints at
some point.  I think "you can't do that" is worth saying
explicitly just to head off the rather complicated an
hard-to-diagnose errors that might result from someone trying to
encode a string starting with an underscore and followed by some
non-ASCII characters and expecting that to work (which it might,
depending on how an application that retrieved SRV records was
coded).

Of course, the fact that "_" is DISALLOWED would be irrelevant
if the application just saw the putative A-label and didn't make
explicit checks on it, just decoded the thing to a Unicode
string and only then looked for the leading underscore.  So I
think it is worth mentioning, even if not worth spending much
energy one.

     john