IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec

[John C Klensin]

--On Friday, September 30, 2011 17:47 -0400 Andrew Sullivan
<ajs at anvilwalrusden.com> wrote:

> On Fri, Sep 30, 2011 at 11:27:17PM +0200, Frank Ellermann
> wrote:
> 
>> AFAICT they are not invalid outside of IDNA.  The RFCs
>> defining host names / HTTP / URLs are not updated by IDNA.
>> For *all* LDH labels, if you are *not* interested to find
>> U-labels for A-labels, simply do not put them into any IDNA
>> processing, because the result will not be what you want in
>> certain corner cases.
> 
> Any LDH-label that is a putative A-label but that is not
> actually an A-label is still a valid label in DNS (and even
> valid under the LDH rules).  That's part of the design of
> IDNA.  

Yes, with the qualification that, if one has an
IDNA2008-conformant application, if it has "--" as the third and
forth characters and isn't an A-label, it is bogus.

> Non-LDH labels could be valid DNS labels, too, of course.
> Strictly speaking, you can put "can't" into the DNS and it
> will work.  Whether any of your software will spit up on it is
> quite another question.

And that is where things become interesting because, as far as
IDNA is concerned, "can't" is a perfactly valid DNS label.
Since it isn't an IDN nor something resembling an A-label, IDNA
just doesn't care about it.  On the other hand, "çan't" is
bogus because it contains non-ASCII characters and isn't a
U-label.

As Andrew, Patrik, and I have been discussing in a completely
unrelated thread, this kind of difficulty is the very good
reason for not attempting to summarize the precise definitions.
 
> There is actually a perfectly good test of what a valid
> A-label is in the IDNA2008 documents, and it seems to me that
> rather than providing partial advice one ought to just point
> over there, no?

Yes, definitely.  See above.
   john