comments on -httpbis-cookie-alone-00

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 13 April 2016 23:23 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7645612E54B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Apr 2016 16:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVxYdMWq_ku3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Apr 2016 16:22:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AF012E545 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 13 Apr 2016 16:22:57 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aqU3C-0005BA-32 for ietf-http-wg-dist@listhub.w3.org; Wed, 13 Apr 2016 23:18:22 +0000
Resent-Date: Wed, 13 Apr 2016 23:18:22 +0000
Resent-Message-Id: <E1aqU3C-0005BA-32@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Jeff.Hodges@kingsmountain.com>) id 1aqU36-0005AO-97 for ietf-http-wg@listhub.w3.org; Wed, 13 Apr 2016 23:18:16 +0000
Received: from gproxy6-pub.mail.unifiedlayer.com ([67.222.39.168]) by lisa.w3.org with smtp (Exim 4.80) (envelope-from <Jeff.Hodges@kingsmountain.com>) id 1aqU34-0000ln-A9 for ietf-http-wg@w3.org; Wed, 13 Apr 2016 23:18:15 +0000
Received: (qmail 8537 invoked by uid 0); 13 Apr 2016 23:17:49 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 13 Apr 2016 23:17:49 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id i6Hh1s01Q2UhLwi016HkoS; Thu, 14 Apr 2016 00:17:46 -0600
X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=A5nG59QqD5UA:10 a=kziv93cY1bsA:10 a=kgoENrvEAAAA:8 a=SSmOFEACAAAA:8 a=A1X0JdhQAAAA:8 a=BqEg4_3jAAAA:8 a=H0umD5oqAAAA:8 a=48vgC7mUAAAA:8 a=KV5hHkq8AAAA:8 a=wjhh3zU3pyM6c-Le-HcA:9 a=CJhkMNZSLbFBJKu6:21 a=yv9HjR0HwHZ3rCLT:21 a=QEXdDO2ut3YA:10 a=26XNcaxp6hkA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=Q/Na7SHH7uaubC0tBQ6uJXRM17m/bk0+MVhpNx/CIs0=; b=dffR/Lmg3DfWeCtKa5YpGUKwGZ i8cpimwI2mdoxMZ6urnrSYQ4wTlOQC5uaJ5E4Y1AhJRb2/BCR1fOyb+RiVKG/B33uVpg+XMP/5EfU +jqdT2e9Tzqhjeznyt8JVisR1;
Received: from [70.213.6.168] (port=8816 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1aqU2a-0000kh-Ki for ietf-http-wg@w3.org; Wed, 13 Apr 2016 17:17:44 -0600
To: IETF HTTP WG <ietf-http-wg@w3.org>
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Message-ID: <570ED38D.4040303@KingsMountain.com>
Date: Wed, 13 Apr 2016 16:17:33 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.6.168 authed with jeff.hodges+kingsmountain.com}
Received-SPF: pass client-ip=67.222.39.168; envelope-from=Jeff.Hodges@kingsmountain.com; helo=gproxy6-pub.mail.unifiedlayer.com
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aqU34-0000ln-A9 cd24c785d3db11b34346f72b516530c5
X-Original-To: ietf-http-wg@w3.org
Subject: comments on -httpbis-cookie-alone-00
Archived-At: <http://www.w3.org/mid/570ED38D.4040303@KingsMountain.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31443
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

here's some comments on -httpbis-cookie-alone-00..

HTH,

=JeffH


overall editorial:

use either "non-secure origin" or "insecure origin" consistently. if I were 
to chose one, I suppose I'd choose "insecure origin", but it's not a big deal.


 > HTTP Working Group                                               M. West
 > Internet-Draft                                               Google, Inc
 > Updates: 6265 (if approved)                            February 23, 2016
 > Intended status: Standards Track
 > Expires: August 26, 2016
 >
 >
 >    Deprecate modification of 'secure' cookies from non-secure origins
 >                    draft-ietf-httpbis-cookie-alone-00
 >
 > Abstract
 >
 >    This document updates RFC6265 by removing the ability for a non-
 >    secure origin to set cookies with a 'secure' flag, and to overwrite
 >    cookies whose 'secure' flag is set.  This deprecation improves the
 >    isolation between HTTP and HTTPS origins, and reduces the risk of
 >    malicious interference.
 >
