idnits 2.17.1 draft-west-cookie-samesite-firstparty-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. ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-httpbis-RFC6265bis]), 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 1787 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) == Unused Reference: 'I-D.west-http-state-tokens' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 374, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-httpbis-rfc6265bis-03 Summary: 3 errors (**), 0 flaws (~~), 5 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 First-Party Sets and SameSite Cookies 8 draft-west-cookie-samesite-firstparty-00 10 Abstract 12 This document proposes the addition of two new values to the 13 "SameSite" cookie attribute defined in RFC6265bis 14 [I-D.ietf-httpbis-rfc6265bis]: "FirstPartyLax" and 15 "FirstPartyStrict". These values are conceptually similar to the 16 existing "Lax" and "Strict" values, but base the delivery checks on 17 the First-Party Sets [first-party-set] of a request's initiator and 18 target, rather than on their respective registrable domains. This 19 widens the scope of a given cookie's applicability, enabling entities 20 that have sharded themselves across multiple registrable domains to 21 maintain HTTP state without exposing themselves to the risks of 22 "SameSite=None". 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 8, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The "FirstParty" value of the "SameSite" attribute . . . . . 4 64 4. Security and Privacy Considerations . . . . . . . . . . . . . 7 65 4.1. CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Secure Transport . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 6.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The "SameSite" attribute enables developers to limit the scope of a 77 given cookie's delivery, mitigating the risks of some classes of 78 cross-site request forgery (CSRF) attack by preventing certain 79 cookies from being delivered along with requests that are initiated 80 from a cross-site context. 82 For example, consider the exciting and dynamic "https://internet- 83 bookstore.example/", which uses "SameSite=Lax" cookies as one layer 84 in its defense against CSRF attack. If "https://example.com" 85 includes resources from "https://internet-bookstore.example/", the 86 request will be considered cross-site, and the authentication cookies 87 will not be delivered. Without that state, CSRF attacks will be 88 significantly less effective. 90 When the site expands into new locations, it may wish to register a 91 domain under a localized TLD, perhaps "https://internet- 92 bookstore.测试/". Likewise, it may decide to shard 93 itself into distinct brands, like "https://internet-things-other- 94 than-books-store.example/". Though the same entity controls each of 95 these origins, they have distict registrable domains, and therefore 96 the authentication cookie noted above will not be delivered from one 97 site to resources on another. This frustrates a number of reasonable 98 use cases, including single-sign on. Today, "SameSite=None" is 99 necessary in order to support these use cases by enabling a given 100 cookie to be delivered across registrable domains. "SameSite=None", 101 unfortunately, exposes the site to more risk than it would prefer, as 102 it removes a layer of CSRF defense. 104 First-Party Sets [first-party-set] proposes a mechanism by which 105 developers can bind each of their distinct registrable domains into a 106 set which mutually agrees to be treated as a single entity. It would 107 be helpful if this concept could be folded into the "SameSite" 108 attribute, perhaps via new "FirstPartyLax" and "FirstPartyStrict" 109 values. These could be conceptually similar to the existing "Lax" 110 and "Strict" values, but base their delivery checks on the First- 111 Party Sets of a given request's initiator and target, rather than on 112 their respective registrable domains. 114 This document spells out that proposal in a bit more detail. 116 2. Conventions and Definitions 118 2.1. Conformance 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 2.2. Syntax 128 This document adjusts some syntax from [I-D.ietf-httpbis-rfc6265bis], 129 and in doing so, relies upon the Augmented Backus-Naur Form (ABNF) 130 notation of [RFC5234]. 132 2.3. Terms 134 HTTP requests are considered "same-site" or "cross-site", as defined 135 in [I-D.ietf-httpbis-rfc6265bis]. 137 First-Party Sets are defined in [first-party-set]. Two origins ("A" 138 and "B") are said to be in the same first-party set if the first- 139 party set associated with "A" contains "B". 141 A request is considered to be "first-party" if the target origin is 142 in the same first-party set as the request's initiator, and "third- 143 party" otherwise. That is, for a given request ("r"), the following 144 algorithm returns "first-party" or "third-party": 146 1. If "request" is "same-site", return "first-party". 148 2. Let "target" be "r"'s current URL's origin. 150 3. If "target" is in the same first-party set as "r"'s client's 151 origin, return "first-party". 153 4. Return "third-party". 155 A document is considered "first-party with its ancestors" if its 156 origin is in the same First-Party Set with the origins of each of the 157 document's ancestors [HTML]. That is, for a given document ("d"), 158 the following algorithm returns "first-party" or "third-party": 160 1. If "d"'s browsing context is a top-level browsing context, return 161 "first-party". 163 2. Let "set" be "d"'s origin's First-Party Set. 165 3. For each "ancestor" in "d"'s browsing context's ancestor browsing 166 contexts: 168 1. If "ancestor"'s active document's origin is not contained 169 within "set", return "third-party". 171 4. Return "first-party". 173 ISSUE: Move these definitions to the First-Party Sets spec, when one 174 exists. 176 3. The "FirstParty" value of the "SameSite" attribute 178 [I-D.ietf-httpbis-rfc6265bis] defines three values for cookies' 179 "SameSite" attribute: "None", which enables delivery for same-site 180 and cross-site requests; "Strict", which enables delivery only for 181 same-site requests; and "Lax", which enables delivery for same-site 182 requests as well as for cross-site top-level navigations. 184 In the presence of first-party sets, it makes sense to extend this 185 syntax a bit to include "FirstParty", which will allow delivery of 186 cookies within a first-party set, and therefore will support the use 187 cases that first-party sets addresses (a given first-party's single 188 sign-on, for instance). For example, given two distinct origins 189 "https://sso.example/" and "https://application.example/" that are 190 contained in the same first-party set: 192 o Requests from "https://application.example/" to 193 "https://sso.example/" may not contain any cookies set with 194 "SameSite=Lax" or "SameSite=Strict", but only those set as 195 "SameSite=None". 197 o Requests from "https://application.example/" to 198 "https://sso.example/" may contain any cookies set with 199 "SameSite=FirstParty" or "SameSite=None". 201 To implement this change, adjust [I-D.ietf-httpbis-rfc6265bis] as 202 follows: 204 First, change the "samesite-value" definition from: 206 samesite-value = "Strict" / "Lax" / "None" 208 to: 210 samesite-value = "Lax" / "Strict" / "FirstPartyLax" / "FirstPartyStrict" / "None" 212 Second, alter the "SameSite" attribute's processing algorithm 213 (Section 5.3.7 of [I-D.ietf-httpbis-rfc6265bis]) to add a new step 4 214 and 5: 216 4. If cookie-av's attribute-value is a case-insensitive 217 match for "FirstPartyLax", set `enforcement` to "FirstPartyLax". 219 5. If cookie-av's attribute-value is a case-insensitive 220 match for "FirstPartyStrict", set `enforcement` to "FirstPartyStrict". 222 Third, alter the cookie storage model (Section 5.4 of 223 [I-D.ietf-httpbis-rfc6265bis]) as follows: 225 Change step 14.1 from: 227 1. If the cookie was received from a "non-HTTP" API, and 228 the API was called from a context whose "site for 229 cookies" is not an exact match for request-uri's host's 230 registered domain, then abort these steps and ignore the 231 newly created cookie entirely. 233 to: 235 1. If the cookie was received from a "non-HTTP" API: 237 1. If the cookie's `same-site-flag` is "Lax" or 238 "Strict", and the API was called from a context 239 whose "site for cookies" is not an exact match for 240 request-uri's host's registered domain, then abort 241 these steps and ignore the newly-created cookie 242 entirely. 244 2. If the cookie's same-site-flag` is "FirstPartyLax" 245 or "FirstPartyStrict", and the API was called from 246 a context that is not first-party with its 247 ancestors, then abort these steps and ignore the 248 newly-created cookie entirely. 250 Change step 14.2 from: 252 2. If the cookie was received from a "same-site" request, 253 skip the remaining substeps and continue processing the 254 cookie. 256 to: 258 2. If the cookie's `same-site-flag` is "Lax" or "Strict", 259 and the cookie was received from a "same-site" request, 260 then skip the remaining substeps and continue processing 261 the cookie. 263 Add a new step 14.3 after the new step 14.2: 265 3. If the cookie's `same-site-flag` is "FirstPartyLax" or 266 "FirstPartyStrict", and the cookie was received from a 267 "first-party" request, then skip the remaining substeps 268 and continue processing the cookie. 270 Fourth, alter the last conditional in step 1 if the "Cookie" header 271 algorithm (Section 5.5 of [I-D.ietf-httpbis-rfc6265bis]) from: 273 * If the cookie's same-site-flag is not "None", and the 274 HTTP request is cross-site then exclude the cookie 275 unless all of the following statements hold: 277 1. The same-site-flag is "Lax". 279 2. The HTTP request's method is "safe". 281 3. The HTTP request's target browsing context is a 282 top-level browsing context. 284 to: 286 * If the HTTP request is cross-site, then exclude the 287 cookie unless one of the following statements holds: 289 1. The cookie's `same-site-flag` is "None". 291 2. The cookie's `same-site-flag` is either "Lax" or 292 "FirstPartyLax", the HTTP request's method is 293 "safe", and the HTTP request's target browsing 294 context is a top-level browsing context. 296 3. The cookie's `same-site-flag` is either 297 "FirstPartyLax" or "FirstPartyStrict", and the HTTP 298 request is a first-party request. 300 4. Security and Privacy Considerations 302 4.1. CSRF 304 Both "FirstPartyLax" and "FirstPartyStrict" provide weaker defenses 305 against CSRF than their "Lax" and "Strict" counterparts, as they 306 enable authenticated requests from a larger set of initiating 307 contexts. That said, they also provide deployment benefits, as 308 they're usable in some contexts where "Lax" and "Strict" would be too 309 restrictive (e.g. the localized registrable domains in the 310 introduction). 312 4.2. Secure Transport 314 First-Party Sets can only be created for secure origins, as 315 unauthenticated transport doesn't give any guarantees that the 316 assertions we use to build the set are in fact being delivered by the 317 entity which controls the server. This has the side-effect of 318 ensuring that "FirstPartyLax" and "FirstPartyStrict" cookies can only 319 be delivered to secure cross-site origins, which has the exciting 320 side effect of providing limited mitigation of monitoring by network 321 attackers [RFC7258]. 323 5. IANA Considerations 325 This document has no IANA actions. 327 6. References 328 6.1. Normative References 330 [first-party-set] 331 West, M., "First-Party Sets", n.d., 332 . 334 [I-D.ietf-httpbis-rfc6265bis] 335 Barth, A. and M. West, "Cookies: HTTP State Management 336 Mechanism", draft-ietf-httpbis-rfc6265bis-03 (work in 337 progress), April 2019. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 345 Specifications: ABNF", STD 68, RFC 5234, 346 DOI 10.17487/RFC5234, January 2008, 347 . 349 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 350 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 351 May 2017, . 353 6.2. Informative References 355 [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, 356 P., and D. Denicola, "HTML", n.d., 357 . 359 [I-D.west-http-state-tokens] 360 West, M., "HTTP State Tokens", draft-west-http-state- 361 tokens-00 (work in progress), March 2019. 363 [mixed-content] 364 West, M., "Mixed Content", n.d., 365 . 367 [pref-cookie] 368 Soltani, A., Peterson, A., and B. Gellman, "NSA uses 369 Google cookies to pinpoint targets for hacking", December 370 2013, . 374 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 375 DOI 10.17487/RFC6265, April 2011, 376 . 378 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 379 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 380 2014, . 382 Acknowledgments 384 Conversations with a number of folks at 2019's HTTP Workshop helped 385 me clarify my thinking around the incremental improvements we can 386 make to cookies. In particular, Martin Thomson and Anne van Kesteren 387 provided insightful feedback. 389 Author's Address 391 Mike West 392 Google 394 Email: mkwst@google.com 395 URI: https://www.mikewest.org/