idnits 2.17.1
draft-west-cookie-incrementalism-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 a Security Considerations section.
** There are 5 instances of too long lines in the document, the longest one
being 29 characters in excess of 72.
** 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 date (March 15, 2020) is 1502 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)
-- Possible downref: Non-RFC (?) normative reference: ref. 'HTML'
== Outdated reference: A later version (-13) exists of
draft-ietf-httpbis-rfc6265bis-05
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
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 March 15, 2020
5 Expires: September 16, 2020
7 Incrementally Better Cookies
8 draft-west-cookie-incrementalism-01
10 Abstract
12 This document proposes a few 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". Third, same-site should take the scheme of the
18 sites into account. Fourth, cookies should respect schemes. Fifth,
19 cookies associated with non-secure schemes should be removed at the
20 end of a user's session. Sixth, the definition of a session should
21 be tightened.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on September 16, 2020.
40 Copyright Notice
42 Copyright (c) 2020 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
59 2.1. Conformance . . . . . . . . . . . . . . . . . . . . . . . 4
60 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 3. Monkey-Patches against RFC6265bis . . . . . . . . . . . . . . 4
62 3.1. "Lax" by Default . . . . . . . . . . . . . . . . . . . . 4
63 3.1.1. "Lax-Allowing-Unsafe" Enforcement . . . . . . . . . . 6
64 3.2. Requiring "Secure" for "SameSite=None" . . . . . . . . . 8
65 3.3. Schemeful Same-Site . . . . . . . . . . . . . . . . . . . 8
66 3.4. Scheming Cookies . . . . . . . . . . . . . . . . . . . . 9
67 3.5. Evict Non-Secure Cookies . . . . . . . . . . . . . . . . 11
68 3.6. Session Lifetime . . . . . . . . . . . . . . . . . . . . 11
69 4. Security and Privacy Considerations . . . . . . . . . . . . . 13
70 4.1. CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . 13
71 4.2. Secure Transport . . . . . . . . . . . . . . . . . . . . 13
72 4.3. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 14
73 5. Implementation Considerations . . . . . . . . . . . . . . . . 14
74 5.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 14
75 5.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 15
76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
78 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
79 7.2. Informative References . . . . . . . . . . . . . . . . . 16
80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
83 1. Introduction
85 The HTTP State Tokens proposal ([I-D.west-http-state-tokens]) aims to
86 replace cookies with a state management mechanism that has better
87 security and privacy properties. That proposal is somewhat
88 aspirational: it's going to take a long time to come to agreement on
89 the exact contours of a cookie replacement, and an even longer time
90 to actually do so.
92 While we're debating the details of a new state management primitive,
93 it seems quite reasonable to reevaluate some aspects of the existing
94 primitive: cookies. When we can find consensus on some aspect of
95 HTTP State Tokens, we can apply those aspirations to cookies, driving
96 incremental improvements to state management in the status quo.
98 Based on conversations at [HTTP-Workshop-2019] and elsewhere, I'd
99 suggest that we have something like agreement on at least three
100 principles:
102 1. HTTP requests should not carry state along with cross-site
103 requests by default (see Section 8.2 of [RFC6265bis]).
105 2. HTTP requests should not carry state over non-secure channels
106 (see Section 8.3 of [RFC6265bis], and [RFC7258]).
108 3. Non-secure channels should not be able to infuence the state of
109 securely-transported content (see Sections 8.3, 8.5, and 8.6 of
110 [RFC6265bis]).
112 With those principles in mind, this document proposes a few changes
113 that seem possible to deploy in the near-term. User agents should:
115 1. Treat the lack of an explicit "SameSite" attribute as
116 "SameSite=Lax". That is, the "Set-Cookie" value "key=value" will
117 produce a cookie equivalent to "key=value; SameSite=Lax".
118 Cookies that require cross-site delivery can explicitly opt-into
119 such behavior by asserting "SameSite=None" when creating a
120 cookie.
122 This is spelled out in more detail in Section 3.1.
124 2. Require the "Secure" attribute to be set for any cookie which
125 asserts "SameSite=None" (similar conceptually to the behavior for
126 the "__Secure-" prefix). That is, the "Set-Cookie" value
127 "key=value; SameSite=None; Secure" will be accepted, while
128 "key=value; SameSite=None" will be rejected.
130 This is spelled out in more detail in Section 3.2.
132 3. Require both the scheme and registrable domain of a request's
133 client's "site for cookies" to match the target URL when deciding
134 whether a given request is considered same-site. That is, a
135 request initiated from "http://site.example" to
136 "https://site.example" should be considered cross-site.
138 This is spelled out in more detail in Section 3.3.
140 4. Separate cookies by scheme. That is, a given cookie set from
141 "http://example.com/" should be considered distinct from the same
142 cookie set from "https://example.com/", preventing the former
143 from influencing the state of the latter.
145 This is spelled out in more detail in Section 3.4.
147 5. Evict non-secure cookies when a user's session on a non-secure
148 site ends, thereby reducing the timespan over which a user
149 broadcasts a stable identifier to the network.
151 This is spelled out in more detail in Section 3.5.
153 6. Tighten the definition of a user's "session" with heuristics that
154 better represent users' expectations.
156 This is spelled out in more detail in Section 3.6.
158 2. Conventions and Definitions
160 2.1. Conformance
162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
164 "OPTIONAL" in this document are to be interpreted as described in
165 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
166 capitals, as shown here.
168 2.2. Syntax
170 This document adjusts some syntax from [RFC6265bis], and in doing so,
171 relies upon the Augmented Backus-Naur Form (ABNF) notation of
172 [RFC5234].
174 3. Monkey-Patches against RFC6265bis
176 3.1. "Lax" by Default
178 The processing algorithm in Section 5.3.7 of [RFC6265bis] treats the
179 absence of a "SameSite" attribute in a "Set-Cookie" header as
180 equivalent to the presence of "SameSite=None". Cookies are therefore
181 available for cross-site delivery by default, and developers may opt-
182 into more security by setting some other value explicitly. Ideally,
183 we'd invert that such that developers who accepted the risks of
184 cross-site delivery (see Section 8.2 of [RFC6265bis]) could opt into
185 them, while developers who didn't make any explicit choice would be
186 protected by default.
188 We could accomplish this goal by first altering the processing
189 algorithm, replacing the current step 1:
191 1. Let "enforcement" be "None".
193 with the following two steps:
195 1. Let "enforcement" be "Default".
197 2. If cookie-av's attribute-value is a case-insensitive
198 match for "None", set "enforcement" to "None".
200 And then by, altering step 13 of the cookie storage model
201 (Section 5.4 of [RFC6265bis]) from:
203 13. If the cookie-attribute-list contains an attribute
204 with an attribute-name of "SameSite", set the cookie's
205 same-site-flag to attribute-value (i.e. either "Strict",
206 "Lax", or "None"). Otherwise, set the cookie's
207 same-site-flag to "None".
209 to:
211 13. If the cookie-attribute-list contains an attribute
212 with an attribute-name of "SameSite" and an
213 attribute-value of "Strict", "Lax", or "None", set the
214 cookie's same-site-flag to attribute-value. Otherwise,
215 set the cookie's same-site-flag to "Default".
217 And finally by altering the fifth bullet point of step 1 of the
218 cookie-string construction algorithm in Section 5.5 of [RFC6265bis]
219 from:
221 * If the cookie's same-site-flag is not "None", and the HTTP
222 request is cross-site (as defined in Section 5.2) then exclude
223 the cookie unless all of the following statements hold:
225 1. The same-site-flag is "Lax"
227 2. The HTTP request's method is "safe".
229 3. The HTTP request's target browsing context is a top-level
230 browsing context.
232 to:
234 * If the cookie's same-site-flag is not "None", and the HTTP
235 request is cross-site (as defined in Section 5.2) then exclude
236 the cookie unless all of the following statements hold:
238 1. The same-site-flag is "Lax" or "Default".
240 2. The HTTP request's method is "safe".
242 3. The HTTP request's target browsing context is a top-level
243 browsing context.
245 This would have the effect of mapping the default behavior in the
246 absence of an explicit "SameSite" attribute, as well as the presence
247 of any unknown "SameSite" value, to the "Lax" behavior, protecting
248 developers by making cross-site delivery an explicit choice, as
249 opposed to an implicit default.
251 3.1.1. "Lax-Allowing-Unsafe" Enforcement
253 The "Lax" enforcement mode described in Section 5.3.7.1 of
254 [RFC6265bis] allows a cookie to be sent along with cross-site
255 requests if and only if they are top-level navigations with a "safe"
256 HTTP method. Implementation experience shows that this is difficult
257 to apply across the board, and it may be reasonable to temporarily
258 carve out cases in which some cookies that rely on today's default
259 behavior can continue to be delivered as the default is shifted to
260 "Lax" enforcement.
262 One such carveout, described in this section, accommodates certain
263 cases in which it may be desirable for a cookie to be excluded from
264 non-top-level cross-site requests, but to be sent with all top-level
265 navigations regardless of HTTP request method.
267 For example, a login flow may involve a cross-site top-level POST
268 request to an endpoint which expects a cookie with login information.
269 For such a cookie, "Lax" enforcement is not appropriate, as it would
270 cause the cookie to be excluded due to the unsafe HTTP request
271 method. On the other hand, "None" enforcement would allow the cookie
272 to be sent with all cross-site requests. For a cookie containing
273 potentially sensitive login information, this may not be desirable.
275 In order to retain some of the protections of "Lax" enforcement (as
276 compared to "None") while still allowing cookies to be sent cross-
277 site with unsafe top-level requests, user agents may choose to
278 provide an intermediate "Lax-allowing-unsafe" enforcement mode. A
279 cookie whose enforcement mode is "Lax-allowing-unsafe" will be sent
280 along with a cross-site request if and only if it is a top-level
281 request, regardless of request method.
283 User agents may choose to apply this enforcement mode instead of
284 "Lax" enforcement, but only in a limited or restricted fashion. Such
285 restrictions may include applying "Lax-allowing-unsafe" only to
286 cookies that did not explicitly specify "SameSite=Lax" (i.e., those
287 whose same-site-flag was set to "Default" by default) with creation-
288 time more recent than a duration of the user agent's choosing (2
289 minutes seems reasonable).
291 This is done by further modifying the previously mentioned fifth
292 bullet point of step 1 of the cookie-string construction algorithm in
293 Section 5.5 of [RFC6265bis] from:
295 * If the cookie's same-site-flag is not "None", and the HTTP
296 request is cross-site (as defined in Section 5.2) then exclude
297 the cookie unless all of the following statements hold:
299 1. The same-site-flag is "Lax" or "Default".
301 2. The HTTP request's method is "safe".
303 3. The HTTP request's target browsing context is a top-level
304 browsing context.
306 to:
308 * If the cookie's same-site-flag is not "None", and the HTTP
309 request is cross-site (as defined in Section 5.2) then exclude
310 the cookie unless all of the following statements hold:
312 1. The same-site-flag is "Lax" or "Default".
314 2. The HTTP request's method is "safe", or the cookie meets
315 the user agent's requirements for being granted
316 "Lax-allowing-unsafe" enforcement.
318 3. The HTTP request's target browsing context is a top-level
319 browsing context.
321 As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe"
322 mode necessarily provides fewer protections against CSRF.
323 Ultimately, the provision of such an enforcement mode should be seen
324 as a temporary measure to ease adoption of "Lax" enforcement by
325 default.
327 3.2. Requiring "Secure" for "SameSite=None"
329 Cookies sent over plaintext HTTP are visible to anyone on the
330 network. As section 8.3 of [RFC6265bis] points out, this visibility
331 exposes substantial amounts of data to network attackers. We know,
332 for example, that long-lived and stable cookies have enabled
333 pervasive monitoring [RFC7258] in the past (see Google's PREF cookie
334 [pref-cookie]), and we know that a secure transport layer provides
335 significant confidentiality protections against this kind of attack.
337 We can, to a reasonable extent, mitigate this threat by ensuring that
338 cookies intended for cross-site delivery (and therefore likely to be
339 more prevalent on the wire than cookies scoped down to same-site
340 requests) require secure transport.
342 That is, we can require that any cookie which asserts "SameSite=None"
343 must also assert the "Secure" attribute (Section 4.1.2.5 of
344 [RFC6265bis]) by altering the storage model defined in Section 5.4 of
345 [RFC6265bis], inserting the following step after the existing step
346 14:
348 15. If the cookie's "same-site-flag" is "None", abort
349 these steps and ignore the cookie entirely unless
350 the cookie's secure-only-flag is true.
352 This is conceptually similar to the requirements put into place for
353 the "__Secure-" prefix (Section 4.1.3.1 of [RFC6265bis]).
355 3.3. Schemeful Same-Site
357 By considering the scheme as well as the registrable domain when
358 determining whether a given request is "same-site", the "SameSite"
359 attribute can protect secure origins from CSRF attacks initiated by a
360 network attacker that can forge requests from a non-secure origin on
361 the same registrable domain. To do so we need to modify a number of
362 things:
364 First change the definition of "site for cookies" from a registrable
365 domain to an origin. In the places where a we return an empty string
366 for a non-existent "site for cookies" we should instead return an
367 origin set to a freshly generated globally unique identifier. Then
368 replace the same-site calculation algorithm with the following:
370 Two origins, A and B, are considered same-site if the following algorithm returns true:
371 1. If A and B are both scheme/host/port triples then
373 1. If A's scheme does not equal B's scheme, return false.
375 2. Let hostA be A's host, and hostB be B's host.
377 3. If hostA equals hostB and hostA's registrable domain is null, return true.
379 4. If hostA's registrable domain equals hostB's registrable domain and is non-null, return true.
381 2. If A and B are both the same globally unique identifier, return true.
383 3. Return false.
385 Note: The port component of the origins is not considered.
387 A request is "same-site" if its target's URI's origin
388 is same-site with the request's client's "site for cookies", or if the
389 request has no client. The request is otherwise "cross-site".
391 Now that we have a new algorithm, we can update any comparision of
392 two sites from "have the same registrable domain" (or "is an exact
393 match for") to say "is same-site".
395 Note: The request's URL when establishing a WebSockets connection has
396 scheme "http" or "https", rather than "ws" or "wss". FETCH maps
397 schemes when constructing the request. This mapping allows same-site
398 cookies to be sent with WebSockets.
400 3.4. Scheming Cookies
402 Cookies are one of the very few components of the web platform that
403 ignore scheme by default. The "Secure" attribute can lock a cookie
404 to secure schemes, and the "__Secure-" prefix can harden that
405 boundary, but these mechanisms are little-used, and cookies lacking
406 these protections flow across scheme boundaries. They are delivered
407 to both the HTTP and HTTPS variants of a given domain, even though
408 their security properties differ radically. As Section 8.6 of
409 [RFC6265bis] points out, this gives network attackers the ability to
410 influence otherwise secured traffic by modifying user state that
411 flows to secure origins, and, of course, insight into user behavior
412 as securely-set cookies that lack the "Secure" attribute likewise
413 flow from secure origins to non-secure variants.
415 We should remedy this defect by storing a "scheme" component along
416 with the cookie, and using that component in cookies' matching
417 algorithms to ensure that secure and non-secure origins' state is
418 clearly distinguishable and separate. This is accomplished as
419 follows:
421 First, alter the Storage Model defined in Section 5.4 of [RFC6265bis]
422 by adding "scheme" to the list of fields the user agent stores about
423 each cookie, and setting it when creating a cookie by altering step 2
424 of the same algorithm from:
426 2. Create a new cookie with name cookie-name, value cookie-value.
427 Set the creation-time and the last-access-time to the current
428 date and time.
430 to:
432 2. Create a new cookie with name cookie-name, value cookie-value.
433 Set the creation-time and the last-access-time to the current
434 date and time. Set the scheme to request-uri's origin's scheme
435 component.
437 Likewise alter step 17 of the same algorithm from:
439 17. If the cookie store contains a cookie with the same name,
440 domain, host-only-flag, and path as the newly-created cookie:
442 to:
444 17. If the cookie store contains a cookie with the same name, scheme,
445 domain, host-only-flag, and path as the newly-created cookie:
447 And step 17.1 from:
449 17.1. Let old-cookie be the existing cookie with the same name,
450 domain, host-only-flag, and path as the newly-created
451 cookie. (Notice that this algorithm maintains the invariant
452 that there is at most one such cookie.)
454 to:
456 17.1. Let old-cookie be the existing cookie with the same name, scheme,
457 domain, host-only-flag, and path as the newly-created
458 cookie. (Notice that this algorithm maintains the invariant
459 that there is at most one such cookie.)
461 Second, alter The Cookie Header algorithm defined in Section 5.5 of
462 [RFC6265bis] to take the "scheme" into account when deciding which
463 cookies to deliver by adding another condition to the list in Step 1
464 of the algorithm:
466 * The cookies' `scheme` matches the scheme component of request-uri's origin.
468 This seems like the minimal set of changes necessary. We could do
469 other cleanup, including removing the "Secure" attribute, as this
470 mechanism obviates it entirely, altering the eviction algorithm to
471 prefer discarding non-secure schemes, etc.
473 3.5. Evict Non-Secure Cookies
475 In the status quo, cookies delivered to non-secure origins are,
476 generally, quite old. Each cookies' age is somewhat representative
477 of its risk: long-lived cookies expose persistent identifiers to the
478 network when delivered non-securely which create tracking
479 opportunities over time. Here, we aim to mitigate this risk by
480 substantially reducing the lifetime of non-secure cookies, thereby
481 limiting the window of opportunity for network attackers.
483 This is similar conceptually to previous proposals, notably
484 [I-D.thomson-http-omnomnom] and [cookies-over-http-bad], but seems
485 like it might be more deployable, especially in conjunction with the
486 scheme changes above.
488 The change is straightforward, requiring the following text to be
489 added to the bottom of Section 5.4 of [RFC6265bis]:
491 ~~~ When "the current session is over", the user agent MUST remove
492 from the cookie store all cookies whose "scheme" component is non-
493 secure. ~~
495 As discussed below in {#session-lifetime}, if we add a site-specific
496 session concept, we can make the following addition:
498 ~~ When "the current session is over" for an origin, the user agent
499 MUST remove from the cookie store all cookies whose "scheme"
500 component is non-secure, and whose "domain" component's registrable
501 domain matches the origin's registrable domain. ~~
503 This still requires the user agent to define a notion of non-
504 secureness, but it would certainly include "http".
506 3.6. Session Lifetime
508 Section 5.4 of [RFC6265bis] defines "the current session is over" by
509 choosing not to define it, instead leaving it up to the user agent.
510 Unfortunately, we have several "session" concepts in user agents
511 today, and it's not clear that any of them are appropriate for
512 cookies. HTML's "sessionStorage" lifetime is tied to a particular
513 top-level browsing context, thereby giving two tabs/windows different
514 views into a page's state. Various user agents' "private mode"
515 create sessions that are scoped in various ways: Chrome's Incognito
516 mode ties a session's lifetime to the closure of the last Incognito
517 window, Safari's private mode's lifetime is tab-specific, etc.
518 Session cookies' lifetime likewise differs between user agents, in
519 some cases based on user-visible settings like Chrome's "Continue
520 where you left off" (which can lead to quite persistent sessions
521 indeed).
523 At some risk of further complicating the notion of a "session", it
524 might be reasonable to learn from existing user agents' work around
525 meeting users' conceptions of when they're using a given site, and to
526 define a recommended heuristic that user agents could adopt. In
527 particular, Chromium's site engagement score and Safari's ITP both
528 track a user's last moment of interaction with a site (which might
529 feasibly include things like navigation, clicks, scrolls, etc). This
530 seems like a useful bit of data to take into account, along with
531 whether or not a user has top-level browsing contexts that include a
532 given site.
534 To that end, we could add a few concepts to [RFC6265bis] to give
535 browser vendors more clarity around a reasonable approach to defining
536 when "the current session is over" for a specific site, rather that
537 for the browsing session as a whole. Something along the following
538 lines makes sense to me:
540 1. User agents should store a timestamp of the last interaction with
541 a given site in a top-level browsing context [HTML]. User agents
542 have a great deal of flexibility in what they consider an
543 interaction, but typing and clicking should probably count.
545 2. Change the "close a browsing context" algorithm [HTML] to call
546 the following algorithm between its existing step 1 and step 2:
548 1. Let "closedOrigin" be the origin of "browsingContext"'s
549 active document.
551 2. For each top-level browsing context "c":
553 1. If "c" is "browsingContext", continue.
555 2. If "c"'s active document's origin is same site with
556 "browsingContext"'s active document's origin, return.
558 3. ASSERT: No top-level browsing context contains a document
559 that's same-site with the document being closed.
561 4. Return, and continue running this algorithm in parallel.
563 5. Wait however long a user would reasonably expect their state
564 to be retained (an hour sounds reasonable).
566 6. For each top-level browsing context "c":
568 1. If "c"'s active document's origin is same site with
569 "closedOrigin", return.
571 7. ASSERT: No top-level browsing context contains a document
572 that's same-site with the document that was closed.
574 8. Trigger "the current session is over" for "closedOrigin".
576 3. Define a new handler for "the current session is over" that takes
577 an origin into account, and clears session cookies for that
578 origin's site.
580 Note that these definitions refer to "site", not "origin", as cookies
581 span an entire registrable domain. Ideally, we'll address that too,
582 but not today.
584 4. Security and Privacy Considerations
586 4.1. CSRF
588 "SameSite" is a reasonably robust defense against some classes of
589 cross-site request forgery attacks, as described in Section 8.8.1 of
590 [RFC6265bis], but developers need to opt-into its protections in
591 order for them to have any effect. That is, developers are
592 vulnerable to CSRF attacks by default, and must do some work to shift
593 themselves into a more defensible position.
595 The change proposed in Section 3.1 would invert that requirement,
596 placing the burden on the small number of developers who are building
597 services that require state in cross-site requests. Those developers
598 would be empowered to opt-into the status quo's less-secure model,
599 while developers who don't intend for their projects to be embedded
600 in cross-site contexts are protected by default.
602 4.2. Secure Transport
604 As discussed in Section 8.3 of [RFC6265bis], cookies delivered over
605 plaintext channels are exposed to intermediaries, and thereby enable
606 pervasive monitoring [RFC7258]. The change proposed in Section 3.2
607 above would set secure transport as a baseline requirement for all
608 stateful cross-site requests, thereby reducing the risk that these
609 cookies can be cataloged or modified by network attackers.
611 Requiring secure transport for cookies intended for cross-site usage
612 has the exciting secondary effect of increasing pressure on entities
613 that produce embeddable content to migrate their products to HTTPS.
614 That has security benefits for those third-party products themselves,
615 but also has the effect of removing the potential of mixed content
616 ([mixed-content]) as a blocker to first-party migration to HTTPS.
618 Note that in the long term, it seems quite reasonable to take the
619 additional step of requiring the "Secure" attribute for all cookies,
620 regardless of their "SameSite" value. That would have more
621 substantial impact on pervasive monitoring and network attackers
622 generally. This document's proposal limits itself to "SameSite=None"
623 because that seems like a low-hanging, high-value change that's
624 deployable in the near term. User agents are encouraged to find
625 additional subsets for which "Secure" can be required.
627 4.3. Tracking
629 The proposals in this document do not in themselves mitigate the
630 privacy risks described in Section 7.1 of [RFC6265bis]. Entities who
631 wish to use cookies to track user activity from cross-site contexts
632 can continue to do so by setting cookies that declare themselves as
633 "SameSite=None".
635 Requiring that explicit declaration, however, gives user agents the
636 ability to easily distinguish cookies used for stateful cross-site
637 requests from those with narrower scope. After the change proposed
638 in Section 3.1, only those cookies that make an explicit
639 "SameSite=None" declaration can be directly used for cross-site
640 tracking. It may make sense for user agents to use that information
641 to give users different controls for these cookies, or to apply
642 different policies for expiration and delivery.
644 5. Implementation Considerations
646 5.1. Sequencing
648 The steps described in this document don't need to be taken at the
649 same time. It's quite possible that it will be less disruptive to
650 deploy "SameSite=Lax" as a default first, then to require the
651 "Secure" attribute for any explicitly "SameSite=None" cookie as a
652 subsequent step, and then deploying schemeful same-site in a final
653 step.
655 User agents are encouraged to adopt these recommendations in whatever
656 order they believe will lead to the widest, most expedient
657 deployment.
659 5.2. Deployment
661 It's possible that a middle-ground between "SameSite=Lax" and
662 "SameSite=None" could be a better balance between doing what
663 developers want by default, and mitigating CSRF by default.
664 [I-D.west-cookie-samesite-firstparty] explores the possibility of
665 integrating First-Party Sets [first-party-set] with the "SameSite"
666 attribute in order to allow entities that shard themselves across
667 multiple registrable domains to maintain stateful communication
668 between them (to support single-sign on, for example).
670 It's possible that user agents who support First-Party Sets could
671 reduce the deployment overhead for developers, and increase the
672 robustness of a site's CSRF defense for cross-site-but-not-cross-
673 party cookies by defaulting to something like that document's
674 "FirstPartyLax" instead of "Lax".
676 6. IANA Considerations
678 This document has no IANA actions.
680 7. References
682 7.1. Normative References
684 [HTML] "HTML", n.d., .
686 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
687 Requirement Levels", BCP 14, RFC 2119,
688 DOI 10.17487/RFC2119, March 1997,
689 .
691 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
692 Specifications: ABNF", STD 68, RFC 5234,
693 DOI 10.17487/RFC5234, January 2008,
694 .
696 [RFC6265bis]
697 West, M. and J. Wilander, "Cookies: HTTP State Management
698 Mechanism", draft-ietf-httpbis-rfc6265bis-05 (work in
699 progress), February 2020.
701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
702 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
703 May 2017, .
705 7.2. Informative References
707 [cookies-over-http-bad]
708 West, M., "Cookies over HTTP Bad", April 2018,
709 .
711 [first-party-set]
712 West, M., "First-Party Sets", n.d.,
713 .
715 [HTTP-Workshop-2019]
716 Nottingham, M., "HTTP Workshop 2019: Report", April 2019,
717 .
720 [I-D.thomson-http-omnomnom]
721 Thomson, M. and C. Peterson, "Expiring Aggressively Those
722 HTTP Cookies", draft-thomson-http-omnomnom-00 (work in
723 progress), May 2016.
725 [I-D.west-cookie-samesite-firstparty]
726 West, M., "First-Party Sets and SameSite Cookies", draft-
727 west-cookie-samesite-firstparty-01 (work in progress), May
728 2019.
730 [I-D.west-http-state-tokens]
731 West, M., "HTTP State Tokens", draft-west-http-state-
732 tokens-00 (work in progress), March 2019.
734 [mixed-content]
735 West, M., "Mixed Content", n.d.,
736 .
738 [pref-cookie]
739 Soltani, A., Peterson, A., and B. Gellman, "NSA uses
740 Google cookies to pinpoint targets for hacking", December
741 2013, .
745 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
746 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
747 2014, .
749 Acknowledgments
751 Conversations with a number of folks at 2019's HTTP Workshop helped
752 me clarify my thinking around the incremental improvements we can
753 make to cookies. In particular, Martin Thomson and Anne van Kesteren
754 provided insightful feedback.
756 Lily Chen has been instrumental in initial deployments of the
757 "SameSite" changes described in Section 3.1 and Section 3.2, proving
758 that incremental changes to cookies can be successfully shipped.
760 Steven Bingler contributed the "Schemeful SameSite" proposal
761 described in Section 3.3.
763 Author's Address
765 Mike West
766 Google
768 Email: mkwst@google.com
769 URI: https://www.mikewest.org/