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/