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

=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 23 December 2011 06:06 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3876921F8A55 for <websec@ietfa.amsl.com>; Thu, 22 Dec 2011 22:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tAKvdaJqCTz1 for <websec@ietfa.amsl.com>; Thu, 22 Dec 2011 22:06:30 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com []) by ietfa.amsl.com (Postfix) with SMTP id E487E21F8A4E for <websec@ietf.org>; Thu, 22 Dec 2011 22:06:26 -0800 (PST)
Received: (qmail 29589 invoked by uid 0); 23 Dec 2011 06:06:05 -0000
Received: from unknown (HELO box514.bluehost.com) ( by cpoproxy2.bluehost.com with SMTP; 23 Dec 2011 06:06:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wpf31BD1SO4FZdhXtciQ4ejumiH64jWU1rpLz9gEjpw=; b=p901ojZj3/kQnmuToYEZPNwpdkO0QZYv029n4rFWjvt8U6u/T5wubu8VpAaGlrYJIdPEH1PNoOfz0ExB7IjfQr4vlxLp3eL3SY7S1wU0rNF1Pfdl472x4ELytAuJpxbc;
Received: from 168-215-210-150.static.twtelecom.net ([] helo=[]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RdyGa-0002d6-FG; Thu, 22 Dec 2011 23:06:04 -0700
Message-ID: <4EF41A5A.2080109@KingsMountain.com>
Date: Thu, 22 Dec 2011 22:06:18 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth authed with jeff.hodges+kingsmountain.com}
Cc: IETF WebSec WG <websec@ietf.org>
Subject: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2011 06:06:31 -0000

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

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)

Please review and comment. Thanks,


From: =JeffH <Jeff.Hodges@KingsMountain.com>;
Date: Thu, 29 Sep 2011 20:07:15 -0700
To: IETF IDNA Update WG <idna-update@alvestrand.no>;
Cc: Pete Resnick <presnick@qualcomm.com>;, websec-chairs@tools.ietf.org,
	Peter Saint-Andre <stpeter@stpeter.im>;, Adam Barth <ietf@adambarth.com>;


In working towards completion of..

    HTTP Strict Transport Security (HSTS)


    The Web Origin Concept

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

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.


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

     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
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.
13.  Security Considerations
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.

13.3.  Denial of Service (DoS)