IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec
John C Klensin
klensin at jck.com
Sat Oct 1 03:49:26 CEST 2011
--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
>> 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
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
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.
More information about the Idna-update