<snip>
 >
 > Table of Contents
 >
 >    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
 >    2.  Terminology and notation  . . . . . . . . . . . . . . . . . .   2
 >    3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   2
 >    4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
 >    5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
 >      5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
 >      5.2.  Informative References  . . . . . . . . . . . . . . . . .   4
 >    Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   5
 >    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5
 >
 > 1.  Introduction
 >
 >    Section 8.5 and Section 8.6 of [RFC6265] spell out some of the
 >    drawbacks of cookies' implementation: due to historical accident,
 >    non-secure origins can set cookies which will be delivered to secure
 >    origins in a manner indistinguishable from cookies set by that origin

s/set by that origin/set by the secure origin/


the terms "secure origin" and "non-secure origin" aka "insecure origin" do 
not appear to be defined anywhere? those terms do not occur in RFC6454, nor 
RFC6265, and "non-secure origin" occurs only in passing in 
webappsec-secure-contexts [1].

Though, the latter citation is to the editor's draft -- the official 
"working draft" [2] has a notion of "potentially secure origin" which seems 
to be superseded in the editor's draft [1] by "potentially trustworthy" 
origin, and it seems we perhaps ought to reference that here, thus see 
suggestion below in "2. Terminology and notation".

[1] https://w3c.github.io/webappsec-secure-contexts/

[2] https://www.w3.org/TR/powerful-features/



 >    itself.  This enables a number of attacks, which have been recently
 >    spelled out in some detail in [COOKIE-INTEGRITY].
 >
 >    We can mitigate the risk of these attacks by making it more difficult
 >    for non-secure origins to influence the state of secure origins.
 >    Accordingly, this document recommends the deprecation and removal of
 >    non-secure origins' ability to write cookies with a 'secure' flag,
 >    and their ability to overwrite cookies whose 'secure' flag is set.
 >
 > 2.  Terminology and notation
 >
 >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 >    document are to be interpreted as described in [RFC2119].
 >
 >    The "scheme" component of a URI is defined in Section 3 of [RFC3986].

suggested addition:

A "secure origin" is one which is deemed "potentially trustworthy" by the 
algorithm given in S 3.2 "Is origin potentially trustworthy?" of 
[SECURE-CONTEXTS], and an "insecure origin" is one deemed "Not Trustworthy" 
by the same algorithm.

NOTE: of course, this definition of "secure origin" could perhaps (also) be 
made explicit in [1].


 > 3.  Recommendations
 >
 >    This document updates Section 5.3 of [RFC6265] as follows:
 >
 >    1.  After step 8 of the current algorithm, which sets the cookie's
 >        "secure-only-flag", execute the following step:
 >
 >        1.  If the "scheme" component of the "request-uri" does not
 >            denote a "secure" protocol (as defined by the user agent),
 >            and the cookie's "secure-only-flag" is "true", then abort
 >            these steps and ignore the newly created cookie entirely.

 >    2.  Before step 11, execute the following step:
 >
 >        1.  If the newly created cookie's "secure-only-flag" is not set,
 >            and the "scheme" component of the "request-uri" does not
 >            denote a "secure" protocol, then abort these steps and ignore
 >            the newly created cookie entirely if the cookie store
 >            contains one or more cookies that meet all of the following
 >            criteria:
 >
 >            1.  Their "name" matches the "name" of the newly created
 >                cookie.
 >            2.  Their "secure-only-flag" is set.
 >            3.  Their "domain" domain-matches the "domain" of the newly
 >                created cookie, or vice-versa.
 >
 >            Note: This comparison intentionally ignores the "path"
 >            component.  The intent is to allow the "secure" flag to
 >            supercede the "path" restrictions to protect sites against
 >            cookie fixing attacks.
 >
 >            Note: This allows "secure" pages to override "secure" cookies
 >            with non-secure variants.  Perhaps we should restrict that as
 >            well?

is the latter Note correct? should it rather be..

    Note: This allows "secure" pages to override "insecure"
    cookies with "secure" variants. Perhaps we should restrict
    that as well?

..or do I misunderstand the Note?




 >    3.  In order to ensure that a non-secure site

s/non-secure site/insecure origin/ ..?

 >                                                    can never cause a
 >        "secure" cookie to be evisted, adjust the "remove excess cookies"

s/evisted/evicted/


 >        priority order at the bottom of Section 5.3 to be the following:
 >
 >        1.  Expired cookies.
 >        2.  Cookies whose "secure-only-flag" is not set and which share a
 >            "domain" field with more than a predetermined number of other
 >            cookies.
 >        3.  Cookies that share a "domain" field with more than a
 >            predetermined number of other cookies.
 >        4.  All cookies.
 >
 >        Note that the eviction algorithm specified here is triggered only
 >        after insertion of a cookie which causes the user agent to exceed
 >        some predetermined upper bound.  Conforming user agents MUST
 >        ensure that inserting a non-secure cookie does not cause a secure
 >        cookie to be removed.

