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

Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkztdjz at
Fri Sep 30 23:27:17 CEST 2011

On 30 September 2011 21:43, =JeffH wrote:

>>> a pointer in the direction of "implementations supporting
>>> IDNA2003 instead of IDNA2008 use the corresponding IDNA2003
>>> 'ToAscii' conversion as specified in RFC 3490" in some
>>> BCP 18 "i18n considerations"?

>> I agree that text such at that is appropriate, but I think that's
>> what Jeff (and Adam) are trying to formulate.

> that is our intent, and essentially what the draft language says,
> IMV.

Sorry, that wasn't my impression, I read "do IDNA2008 or IDNA2003",
not "do IDNA as specified in 5xxx", with the IDNA2003 blurb hidden
in "i18n considerations".  I did not know that some folks consider
IDNA2008 as controversial.  [User's POV:  I don't like to see any
U-labels in scripts I can't read, and as long as I can't configure
which scripts I can read I consider all U-labels as "insecure", but
that doesn't depend on the IDNA version.]

   [xn--cocacola and na--whatever]
>>> These are perfectly valid LDH labels in DNS *host* names outside
>>> of IDNA.

>>> What do you plan to do in these cases, throw an exception, maybe?

> If you read closely, the actual idna-canonicalization will be done
> by prior portions of "the pipeline", and presuming they implement
> IDNA2008, then yes, they'd not "process" those above labels because
> they are invalid.

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.

Otherwise, if you want to find U-labels, take only XN-labels as input
for IDNA processing, because anything else cannot be a valid A-label.

> I just jammed xn--cocacola into the Firefox address bar and got an
> interesting result: "ః௾అఅ௿௾" which may or may not be a valid
> IDNA2003 U-label (to coin a term).

Apologies, I never really tested it:  xn--cocacola used to be a kind
of joke on this list years ago (wrt legal copyright problems, not to
security issues).

Apparently <>
is down at the moment... :-(

Looking at my mail with suggested idnatest subdomains the Gmail UI
as displayed by Chrome shows a difference for two of the test URLs:  \/ "http://" not shown as     /\ part of the wannabe-link  \/ "http://" shown as     /\ part of the wannabe-link


More information about the Idna-update mailing list