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

Peter Saint-Andre stpeter at
Fri Sep 30 20:58:56 CEST 2011

On 9/30/11 12:42 PM, Frank Ellermann wrote:
> On 30 September 2011 05:07, =JeffH wrote:
>> we are attempting to address the proper way to reference IDNA2008
>> and IDNA2003 in terms of stipulating comparisons of domain names
>> (that may or may not be IDNs).
> Why do you wish to discuss IDNA2003 at all, 

Because it seems that most or all of the browsers implement IDNA2003 but
have no plans to migrate to IDNA2008.

> apart from 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. Naturally, they might have
missed the mark (or I might misunderstand their intent).

>> the guidance we've received is that given the complexities and
>> subtleties of IDNA processing and considerations, our specs
>> really should be more explicit about the foregoing assumption(s)
>> and the downside risks if the requisite validation/testing is
>> not performed.
> Just in case, if comparison of DNS *host* names is all you want,
> and you strictly follow RFC 5890, then you end up with various
> special cases such as xn--cocacola (= fake A-label in RFC 5890)
> or na--whatever (= reserved non XN-label in RFC 5890).  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?
> It could be simpler if you limit your IDNA efforts to "not LDH"
> labels instead of "not NR-LDH" -- that would allow xn--cocacola
> or na--whatever as "good enough for a comparison".
> You talk about *domain* names as in DNS, and that results in some
> special cases such as "underscore labels" (mentioned in RFC 5890)
> or any non-ASCII (binary) label not passing an IDNA U-label test.
> It could be simpler if you limit your DNS efforts to *host* names
> (LDH) and U-labels, IFF anything else is anyway irrelevant for
> your purposes.

I think that underscore labels are out of scope for both the Origin and
HSTS specs.


Peter Saint-Andre

More information about the Idna-update mailing list