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

=JeffH <Jeff.Hodges@KingsMountain.com> Mon, 30 July 2012 05:30 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877F721F85C7 for <websec@ietfa.amsl.com>; Sun, 29 Jul 2012 22:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.495
X-Spam-Level:
X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wffKJ8mR7I-O for <websec@ietfa.amsl.com>; Sun, 29 Jul 2012 22:30:14 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id D7EB621F85D1 for <websec@ietf.org>; Sun, 29 Jul 2012 22:30:13 -0700 (PDT)
Received: (qmail 1076 invoked by uid 0); 30 Jul 2012 05:30:13 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 30 Jul 2012 05:30:13 -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=xmKcfdIvb5LkKTijMpc7nGaIFTk7mCbkrfXaMyxYse4=; b=nTdfKFh6mPLnoARRSpWzkjRa/18p9woCnGMt0xfpW/YhNEF0zfRCF4KS0pel+fMikZvz0A5sEeLj4sXTRSTtgff3VOXdpnFMSg51Ok4xH/3Rs7iH1uTdTbYXcJ6l0rPC;
Received: from [130.129.65.226] (port=37158) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SviYO-0007ck-Gm; Sun, 29 Jul 2012 23:30:05 -0600
Message-ID: <50161BD5.7040901@KingsMountain.com>
Date: Sun, 29 Jul 2012 22:29:57 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
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 130.129.65.226 authed with jeff.hodges+kingsmountain.com}
Cc: General Area Review Team <gen-art@ietf.org>, IETF WebSec WG <websec@ietf.org>, draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List <ietf@ietf.org>
Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
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: Mon, 30 Jul 2012 05:30:15 -0000

thanks for the review Ben.

 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
 > please see the FAQ at
 >
 > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .
 >
 > Please resolve these comments along with any other Last Call comments you may
 > receive.
 >
 > Document:  draft-ietf-websec-strict-transport-sec-11 Reviewer: Ben Campbell
 > Review Date: 2012-07-24 IETF LC End Date: 2012-07-25
 >
 > Summary: This draft is almost ready for publication as a proposed standard,
 > but there are a few issues that should be considered first.
 >
 > *** Major issues:
 >
 > None
 >
 > *** Minor issues:
 >
 > -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
 > should be explicitly flagged and mentioned in the abstract.

Good question, I don't believe we've discussed this possibility directly in the 
websec wg. In looking at the RFCs that do update RFC2616, it doesn't look like 
draft-ietf-websec-strict-transport-sec (HSTS) is of that ilk.

However, it nominally appears that an argument could be made that it'd be 
appropriate to update RFC2818 via draft-ietf-websec-strict-transport-sec, 
specifically with regards to Section 2.1.  Connection Initiation.

Though, RFC2818 is Informational, which may be an issue (?). Also, perhaps this 
is something to more appropriately do via a standards-track rfc2818bis, i.e., 
have the latter reference the HSTS spec.

this is something to discuss this coming week @IETF-84 Vancouver it seems.


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

###
10.  Server Implementation and Deployment Advice

    This section is non-normative.

10.1.  Non-Conformant User Agent Considerations

    Non-conformant UAs 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".  Please refer to Section 14.1
    "Non-Conformant User Agent Implications" for further discussion.

                        .
                        .

14.  Security Considerations
                        .
                        .
14.1.  Non-Conformant User Agent Implications

    Non-conformant UAs 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 user agents will be vulnerable to both:

       Passive network attacks due to web site development and deployment
       bugs: 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.

       Active network attacks: 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.
###

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


 >
 > -- section 6.1:
 >
 > The draft mentions that directives may be extended, but defers creation of an
 > IANA registry to the time of first extension. IANA registries are not
 > expensive; I suggest it be created now. If there's a good reason not to, then
 > the draft should still address the specification policy for extensions.
 >
 > Also, do you expect that some future directive might need to have a
 > "required-to-understand" status? Given that this is a security-affecting
 > extension, it seems likely. If so, then the mechanism for expressing that
 > needs to be defined in this draft.


These are good questions, and they beg the overall question of how complex this 
simple solution really needs to be and whether we really think we'll need any 
extensions. Something for us to discuss in the working group meeting on Tue 
morning I think.

 >
 > -- section 7.2:
 >
 > Am I correct to assume that the server must never just serve the content over
 > a non-secure connection? If so, it would be helpful to mention that, maybe
 > even normatively.

It's a SHOULD, see the Note in that section, so it's already effectively stated 
normatively, though one needs to understand HTTP workings to realize it in the 
way you stated it above.  Perhaps could add a simple statement as you suggest to 
the intro para for section 7 Server Processing Model, to address this concern?


 >
 > -- section 8.4:
 >
 > Does this imply a duty for compliant UAs to check for revocation one way or
 > another?

yes. though, per other relevant specifications, as duly cited. AFAIK the HSTS 
spec doesn't need to get into the details because the underlying security 
transport specs, namely TLS, already do this.



 >
 >
 > *** Nits/editorial comments:
 >
 > -- idnits reports an uncited reference:
 >
 > == Unused Reference: 'RFC6376' is defined on line 1709, but no explicit
 > reference was found in the text


fixed in my -12 working copy.


 > -- section 1.2:
 >
 > The description of indented notes is almost precisely the opposite of how
 > they are described in the RFC editor's style guide. It describes them as
 > "parenthetical" notes, which is how experienced RFC readers are likely to
 > perceive them. While it doesn't say so explicitly, I think putting normative
 > text in parenthetical notes should be avoided. If these are intended to be
 > taken more strongly than that (and by the description, I take it they should
 > be taken more strongly than the surrounding text), then I suggest choosing a
 > stronger prefix than "NOTE:"

As it turns out, almost all the Notes are parenthetical.

I'll render the one(s) that are normative as a regular paragraph(s) and leave 
the others as-is. Will that address your concern?


 >
 > -- section 7:
 >
 > Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for
 > SSL3?

no, it's just that SSLv3 remains a fact of life and is referenced for 
completeness' sake.



 >
 > -- section 8.2, paragraph 5 (first non-numbered paragraph after numbered
 > list)
 >
 > To be pedantic, this could be taken to mean a congruent match only applies if
 > the includeSubdomains flag is not present. I assume it's intended to apply
 > whether or not the flag is present.

[ I am assuming you actually are referring to section 8.3, as section 8.2 
doesn't mention the includeSubdomains flag and does not contain a numbered list. ]

yes, a congruent match is intended to apply whether or not the flag is present.



 > -- section 12 and subsections:
 >
 > I was surprised to see more apparently normative material after the
 > non-normative guidance sections. I think it would improve the organization to
 > put this closer to the normative rules for UAs.

We can move section 12 up ahead of the non-normative guidance sections.


 >
 > -- section 14.1, 4th paragraph (first non-bulleted paragraph following bullet
 > list)
 >
 > This issue is only true for proxies that act as a TLS MiTM, right?

yes.


 > Would
 > proxies that tunnel TLS via the CONNECT method have this issue?

I don't think so in the general case.

I'm not sure what terminology to use to differentiate such proxies if this is a 
detail worth addressing.


thanks again,

=JeffH