Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec

[Pete Resnick <[e-mail]>]

A while back, Jeff Cc'ed me on this message and I promised to give a 
little feedback. I failed. Here is an attempt, just in case it makes a 
difference. Since this was posted so long ago, I'll leave all of his 
text and answer inline. Scroll down to see my comments:

On 12/23/11 12:06 AM, =JeffH wrote:
> PaulH and PeteR raised some concerns in Taipei over the IDNA-related 
> language in  draft-ietf-websec-strict-transport-sec.
>
> This message is a reminder to them and an instigator to others for 
> further review specifically of the IDN aspects of the HSTS spec.
>
> My initial request for review and summation of the pertinent language, 
> as sent to the na-update@ list, is here (and attached below)..
>
>   IDN processing-related security considerations for
>   draft-ietf-websec-strict-transport-sec
>   
> http://www.alvestrand.no/pipermail/idna-update/2011-September/007140.html
>
>
> The above-cited message presaged the -03 HSTS draft, which is 
> presently (for a little while) current, and is here..
>
>   HTTP Strict Transport Security (HSTS)
> <https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-03>
>
>
> Please review and comment. Thanks,
>
> =JeffH
> ------
>
> From: =JeffH <[e-mail]>
> Date: Thu, 29 Sep 2011 20:07:15 -0700
> To: IETF IDNA Update WG <[e-mail]>
> Cc: Pete Resnick <[e-mail]>, [e-mail],
>     Peter Saint-Andre <[e-mail]>, Adam Barth 
> <[e-mail]>
>
> Hi,
>
> In working towards completion of..
>
>    HTTP Strict Transport Security (HSTS)
> <https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec>
>
> ..and..
>
>    The Web Origin Concept
>    https://tools.ietf.org/html/draft-ietf-websec-origin
>
> ..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).
>
> In discussions with our ADs and a few IDNA-literate folks, we've been 
> informed
> that the IDNA-specific language in the recently-released RFC6265 HTTP 
> State
> Management spec isn't quite up to the standards they would like to see 
> at this
> time.
>
> Thus I've performed some surgery on 
> draft-ietf-websec-strict-transport-sec and
> have included below the specific section portions that are IDNA 
> specific (this
> is from my working copy which isn't quite yet overall ready tonight to 
> submit
> as -03).
>
> The key context to keep in mind when reviewing the below is that the key
> "processing" -- essentially a domain name comparison -- will occur 
> deep within
> the bowels of HTTP clients, well along the processing pipeline for 
> URIs, and
> presumably after IDNA-canonicalization and requisite 
> validation/testing has
> occurred. However, 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.
>
> With that context in mind, thoughts on the below are solicited. 
> Apologies for
> just having these excerpts at this time, but I ought to have
> -websec-strict-transport-sec-03 submitted in the next few days at most.
>
> thanks,
>
> =JeffH
>                .
>                .
>                .
> 7.  User Agent Processing Model
>
>     This section describes the HTTP Strict Transport Security processing
>     model for UAs.  There are several facets to the model, enumerated by
>     the following subsections.
>
>     This processing model assumes that the UA implements IDNA2008
>     [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11
>     "Internationalized Domain Names for Applications (IDNA): Dependency
>     and Migration".  It also assumes that all domain names manipulated in
>     this specification's context are already IDNA-canonicalized as
>     outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to
>     the processing specified in this section.
>
>     The above assumptions mean that this processing model also
>     specifically assumes that appropriate IDNA and Unicode validations
>     and character list testing have occured on the domain names, in
>     conjunction with their IDNA-canonicalization, prior to the processing
>     specified in this section.  See the IDNA-specific security
>     considerations in Section 13.2 "Internationalized Domain Names" for
>     rationale and further details.

I think the above is just fine and gives implementers the correct 
instructions.

> 8.  Domain Name IDNA-Canonicalization
>
>     An IDNA-canonicalized domain name is the string generated by the
>     following algorithm, whose input must be a valid Unicode-encoded (in
>     NFC form [Unicode6]) string-serialized domain name:
>
>     1.  Convert the domain name to a sequence of individual domain name
>         label strings.
>
>     2.  When implementing IDNA2008, convert each label that is not a Non-
>         Reserved LDH (NR-LDH) label, to an A-label.  See Section 2.3.2 of
>         [RFC5890] for definitions of the former and latter, refer to
>         Sections 5.3 through 5.5 of [RFC5891] for the conversion
>         algorithm and requisite input validation and character list
>         testing procedures.
>
>         Otherwise, when implementing IDNA2003, convert each label using
>         the "ToASCII" conversion in Section 4 of [RFC3490] (see also the
>         definition of "equivalence of labels" in Section 2 of the latter
>         specification).
>
>     3.  Concatenate the resulting labels, separating each label from the
>         next with (".") a %x2E character.
>
>     See also Section 11 "Internationalized Domain Names for Applications
>     (IDNA): Dependency and Migration" and Section 13.2 "Internationalized
>     Domain Names" of this specification for further details and
>     considerations.

Again, the above is fine.

> 11.  Internationalized Domain Names for Applications (IDNA): Dependency
>       and Migration
>
>     Textual domain names on the modern Internet may contain one or more
>     "internationalized" domain name labels.  Such domain names are
>     referred to as "internationalized domain names" (IDNs).  The
>     specification suites defining IDNs and the protocols for their use
>     are named "Internationalized Domain Names for Applications (IDNA)".
>     At this time, there are two such specification suites: IDNA2008
>     [RFC5890] and its predecessor IDNA2003 [RFC3490].
>
>     IDNA2008 obsoletes IDNA2003, but there are differences between the
>     two specifications, and thus there can be differences in processing
>     (e.g. converting) domain name labels that have been registered under
>     one from those registered under the other.  There will be a
>     transition period of some time during which IDNA2003-based domain
>     name labels will exist in the wild.  User agents SHOULD implement
>     IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of
>     [RFC5894]) or [UTS46] in order to facilitate their IDNA transition.
>     If a user agent does not implement IDNA2008, the user agent MUST
>     implement IDNA2003.

