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

[Frank Ellermann]

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, 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"?

> 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.

OTOH it would be simple to compare say _cocacola and _whatever, or
-cocacola and -whatever.  If you want that you could replace the
convoluted "not NR-LDH label" by a simpler "non-ASCII label".

-Frank