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

[J-F C. Morfin]

Jeff,

I am sorry I cannot study your inputs before one or two weeks. From 
your mail, I fear there is a misunderstanding concerning the impact 
of IDNA2008 on the architecture and security of the network user side.

Basically, the problem is as follows:

- the support of a language in the OSI model is achieved at the 
presentation layer.
- the support of the linguistic diversity (scripts and 
orthotypography of each language) at end user level, to be constantly 
adapted to variants as demanded by people and the foreseeable 
semantic orient extension of networking, means an incredibly complex 
presentation layer.
- the Internet has no presentation layer.

However, IDNA2008 has introduced a stable, simple, and secure way to 
support the IDN linguistic diversity. That it was able to do it 
without changing a single bit in existing Internet protocols means 
that this way was buried into the Internet architecture from the very 
beginning. Warning!: that it took ten years to exemplify a solution 
without documenting an architectural principle in line with RFC 1958 
and 3439 means that the true Internet model is not with us yet.

This new model is under IETF and non-IETF investigation - and you 
participate in its exploration. What we already know is that:

- from the beginning of the IDNA2008 work I asked if the target was 
to support IDNA for the Internet or for the users. The charter and 
the Chair said "for the Internet". So, I committed to make sure that 
I could build the user oriented extension (I called the ML-DNS as in 
multi-layer) on top of the IDNA2008 solution. My referent was the 
support of French semantics in IDNs. There were rough times but a 
Pete Resnick and Paul Hoffman I_D (which became the RFC 5865 for 
information) exemplified a solution for our "unusual" case and 
permitted a full consensus. It introduced (my reading) cooperation 
with external subsidiarity as an Internet architectural principle.

- that consensus was however questioned on two points:
   - by me: the inability to support orthotypographic metadata 
(example: the meaningful French majuscules - that may be represented 
by but are not upper cases)
   - by the AD: the very IDNA architecture concept is costly and 
insecure. Several applications (as what you discuss) on the same 
machine may resolve the same user entry to different IPs.

This called for the concept of a smart (virtual) middlebox I named 
the IUI (see below). It had to be simple (RFC 2934), optional 
(introduction) and at fringes (because being smart) or at edges (OPES).

I was one of the active people in discussing this:

1. I reported the IESG my IDNA2008 unresolved problems as Project.FRA 
leader, an experimental project of open networked ontology supported 
by a Francophone namespace:
     - the way I would architecturally address it,
     - the urgency for them to accept IDNA2008 so we could start 
working on a stable definition of the Internet Use Interface IETF 
requirements (IUI).
     - the implied major problem of IETF responsibility (cf. RFC 
3935) in specifying the resulting multi-technology users' digital 
ecosystem Intelligent Use Interface (IUI)
     - I would address through an appeal.

2. I therefore constructively appealed against the lack of an IESG or 
IAB disclaimer in IDNA2008 RFCs alerting everyone of the implied 
enormous extension and simplification in reading the Internet 
technology. The lack of disclaimer has lead to several requests for 
information like yours (WG/PRECIS, Hapiana, ICANN/WG/VIP) and work at the IUCG.

The IESG and IAB response and the parallel IAB road map were equally 
constructive. IAB/IESG responses and RFC 5865 lead to understand that 
IUI architectures and standardization are not in the in the IETF area 
and that interfacing protocol should be completed by an informational 
"how to" in the case no IUI is being involved (as exemplified by the 
IDNA2008 RFC set).

Based upon my position during the WG work and the final consensus we 
reached, I would suggest this simple rule: the IETF can use MUSTs 
only for the end to end, SHOULDs only for the fringe to fringe, and 
MAYs for the applications to applications. This way Internet protocol 
requirements are stable and clear, and IUI test designers and further 
standardizers have clear inputs to implement their services and their 
interface with the various local applications (network apps such as 
the DNS, IUI mutual service apps, and the User's side applications 
such as a browser).

Without prejudging the finalization of the post-IDNA2008 Internet and 
digital ecosystem Model, I think the "plug, end, fringe, application, 
brain" layering protects the future.
jfc


At 05:07 30/09/2011, =JeffH wrote:
>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.
>               .
>               .
>               .
>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.
>               .
>               .
>               .
>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)
>               .
>               .
>               .
>
>
>---
>end
>