Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

=JeffH <> Sat, 11 August 2012 04:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69A6F21F8508 for <>; Fri, 10 Aug 2012 21:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.377
X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pqQAKE5ZfQ5v for <>; Fri, 10 Aug 2012 21:41:16 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 6A78021F8507 for <>; Fri, 10 Aug 2012 21:41:15 -0700 (PDT)
Received: (qmail 1457 invoked by uid 0); 11 Aug 2012 04:40:53 -0000
Received: from unknown (HELO ( by with SMTP; 11 Aug 2012 04:40:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pAUvay1+OwfsdgXlsoXr/7NnBbFxf3AmRbW1zQy4gVY=; b=2JCYYopKE5hWt5Dw40q4+QK9rfVYp5cy9gFeYYUfHvOmPlvmXnpiNztH2QgqqV4BHksahsz5o4n29WYkPHuzReCP/hzaT4KTHDRICE4juqTotMrD9ZmyokkLG14pjE4X;
Received: from [] (port=43149 helo=[]) by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1T03VN-0007RE-Lo; Fri, 10 Aug 2012 22:40:53 -0600
Message-ID: <>
Date: Fri, 10 Aug 2012 21:40:51 -0700
From: =JeffH <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ben Campbell <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Cc: General Area Review Team <>, IETF WebSec WG <>,, IETF Discussion List <>
Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Aug 2012 04:41:17 -0000


I believe I've made requite changes to draft-ietf-websec-strict-transport-sec
per this thread as well as the WG f2f discussion @IETF-84 Vancouver and also my
f2f discussion with Ben after the websec wg meeting.

In the below I'm just going to try to identify the individual issues from Ben's
review without quoting all the thread discussion, but also highlight the changes
I have queued in my -12 working copy of draft-ietf-websec-strict-transport-sec.

If the below looks nominally OK I can submit my -12 working copy, please let me 
know (Alexey/Barry). (note: I'm going to be mostly offline for the next several 



Ben's "minor items":

M1) update 2818 ?

 >> -- Does this draft update any other RFCs (e.g. 2616 or 2818)?

Maybe 2818, but based on the informational status of 2818, websec wg 
discussions, and discussions with Ben and EKR, there's no statement of updating 
2818 in my -12 working copy.

M2) non-conformant UAs ?

 >>> -- I did not find any guidance on how to handle UAs that do not
 >>> understand this extension. I don't know if this needs to be normative,
 >>> but the draft should at least mention the possibility and implications.
 >> Agreed. My -12 working copy now contains these new subsections..
 >> <snip/>
 > That's all good text, but I'm not sure it actually captures my concern.
 > <snip/> That is, the server can't merely select the extension and forget
 > about things--it still needs to to take the same care to avoid leaking
 > resources over unprotected connections that it would need to do if this
 > extension did not exist in the first place.
 > I think this is implied by your last sentence above, but it would be better
 > to say it explicitly.

I've added text to my -12 working copy, it now states...

14.1.  Non-Conformant User Agent Implications

    Non-conformant user agents ignore the Strict-Transport-Security
    header field, thus non-conformant user agents do not address the
    threats described in Section 2.3.1 "Threats Addressed".

    This means that the web application and its users wielding non-
    conformant UAs will be vulnerable to both:

    o  Passive network attacks due to web site development and deployment

          For example, if the web application contains any insecure,
          non-"https", references to the web application server, and if
          not all of its cookies are flagged as "Secure", then its
          cookies will be vulnerable to passive network sniffing, and
          potentially subsequent misuse of user credentials.

    o  Active network attacks:

          For example, if an attacker is able to place a man-in-the-
          middle, secure transport connection attempts will likely yield
          warnings to the user, but without HSTS Policy being enforced,
          the present common practice is to allow the user to "click-
          through" and proceed.  This renders the user and possibly the
          web application open to abuse by such an attacker.

    This is essentially the status-quo for all web applications and their
    users in the absence of HSTS Policy.  Since web application providers
    typically do not control the type or version of UAs their web
    applications interact with, the implication is that HSTS Host
    deployers must generally exercise the same level of care to avoid web
    site development and deployment bugs (see Section as they
    would if they were not asserting HSTS Policy.

M3) the superdomain match wins (?) question  (section 8.x generally)

 >>> -- How should a UA handle potential conflicts between a the policy
 >>> record that includes the includeSubdomain, and any records for subdomains
 >>> that might have different parameters?
 >> this is in the draft. the short answer is that at policy enforcement time,
 >> "superdomain matches win".
 >> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) is
 >> noted regardless of whether there are superdomain HSTS hosts asserting
 >> "includeSubDomains".
 >> perhaps this needs to be made more clear?
 > Maybe I'm missing something, but I'm not getting that answer from the text.