I really, truly wish we could avoid all reference to 5895 and UTS46. 
(And this comes from a co-author of the former.) Basically, those 
documents are about taking user (or other sorts of "unwashed" input) and 
doing something 'magic' before handing it to something that expects 
proper IDNs. Really, I'd like this kind of protocol document to say, 
"What goes is this field is something that is properly pre-processed by 
whatever handed it to us and if it's bogus, we're not going to do 
anything to 'help' it." But I understand that this may be "happy 
thoughts". If you really can't avoid talking about user input processing 
in this document, I will hold my nose and say no more about it.

> 13.2.  Internationalized Domain Names
>
>     Internet security relies in part on the DNS and the domain names it
>     hosts.  Domain names are used by users to identify and connect to
>     Internet hosts and other network resources.  For example, Internet
>     security is compromised if a user entering an internationalized
>     domain name (IDN) is connected to different hosts based on different
>     interpretations of the IDN.
>
>     The processing models specified in this specification assume that the
>     domain names they manipulate are IDNA-canonicalized, and that the
>     canonicalization process correctly performed all appropriate IDNA and
>     Unicode validations and character list testing per the requisite
>     specifications (e.g., as noted in Section 8 "Domain Name IDNA-
>     Canonicalization").  These steps are necessary in order to avoid
>     various potentially compromising situations.
>
>     In brief, some examples of issues that could stem from lack of
>     careful and consistent Unicode and IDNA validations are things such
>     as unexpected processing exceptions, truncation errors, and buffer
>     overflows, as well as false-positive and/or false-negative domain
>     name matching results.  Any of the foregoing issues could possibly be
>     leveraged by attackers in various ways.
>
>     Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in
>     terms of disallowed characters and character mapping conventions.
>     This situation can also lead to false-positive and/or false-negative
>     domain name matching results, resulting in, for example, users
>     possibly communicating with unintended hosts, or not being able to
>     reach intended hosts.
>
>     For details, refer to the Security Considerations sections of
>     [RFC5890], [RFC5891], and [RFC3490], as well as the specifications
>     they normatively reference.  Additionally, [RFC5894] provides
>     detailed background and rationale for IDNA2008 in particular, as well
>     as IDNA and its issues in general, and should be consulted in
>     conjunction with the former specifications.

Peachy.

I hope that helps.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]