is the above parag intended to replace the final parag of RFC6265 S 5.3 
which is..

    If two cookies have the same removal priority, the user agent MUST
    evict the cookie with the earliest last-access date first.
    When "the current session is over" (as defined by the user agent),
    the user agent MUST remove from the cookie store all cookies with the
    persistent-flag set to false.

..or is it intended to be in addition to this final parag?

I am guessing that the above "Note that the eviction alg..." parag is 
effectively suggesting some text to be added to the existing final parag of 
RFC6265 S 5.3, e.g...

    If two cookies have the same removal priority, the user agent MUST
    evict the cookie with the earliest last-access date first. However,
    user agents MUST ensure that inserting a non-secure cookie does not
    cause eviction of a secure cookie. When "the current session is
    over" (as defined by the user agent), the user agent MUST remove
    from the cookie store all cookies with the persistent-flag set
    to false.

..?



 > 4.  Security Considerations
 >
 >    This specification increases a site's confidence that secure cookies
 >    it sets will remain unmodified by insecure pages on hosts which it
 >    domain-matches.  Ideally, sites would use HSTS as described in
 >    [RFC6797] to defend more robustly against the dangers of non-secure
 >    transport in general, but until adoption of that protection becomes
 >    ubiquitous, this deprecation this document recommends will mitigate a
 >    number of risks.
 >
 >    The mitigations in this document do not, however, give complete
 >    confidence that a given cookie was set securely.  If an attacker is
 >    able to impersonate a response from "http://example.com/" before a
 >    user visits "https://example.com/", the user agent will accept any
 >    cookie that the insecure origin sets, as the "secure" cookie won't
 >    yet be present in the user agent's cookie store.  An active network
 >    attacker may still be able to use this ability to mount an attack
 >    against "example.com", even if that site uses HTTPS exclusively.
 >
 >    The proposal in [COOKIE-PREFIXES] could mitigate this risk, as could
 >    "preloading" HSTS for "example.com" into the user agent
 >    [HSTS-PRELOADING].

perhaps add this here..

    NOTE: given the above, then there are revisions/additions to
    RFC6265's Sec Cons to appropriately craft (the first two paragraphs
    above constitute raw material for such revisions/additions), though
    doing so ultimately depends on which set of internet-drafts that
    'patch' RFC6265 are implemented.

..?



 >
 > 5.  References

Add ref to webappsec-secure-contexts, tho I am unsure whether it ought to be 
normative or informative..

   [SECURE-CONTEXTS]  West, M., Zhu, Yan, "Secure Contexts",
                      work-in-progress,
                      <https://w3c.github.io/webappsec-secure-contexts/>.



 >
 > 5.1.  Normative References
 >
 >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 >               Requirement Levels", BCP 14, RFC 2119,
 >               DOI 10.17487/RFC2119, March 1997,
 >               <http://www.rfc-editor.org/info/rfc2119>.
 >
 >    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 >               Resource Identifier (URI): Generic Syntax", STD 66,
 >               RFC 3986, DOI 10.17487/RFC3986, January 2005,
 >               <http://www.rfc-editor.org/info/rfc3986>.
 >
 >    [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
 >               DOI 10.17487/RFC6265, April 2011,
 >               <http://www.rfc-editor.org/info/rfc6265>.
 >
 > 5.2.  Informative References
 >
 >    [COOKIE-INTEGRITY]
 >               Zheng, X., Jiang, J., Liang, J., Duan, H., Chen, S., Wan,
 >               T., and N. Weaver, "Cookies Lack Integrity: Real-World
 >               Implications", August 2015,
 >               <https://www.usenix.org/conference/usenixsecurity15/
 >               technical-sessions/presentation/zheng>.
 >
 >    [COOKIE-PREFIXES]
 >               West, M., "Cookie Prefixes", 2016,
 >               <https://tools.ietf.org/html/draft-ietf-httpbis-cookie-
 >               prefixes>.
 >
 >    [HSTS-PRELOADING]
 >               "HSTS Preload Submission", n.d.,
 >               <https://hstspreload.appspot.com/>.
 >
 >    [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
 >               Transport Security (HSTS)", RFC 6797,
 >               DOI 10.17487/RFC6797, November 2012,
 >               <http://www.rfc-editor.org/info/rfc6797>.