idnits 2.17.1 draft-west-cookie-incrementalism-00.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 a Security Considerations section. ** The abstract seems to contain references ([I-D.west-http-state-tokens]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 7, 2019) is 1809 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) == Outdated reference: A later version (-13) exists of draft-ietf-httpbis-rfc6265bis-03 == Outdated reference: A later version (-01) exists of draft-west-cookie-samesite-firstparty-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. West 3 Internet-Draft Google 4 Intended status: Standards Track May 7, 2019 5 Expires: November 8, 2019 7 Incrementally Better Cookies 8 draft-west-cookie-incrementalism-00 10 Abstract 12 This document proposes two changes to cookies inspired by the 13 properties of the HTTP State Tokens mechanism proposed in 14 [I-D.west-http-state-tokens]. First, cookies should be treated as 15 "SameSite=Lax" by default. Second, cookies that explicitly assert 16 "SameSite=None" in order to enable cross-site delivery should also be 17 marked as "Secure". 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 8, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 55 2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Monkey-Patches against RFC6265bis . . . . . . . . . . . . . . 3 58 3.1. "Lax" by Default . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Requiring "Secure" for "SameSite=None" . . . . . . . . . 4 60 4. Security and Privacy Considerations . . . . . . . . . . . . . 5 61 4.1. CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Secure Transport . . . . . . . . . . . . . . . . . . . . 5 63 4.3. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 5.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The HTTP State Tokens proposal ([I-D.west-http-state-tokens]) aims to 77 replace cookies with a state management mechanism that has better 78 security and privacy properties. That proposal is somewhat 79 aspirational: it's going to take a long time to come to agreement on 80 the exact contours of a cookie replacement, and an even longer time 81 to actually do so. 83 While we're debating the details of a new state management primitive, 84 it seems quite reasonable to reevaluate some aspects of the existing 85 primitive: cookies. When we can find consensus on some aspect of 86 HTTP State Tokens, we can apply those aspirations to cookies, driving 87 incremental improvements to state management in the status quo. 89 Based on conversations at [HTTP-Workshop-2019] and elsewhere, I'd 90 suggest that we have something like agreement on at least two 91 principles: 93 1. HTTP requests should not carry state along with cross-site 94 requests by default (see Section 8.2 of [RFC6265bis]). 96 2. HTTP requests should not carry state over non-secure channels 97 (see Section 8.3 of [RFC6265bis], and [RFC7258]). 99 With those principles in mind, this document proposes two changes 100 that seem possible to deploy in the near-term. User agents should: 102 1. Treat the lack of an explicit "SameSite" attribute as 103 "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will 104 produce a cookie equivalent to "key=value; SameSite=Lax". 105 Cookies that require cross-site delivery can explicitly opt-into 106 such behavior by asserting "SameSite=None" when creating a 107 cookie. 109 This is spelled out in more detail in Section 3.1. 111 2. Require the "Secure" attribute to be set for any cookie which 112 asserts "SameSite=None" (similar conceptually to the behavior for 113 the "__Secure-" prefix). That is, the "Set-Cookie" value 114 "key=value; SameSite=None; Secure" will be accepted, while 115 "key=value; SameSite=None" will be rejected. 117 This is spelled out in more detail in Section 3.2. 119 2. Conventions and Definitions 121 2.1. Conformance 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.2. Syntax 131 This document adjusts some syntax from [RFC6265bis], and in doing so, 132 relies upon the Augmented Backus-Naur Form (ABNF) notation of 133 [RFC5234]. 135 3. Monkey-Patches against RFC6265bis 137 3.1. "Lax" by Default 139 The processing algorithm in Section 5.3.7 of [RFC6265bis] treats the 140 absence of a "SameSite" attribute in a "Set-Cookie" header as 141 equivalent to the presence of "SameSite=None". Cookies are therefore 142 available for cross-site delivery by default, and developers may opt- 143 into more security by setting some other value explicitly. Ideally, 144 we'd invert that such that developers who accepted the risks of 145 cross-site delivery (see Section 8.2 of [RFC6265bis]) could opt into 146 them, while developers who didn't make any explicit choice would be 147 protected by default. 149 We could accomplish this goal by first altering the processing 150 algorithm, replacing the current step 1: 152 1. Let "enforcement" be "None". 154 with the following two steps: 156 1. Let "enforcement" be "Lax". 158 2. If cookie-av's attribute-value is a case-insensitive 159 match for "None", set "enforcement" to "None". 161 And then by, altering step 13 of the cookie storage model 162 (Section 5.4 of [RFC6265bis]) from: 164 13. If the cookie-attribute-list contains an attribute 165 with an attribute-name of "SameSite", set the cookie's 166 same-site-flag to attribute-value (i.e. either "Strict", 167 "Lax", or "None"). Otherwise, set the cookie's 168 same-site-flag to "None". 170 to: 172 13. If the cookie-attribute-list contains an attribute 173 with an attribute-name of "SameSite", set the 174 cookie's same-site-flag to attribute-value. Otherwise, 175 set the cookie's same-site-flag to "Lax". 177 This would have the effect of mapping the default behavior in the 178 absence of an explicit "SameSite" attribute, as well as the presence 179 of any unknown "SameSite" value, to the "Lax" behavior, protecting 180 developers by making cross-site delivery an explicit choice, as 181 opposed to an implicit default. 183 3.2. Requiring "Secure" for "SameSite=None" 185 Cookies sent over plaintext HTTP are visible to anyone on the 186 network. As section 8.3 of [RFC6265bis] points out, this visibility 187 exposes substantial amounts of data to network attackers. We know, 188 for example, that long-lived and stable cookies have enabled 189 pervasive monitoring [RFC7258] in the past (see Google's PREF cookie 190 [pref-cookie]), and we know that a secure transport layer provides 191 significant confidentiality protections against this kind of attack. 193 We can, to a reasonable extent, mitigate this threat by ensuring that 194 cookies intended for cross-site delivery (and therefore likely to be 195 more prevalent on the wire than cookies scoped down to same-site 196 requests) require secure transport. 198 That is, we can require that any cookie which asserts "SameSite=None" 199 must also assert the "Secure" attribute (Section 4.1.2.5 of 200 [RFC6265bis]) by altering the storage model defined in Section 5.4 of 201 [RFC6265bis], inserting the following step after the existing step 202 14: 204 15. If the cookie's "same-site-flag" is "None", abort 205 these steps and ignore the cookie entirely unless 206 the cookie's secure-only-flag is true. 208 This is conceptually similar to the requirements put into place for 209 the "__Secure-" prefix (Section 4.1.3.1 of [RFC6265bis]). 211 4. Security and Privacy Considerations 213 4.1. CSRF 215 "SameSite" is a reasonably robust defense against some classes of 216 cross-site request forgery attacks, as described in Section 8.8.1 of 217 [RFC6265bis], but developers need to opt-into its protections in 218 order for them to have any effect. That is, developers are 219 vulnerable to CSRF attacks by default, and must do some work to shift 220 themselves into a more defensible position. 222 The change proposed in Section 3.1 would invert that requirement, 223 placing the burden on the small number of developers who are building 224 services that require state in cross-site requests. Those developers 225 would be empowered to opt-into the status quo's less-secure model, 226 while developers who don't intend for their projects to be embedded 227 in cross-site contexts are protected by default. 229 4.2. Secure Transport 231 As discussed in Section 8.3 of [RFC6265bis], cookies delivered over 232 plaintext channels are exposed to intermediaries, and thereby enable 233 pervasive monitoring [RFC7258]. The change proposed in Section 3.2 234 above would set secure transport as a baseline requirement for all 235 stateful cross-site requests, thereby reducing the risk that these 236 cookies can be cataloged or modified by network attackers. 238 Requiring secure transport for cookies intended for cross-site usage 239 has the exciting secondary effect of increasing pressure on entities 240 that produce embeddable content to migrate their products to HTTPS. 242 That has security benefits for those third-party products themselves, 243 but also has the effect of removing the potential of mixed content 244 ([mixed-content]) as a blocker to first-party migration to HTTPS. 246 Note that in the long term, it seems quite reasonable to take the 247 additional step of requiring the "Secure" attribute for all cookies, 248 regardless of their "SameSite" value. That would have more 249 substantial impact on pervasive monitoring and network attackers 250 generally. This document's proposal limits itself to "SameSite=None" 251 because that seems like a low-hanging, high-value change that's 252 deployable in the near term. User agents are encouraged to find 253 additional subsets for which "Secure" can be required. 255 4.3. Tracking 257 The proposals in this document do not in themselves mitigate the 258 privacy risks described in Section 7.1 of [RFC6265bis]. Entities who 259 wish to use cookies to track user activity from cross-site contexts 260 can continue to do so by setting cookies that declare themselves as 261 "SameSite=None". 263 Requiring that explicit declaration, however, gives user agents the 264 ability to easily distinguish cookies used for stateful cross-site 265 requests from those with narrower scope. After the change proposed 266 in Section 3.1, only those cookies that make an explicit 267 "SameSite=None" declaration can be directly used for cross-site 268 tracking. It may make sense for user agents to use that information 269 to give users different controls for these cookies, or to apply 270 different policies for expiration and delivery. 272 5. Implementation Considerations 274 5.1. Sequencing 276 The steps described in this document don't need to be taken at the 277 same time. It's quite possible that it will be less disruptive to 278 deploy "SameSite=Lax" as a default first, and then to require the 279 "Secure" attribute for any explicitly "SameSite=None" cookie as a 280 subsequent step. 282 User agents are encouraged to adopt these recommendations in whatever 283 order they believe will lead to the widest, most expedient 284 deployment. 286 5.2. Deployment 288 It's possible that a middle-ground between "SameSite=Lax" and 289 "SameSite=None" could be a better balance between doing what 290 developers want by default, and mitigating CSRF by default. 291 [I-D.west-cookie-samesite-firstparty] explores the possibility of 292 integrating First-Party Sets [first-party-set] with the "SameSite" 293 attribute in order to allow entities that shard themselves across 294 multiple registrable domains to maintain stateful communication 295 between them (to support single-sign on, for example). 297 It's possible that user agents who support First-Party Sets could 298 reduce the deployment overhead for developers, and increase the 299 robustness of a site's CSRF defense for cross-site-but-not-cross- 300 party cookies by defaulting to something like that document's 301 "FirstPartyLax" instead of "Lax". 303 6. IANA Considerations 305 This document has no IANA actions. 307 7. References 309 7.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 317 Specifications: ABNF", STD 68, RFC 5234, 318 DOI 10.17487/RFC5234, January 2008, 319 . 321 [RFC6265bis] 322 Barth, A. and M. West, "Cookies: HTTP State Management 323 Mechanism", draft-ietf-httpbis-rfc6265bis-03 (work in 324 progress), April 2019. 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 7.2. Informative References 332 [first-party-set] 333 West, M., "First-Party Sets", n.d., 334 . 336 [HTTP-Workshop-2019] 337 Nottingham, M., "HTTP Workshop 2019: Report", April 2019, 338 . 341 [I-D.west-cookie-samesite-firstparty] 342 West, M., "First-Party Sets and SameSite Cookies", May 343 2019, . 346 [I-D.west-http-state-tokens] 347 West, M., "HTTP State Tokens", draft-west-http-state- 348 tokens-00 (work in progress), March 2019. 350 [mixed-content] 351 West, M., "Mixed Content", n.d., 352 . 354 [pref-cookie] 355 Soltani, A., Peterson, A., and B. Gellman, "NSA uses 356 Google cookies to pinpoint targets for hacking", December 357 2013, . 361 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 362 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 363 2014, . 365 Acknowledgments 367 Conversations with a number of folks at 2019's HTTP Workshop helped 368 me clarify my thinking around the incremental improvements we can 369 make to cookies. In particular, Martin Thomson and Anne van Kesteren 370 provided insightful feedback. 372 Author's Address 373 Mike West 374 Google 376 Email: mkwst@google.com 377 URI: https://www.mikewest.org/