idnits 2.17.1 draft-ietf-httpbis-cookie-alone-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2016) is 2790 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. West 3 Internet-Draft Google, Inc 4 Updates: 6265 (if approved) September 5, 2016 5 Intended status: Standards Track 6 Expires: March 9, 2017 8 Deprecate modification of 'secure' cookies from non-secure origins 9 draft-ietf-httpbis-cookie-alone-01 11 Abstract 13 This document updates RFC6265 by removing the ability for a non- 14 secure origin to set cookies with a 'secure' flag, and to overwrite 15 cookies whose 'secure' flag is set. This deprecation improves the 16 isolation between HTTP and HTTPS origins, and reduces the risk of 17 malicious interference. 19 Note to Readers 21 Discussion of this draft takes place on the HTTP working group 22 mailing list (ietf-http-wg@w3.org), which is archived at 23 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 25 Working Group information can be found at http://httpwg.github.io/ ; 26 source code and issues list for this draft can be found at 27 https://github.com/httpwg/http-extensions/labels/cookie-alone . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 9, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3 65 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 5.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 71 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 5 72 B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Section 8.5 and Section 8.6 of [RFC6265] spell out some of the 78 drawbacks of cookies' implementation: due to historical accident, 79 non-secure origins can set cookies which will be delivered to secure 80 origins in a manner indistinguishable from cookies set by that origin 81 itself. This enables a number of attacks, which have been recently 82 spelled out in some detail in [COOKIE-INTEGRITY]. 84 We can mitigate the risk of these attacks by making it more difficult 85 for non-secure origins to influence the state of secure origins. 86 Accordingly, this document recommends the deprecation and removal of 87 non-secure origins' ability to write cookies with a 'secure' flag, 88 and their ability to overwrite cookies whose 'secure' flag is set. 90 2. Terminology and notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 The "scheme" component of a URI is defined in Section 3 of [RFC3986]. 98 3. Recommendations 100 This document updates Section 5.3 of [RFC6265] as follows: 102 1. After step 8 of the current algorithm, which sets the cookie's 103 "secure-only-flag", execute the following step: 105 1. If the "scheme" component of the "request-uri" does not 106 denote a "secure" protocol (as defined by the user agent), 107 and the cookie's "secure-only-flag" is "true", then abort 108 these steps and ignore the newly created cookie entirely. 109 2. Before step 11, execute the following step: 111 1. If the newly created cookie's "secure-only-flag" is not set, 112 and the "scheme" component of the "request-uri" does not 113 denote a "secure" protocol, then abort these steps and ignore 114 the newly created cookie entirely if the cookie store 115 contains one or more cookies that meet all of the following 116 criteria: 118 1. Their "name" matches the "name" of the newly created 119 cookie. 120 2. Their "secure-only-flag" is set. 121 3. Their "domain" domain-matches the "domain" of the newly 122 created cookie, or vice-versa. 123 4. The "path" of the newly created cookie path-matches the 124 "path" of the existing cookie. 126 Note: The "path" comparison is not symmetric, ensuring only 127 that a newly-created non-secure cookie does not overlay an 128 existing secure cookie, providing some mitigation against 129 cookie fixing attacks. That is, given an existing secure 130 cookie named "a" with a "path" of "/login", a non-secure 131 cookie named "a" could be set for a "path" of "/" or "/foo", 132 but not for a "path" of "/login" or "/login/en". 134 Note: This allows "secure" pages to override "secure" cookies 135 with non-secure variants. Perhaps we should restrict that as 136 well? 138 3. In order to ensure that a non-secure site can never cause a 139 "secure" cookie to be evicted, adjust the "remove excess cookies" 140 priority order at the bottom of Section 5.3 to be the following: 142 1. Expired cookies. 143 2. Cookies whose "secure-only-flag" is not set and which share a 144 "domain" field with more than a predetermined number of other 145 cookies. 146 3. Cookies that share a "domain" field with more than a 147 predetermined number of other cookies. 148 4. All cookies. 150 Note that the eviction algorithm specified here is triggered only 151 after insertion of a cookie which causes the user agent to exceed 152 some predetermined upper bound. Conforming user agents MUST 153 ensure that inserting a non-secure cookie does not cause a secure 154 cookie to be removed. 156 4. Security Considerations 158 This specification increases a site's confidence that secure cookies 159 it sets will remain unmodified by insecure pages on hosts which it 160 domain-matches. Ideally, sites would use HSTS as described in 161 [RFC6797] to defend more robustly against the dangers of non-secure 162 transport in general, but until adoption of that protection becomes 163 ubiquitous, this deprecation this document recommends will mitigate a 164 number of risks. 166 The mitigations in this document do not, however, give complete 167 confidence that a given cookie was set securely. If an attacker is 168 able to impersonate a response from "http://example.com/" before a 169 user visits "https://example.com/", the user agent will accept any 170 cookie that the insecure origin sets, as the "secure" cookie won't 171 yet be present in the user agent's cookie store. An active network 172 attacker may still be able to use this ability to mount an attack 173 against "example.com", even if that site uses HTTPS exclusively. 175 The proposal in [COOKIE-PREFIXES] could mitigate this risk, as could 176 "preloading" HSTS for "example.com" into the user agent 177 [HSTS-PRELOADING]. 179 5. References 181 5.1. Normative References 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, 185 DOI 10.17487/RFC2119, March 1997, 186 . 188 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 189 Resource Identifier (URI): Generic Syntax", STD 66, 190 RFC 3986, DOI 10.17487/RFC3986, January 2005, 191 . 193 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 194 DOI 10.17487/RFC6265, April 2011, 195 . 197 5.2. Informative References 199 [COOKIE-INTEGRITY] 200 Zheng, X., Jiang, J., Liang, J., Duan, H., Chen, S., Wan, 201 T., and N. Weaver, "Cookies Lack Integrity: Real-World 202 Implications", August 2015, 203 . 206 [COOKIE-PREFIXES] 207 West, M., "Cookie Prefixes", 2016, 208 . 211 [HSTS-PRELOADING] 212 "HSTS Preload Submission", n.d., 213 . 215 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 216 Transport Security (HSTS)", RFC 6797, 217 DOI 10.17487/RFC6797, November 2012, 218 . 220 Appendix A. Acknowledgements 222 Richard Barnes encouraged a formalization of the deprecation 223 proposal. [COOKIE-INTEGRITY] was a useful exploration of the issues 224 [RFC6265] described. 226 Appendix B. Changes 227 B.1. Since -00 229 o Issue 223 addressed by adding a path-match constraint to the 230 storage algorithm for non-secure cookies. This ensures that non- 231 secure cookies cannot overlay secure cookies for a given path, but 232 allows secure and non-secure cookies with the same name to exist 233 on distinct paths. 235 Author's Address 237 Mike West 238 Google, Inc 240 Email: mkwst@google.com 241 URI: https://mikewest.org/