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

[=JeffH]

StPete wrote:
 > 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.

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

Frank said:
 >>> 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?

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. With 
IDNA2003, I'm not as sure, 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).


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

Again, that's the decision of the surrounding "environment", which in these 
cases is an HTTP client, and if said client is implementing IDNA2008, then it 
probably can't do that.


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

Actually, the intention of the spec is to limit it to comparison of NR-LDH 
labels and A-labels -- if that isn't clear we'll have to make it more clear. 
The implicit presumption is that various other label types will be filtered out 
and handled by other portions of the processing pipeline. We may need to make 
this more clear and/or add appropriate additional references.

thanks,

=JeffH