In our f2f discussion, Ben and I agreed that we need to clear that we stop on 
first match when doing policy enforcement -- but it turns out to be not quite 
that simple, due to the includeSubDomains semantics. Here's the relvant text now 
in my -12 working copy, the alterations are in step 5...

8.3.  URI Loading and Port Mapping

    Whenever the UA prepares to "load", also known as "dereference", any
    "http" URI [RFC3986] (including when following HTTP redirects
    [RFC2616]), the UA MUST first determine whether a domain name is
    given in the URI and whether it matches a Known HSTS Host, using
    these steps:
    4.  Otherwise, the substring is a given domain name, which MUST be
        matched against the UA's Known HSTS Hosts using the procedure in
        Section 8.2 "Known HSTS Host Domain Name Matching".

    5.  If when performing doman name matching, any superdomain match
        with an asserted includeSubDomains flag is found, or, if no
        superdomain matches with asserted includeSubDomains flags are
        found and a congruent match is found (with or without an asserted
        includeSubDomains flag), then before proceeding with the load:

M4) section 6.1: handling header field extensibility

[ see separate message entitled "handling STS header field extendability" ]
section 7.2 must not serve insecure content?

M5) section 7.2: state explicitly must not serve insecure content?

no changes necessary, see relevant discussion in this thread.

M6) section 8.4:formal duty for revocation checking ?

Based on f2f discussions with Ben and EKR, I now have the following text in my 
-12 working copy, and have moved the references to RFC2560 & RFC5280 to 
Informational. The rationale is that revocation checking is not required by the 
TLS and PKIX specs, they just say "here's how you can do it", and there's not 
really an appropriate spec to point at (which would have any chance at all to be 
actually adhered to by UAs due to the rapidly evolving nature of our 
understanding of the efficacy and performance and utility of "classical" 
revocation checking).

8.4.  Errors in Secure Transport Establishment

    When connecting to a Known HSTS Host, the UA MUST terminate the
    connection (see also Section 12 "User Agent Implementation Advice")
    if there are any errors, whether "warning" or "fatal" or any other
    error level, with the underlying secure transport.  For example, this
    includes any errors found in certificate validity checking UAs employ
    such as via Certificate Revocation Lists (CRL) [RFC5280], or via the
    Online Certificate Status Protocol (OCSP) [RFC2560].

Ben's editorial items:

E1) Unused Reference: 'RFC6376'                       -- done in -12

E2) fixup indented "Note:" such that one(s) that are normative as a regular 
paragraph(s) and leave the others as-is              -- done in -12

E3) reference to SSLv3, ref 6101 informatively       -- done in -12

E4) section 8.3 congruent match -- text is fine, no changes necessary

E5) move section 12 up ahead of the non-normative guidance sections
                                                      -- done in -12

E6) proxy sec cons apply to CONNECT proxy ?            -- done in -12
( noted that the type of proxy of concern is a "MITM non-transparent proxy",
   which ought to clarify that it's not a transparent HTTP CONNECT-based
   proxy. (I couldn't find any dominating terminology describing these
   beasts, it is all over the map, but maybe I'm missing something) )