idnits 2.17.1 

draft-west-first-party-cookies-03.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 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 (May 13, 2015) is 3270 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'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'PSL'

  ** Downref: Normative reference to an Informational RFC: RFC 7034

  ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SERVICE-WORKERS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'WORKERS'


     Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	HTTPbis                                                          M. West
3	Internet-Draft                                               Google, Inc
4	Updates: 6265 (if approved)                                 May 13, 2015
5	Intended status: Standards Track
6	Expires: November 14, 2015

8	                        First-Party-Only Cookies
9	                   draft-west-first-party-cookies-03

11	Abstract

13	   This document updates RFC6265 by defining a "First-Party-Only"
14	   attribute which allows servers to assert that a cookie ought to be
15	   sent only in a "first-party" context.  This assertion allows user
16	   agents to mitigate the risk of cross-origin information leakage, and
17	   provides some minimal protection against cross-site request forgery
18	   attacks.

20	Status of This Memo

22	   This Internet-Draft is submitted in full conformance with the
23	   provisions of BCP 78 and BCP 79.

25	   Internet-Drafts are working documents of the Internet Engineering
26	   Task Force (IETF).  Note that other groups may also distribute
27	   working documents as Internet-Drafts.  The list of current Internet-
28	   Drafts is at http://datatracker.ietf.org/drafts/current/.

30	   Internet-Drafts are draft documents valid for a maximum of six months
31	   and may be updated, replaced, or obsoleted by other documents at any
32	   time.  It is inappropriate to use Internet-Drafts as reference
33	   material or to cite them other than as "work in progress."

35	   This Internet-Draft will expire on November 14, 2015.

37	Copyright Notice

39	   Copyright (c) 2015 IETF Trust and the persons identified as the
40	   document authors.  All rights reserved.

42	   This document is subject to BCP 78 and the IETF Trust's Legal
43	   Provisions Relating to IETF Documents
44	   (http://trustee.ietf.org/license-info) in effect on the date of
45	   publication of this document.  Please review these documents
46	   carefully, as they describe your rights and restrictions with respect
47	   to this document.  Code Components extracted from this document must
48	   include Simplified BSD License text as described in Section 4.e of
49	   the Trust Legal Provisions and are provided without warranty as
50	   described in the Simplified BSD License.

52	Table of Contents

54	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
55	     1.1.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
56	     1.2.  Limitations . . . . . . . . . . . . . . . . . . . . . . .   3
57	     1.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
58	   2.  Terminology and notation  . . . . . . . . . . . . . . . . . .   4
59	     2.1.  First-party and Third-party Requests  . . . . . . . . . .   5
60	       2.1.1.  Document-based requests . . . . . . . . . . . . . . .   5
61	       2.1.2.  Worker-based requests . . . . . . . . . . . . . . . .   7
62	   3.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   8
63	     3.1.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . .   8
64	     3.2.  Semantics of the "First-Party-Only" Attribute (Non-
65	           Normative)  . . . . . . . . . . . . . . . . . . . . . . .   9
66	   4.  User Agent Requirements . . . . . . . . . . . . . . . . . . .   9
67	     4.1.  The "First-Party-Only" attribute  . . . . . . . . . . . .   9
68	     4.2.  Monkey-patching the Storage Model . . . . . . . . . . . .   9
69	     4.3.  Monkey-patching the "Cookie" header . . . . . . . . . . .  10
70	   5.  Authoring Considerations  . . . . . . . . . . . . . . . . . .  10
71	     5.1.  Mashups and Widgets . . . . . . . . . . . . . . . . . . .  10
72	   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
73	   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
74	     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
75	     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
76	   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  12
77	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

79	1.  Introduction

81	   Section 8.2 of [RFC6265] eloquently notes that cookies are a form of
82	   ambient authority, attached by default to requests the user agent
83	   sends on a user's behalf.  Even when an attacker doesn't know the
84	   contents of a user's cookies, she can still execute commands on the
85	   user's behalf (and with the user's authority) by asking the user
86	   agent to send HTTP requests to unwary servers.

88	   Here, we update [RFC6265] with a simple mitigation strategy that
89	   allows servers to declare certain cookies as "First-party-only",
90	   meaning they should be attached to requests if and only if those
91	   requests occur in a first-party context (as defined in section 2.1).

93	   Note that the mechanism outlined here is backwards compatible with
94	   the existing cookie syntax.  Servers may serve first-party cookies to
95	   all user agents; those that do not support the "First-Party-Only"
96	   attribute will simply store a cookie which is returned in all
97	   applicable contexts, just as they do today.

99	1.1.  Goals

101	   These first-party-only cookies are intended to provide a solid layer
102	   of defense-in-depth against attacks which require embedding an
103	   authenticated request into an attacker-controlled context:

105	   1.  Timing attacks which yield cross-origin information leakage (such
106	       as those detailed in [pixel-perfect]) can be substantially
107	       mitigated by setting the "First-Party-Only" attribute on
108	       authentication cookies.  The attacker will only be able to embed
109	       unauthenticated resources, as embedding mechanisms such as
110	       "<iframe>" will not create first-party contexts.

112	   2.  Cross-site script inclusion (XSSI) attacks are likewise mitigated
113	       by setting the "First-Party-Only" attribute on authentication
114	       cookies.  The attacker will not be able to include authenticated
115	       resources via "<script>" or "<link>", as these embedding
116	       mechanisms will not create first-party contexts.

118	   First-party-only cookies also mitigate one specific kind of cross-
119	   site request forgery (CSRF) attack by treating cross-origin requests
120	   with unsafe methods (including top-level navigations) as as third-
121	   party requests.

123	   Aside from these attack mitigations, first-party-only cookies can
124	   also be useful for policy or regulatory purposes.  That is, it may be
125	   valuable for an origin to assert that its cookies should not be sent
126	   along with third-party requests in order to limit its exposure to
127	   non-technical risk.

129	1.2.  Limitations

131	   First-party-only cookies provide reasonable defense in depth against
132	   CSRF attacks that rely on unsafe HTTP methods (like "POST").  They do
133	   not offer a robust defense against CSRF as a general category of
134	   attack:

136	   1.  Attackers can still pop up new windows or trigger top-level
137	       navigations in order to create a first-party context (as
138	       described in section 2.1), which is only a speedbump along the
139	       road to exploitation.

141	   2.  Features like "<link rel='prerender'>" [prerendering] can be
142	       exploited to create first-party contexts without the risk of user
143	       detection.

145	   In addition to the usual server-side defenses (CSRF tokens, ensuring
146	   that "safe" HTTP methods are idempotent, etc), client-side techniques
147	   such as those described in [app-isolation] may prove effective
148	   against CSRF, and are certainly worth exploring in combination with
149	   first-party-only cookies.  First-party-only cookies on their own,
150	   however, are not a barrier to CSRF attacks as a general category.

152	1.3.  Examples

154	   First-party-only cookies are set via the "First-Party-Only" attribute
155	   in the "Set-Cookie" header field.  That is, given a server's response
156	   to a user agent which contains the following header field:

158	   Set-Cookie: SID=31d4d96e407aad42; First-Party-Only

160	   Subsequent requests from that user agent can be expected to contain
161	   the following header field if and only if both the requested resource
162	   and the resource in the top-level browsing context match the cookie.

164	2.  Terminology and notation

166	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
167	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
168	   document are to be interpreted as described in [RFC2119].

170	   This specification uses the Augmented Backus-Naur Form (ABNF)
171	   notation of [RFC5234].

173	   Two sequences of octets are said to case-insensitively match each
174	   other if and only if they are equivalent under the "i;ascii-casemap"
175	   collation defined in [RFC4790].

177	   The terms "active document", "ancestor browsing context", "browsing
178	   context", "document", "iframe srcdoc document", "parent browsing
179	   context", and "top-level browsing context" are defined in the HTML
180	   Living Standard [HTML].

182	   "Web Workers", "dedicated workers", "owner document", "list of
183	   relevant documents", and "shared workers" are defined in the Web
184	   Workers specification [WORKERS].

186	   "Service Workers" are defined in the Service Workers specification
187	   [SERVICE-WORKERS].

189	   The term "origin", the mechanism of deriving an origin from a URI,
190	   and the "the same" matching algorithm for origins are defined in
191	   [RFC6454].

193	   "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
194	   defined in Section 4.2.1 of [RFC7231].

196	   The term "public suffix" is defined in a note in Section 5.3 of
197	   [RFC6265] as "a domain that is controlled by a public registry".  For
198	   example, "example.com"'s public suffix is "com".  User agents SHOULD
199	   use an up-to-date public suffix list, such as the one maintained by
200	   Mozilla at [PSL].

202	   An origin's "registerable domain" is the origin's host's public
203	   suffix plus the label to its left.  That is,
204	   "https://www.example.com"'s registerable domain is "example.com".
205	   This concept is defined more rigorously in [PSL].

207	2.1.  First-party and Third-party Requests

209	2.1.1.  Document-based requests

211	   When considering a request generated while parsing a document, or
212	   executing script in its context, we need to consider the document's
213	   origin as well as the origin of each of it's ancestors, in order to
214	   determine whether the request should be considered "first-party".

216	   For this kind of request, the URI displayed in a user agent's address
217	   bar is the only security context directly exposed to users, and
218	   therefore the only signal users can reasonably rely upon to determine
219	   whether or not they trust a particular website.  The origin of that
220	   URI is, therefore, the "first-party origin".

222	   In order to prevent the kinds of "multiple-nested scenarios"
223	   described in Section 4 of [RFC7034], we must check the first-party
224	   origin against the origins of each of a document's ancestor browsing
225	   contexts' active documents.  A document is considered a "first-party
226	   context" if and only if the registerable domain of the origin of its
227	   URI is the same as the registerable domain of the first-party origin,
228	   *and* if each of the active documents in its ancestors' browsing
229	   contexts' is a first-party context.

231	   This definition has a few implications:

233	   o  New windows create new first-party contexts (as the active
234	      document is rendered into a top-level browsing context).

236	   o  Full-page navigations create new first-party contexts.  Notably,
237	      this includes both HTTP and "<meta>"-driven redirects.

239	   o  "<iframe>"s do not create new first-party contexts; their requests
240	      MUST be considered in the context of the origin of the URL the
241	      user actually sees in the user agent's address bar.

243	   To be more precise, given an HTTP request "request", the following
244	   algorithm returns "First-Party" if "request" is a first-party
245	   request, and "Third-Party" otherwise:

247	   1.  Let "document" be the document responsible for "request".

249	   2.  If "document" is a first-party context, and "request"'s URI's
250	       origin's registerable domain is the same the registerable domain
251	       of the origin of the URI of the active document in the top-level
252	       browsing context of "document", then return "First-Party".

254	   3.  Return "Third-Party".

256	   Given a Document "document", the following algorithm returns "First-
257	   Party" if "document" is a first-party context, and "Third-Party"
258	   otherwise:

260	   1.  Let "top-origin" be the origin of the URI of the active document
261	       in the top-level browsing context of the document responsible for
262	       "request".

264	   2.  If "document"'s URI's origin is not "top-origin", return "Third-
265	       Party".

267	   3.  While "document" has a parent browsing context:

269	       1.  Let "document" be "document"'s parent browsing context's
270	           active document.

272	       2.  If "document"'s URI's origin does not have the same
273	           registerable domain as "top-origin" and "document" is not an
274	           iframe srcdoc document, return "Third-Party".

276	   4.  Return "First-Party".

278	   Note that we deal with the document's location in steps 2, 3, and 4.2
279	   above, not with the document's origin.  For example, a top-level
280	   document from "https://example.com" which has been sandboxed into a
281	   unique origin still creates a non-unique first-party context for
282	   subsequent requests.

284	2.1.2.  Worker-based requests

286	   Worker-driven requests aren't as clear-cut as document-driven
287	   requests, as there isn't a clear link between a top-level browsing
288	   context and a worker.  This is especially true for Service Workers
289	   [SERVICE-WORKERS], which may execute code in the background, without
290	   any document visible at all.

292	   Note: The descriptions below assume that workers must be same-origin
293	   with the documents that instantiate them.  If this invariant changes,
294	   we'll need to take the worker's script's URI into account when
295	   determining their status.

297	2.1.2.1.  Dedicated Workers

299	   Dedicated workers are fairly straightforward to categorize, as each
300	   dedicated worker is bound to one and only one Document.  Requests
301	   generated from a dedicated worker (via "importScripts",
302	   "XMLHttpRequest", "fetch()", and so on) are first-party requests if
303	   and only if the worker's owner document is a first-party context.

305	   To be more precise, given an HTTP request "request", the following
306	   algorithm returns "First-Party" if "request" is a first-party
307	   request, and "Third-Party" otherwise:

309	   1.  Let "worker" be the dedicated worker responsible for "request".

311	   2.  Let "document" be "worker"'s owner document.

313	   3.  If "document" is a first-party context, and "request"'s URI's
314	       origin's registerable domain is the same as the registerable
315	       domain of the origin of the URI of the active document in the
316	       top-level browsing context of "document", then return "First-
317	       Party".

319	   4.  Return "Third-Party".

321	2.1.2.2.  Shared Workers

323	   Shared Workers introduce the complexity of bindings to multiple
324	   Documents.  As it is quite possible for a shared worker to be bound
325	   at the same time to one Document that is a first-party context, and
326	   another that isn't, we'll need to walk through all the documents
327	   associated with the worker to determine its status.  If and only if
328	   all associated documents are first-party contexts, then the worker is
329	   a first-party context.

331	   To be more precise, given an HTTP request "request", the following
332	   algorithm returns "First-Party" if "request" is a first-party
333	   request, and "Third-Party" otherwise:

335	   1.  Let "worker" be the dedicated worker responsible for "request".

337	   2.  For each "document" in "worker"'s list of relevant Documents:

339	       1.  Return "Third-Party" if "document" is not a first-party
340	           context (as defined in section 2.1.1).

342	       2.  Return "Third-Party" if "request"'s URI's origin's
343	           registerable domain is not the same as the registerable
344	           domain of the origin of the URI of the active document in the
345	           top-level browsing context of "document".

347	   3.  Return "First-Party".

349	2.1.2.3.  Service Workers

351	   Service Workers are more complex still, as they act as a completely
352	   separate execution context, with very little relationship to the
353	   Document which registered them.

355	   Until we have more implementation experience, we will consider
356	   Service Workers as third-party contexts in all cases.

358	   Note: Requests which simply pass through a service worker will be
359	   handled as described above; the only requests which will be effected
360	   by this categorization are those which the service worker itself
361	   initiates (via "fetch()", for instance).

363	3.  Server Requirements

365	   This section describes extensions to [RFC6265] necessary to implement
366	   the server-side requirements of the "First-Party-Only" attribute.

368	3.1.  Grammar

370	   Add "First-Party-Only" to the list of accepted attributes in the
371	   "Set-Cookie" header field's value by replacing the "cookie-av" token
372	   definition in Section 4.1.1 of [RFC6265] with the following ABNF
373	   grammar:

375	   cookie-av           = expires-av / max-age-av / domain-av /
376	                         path-av / secure-av / httponly-av /
377	                         first-party-only-av / extension-av
378	   first-party-only-av = "First-Party-Only"

380	3.2.  Semantics of the "First-Party-Only" Attribute (Non-Normative)

382	   The "First-Party-Only" attribute limits the scope of the cookie such
383	   that it will only be attached to requests if those requests are
384	   "first-party", as described in Section 2.1.  For example, requests
385	   for "https://example.com/sekrit-image" will attach first-party-only
386	   cookies if and only if the top-level browsing context is currently
387	   displaying a document from "https://example.com".

389	   The changes to the "Cookie" header field suggested in Section 4.3
390	   provide additional detail.

392	4.  User Agent Requirements

394	   This section describes extensions to [RFC6265] necessary in order to
395	   implement the client-side requirements of the "First-Party-Only"
396	   attribute.

398	4.1.  The "First-Party-Only" attribute

400	   The following attribute definition should be considered part of the
401	   the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]:

403	   If the attribute-name case-insensitively matches the string "First-
404	   Party-Only", the user agent MUST append an attribute to the "cookie-
405	   attribute-list" with an "attribute-name" of "First-Party-Only" and an
406	   empty "attribute-value".

408	4.2.  Monkey-patching the Storage Model

410	   Note: There's got to be a better way to specify this.  Until I figure
411	   out what that is, monkey-patching!

413	   Alter Section 5.3 of [RFC6265] as follows:

415	   1.  Add "first-party-only-flag" to the list of fields stored for each
416	       cookie.

418	   2.  Before step 11 of the current algorithm, add the following:

420	       1.  If the "cookie-attribute-list" contains an attribute with an
421	           "attribute-name" of "First-Party-Only", set the cookie's
422	           "first-party-only-flag" to true.  Otherwise, set the cookie's
423	           "first-party-only-flag" to false.

425	       2.  If the cookie's "first-party-only-flag" is set to true, and
426	           the request which generated the cookie is not a first-party
427	           request (as defined in Section 2.1), then abort these steps
428	           and ignore the newly created cookie entirely.

430	4.3.  Monkey-patching the "Cookie" header

432	   Note: There's got to be a better way to specify this.  Until I figure
433	   out what that is, monkey-patching!

435	   Alter Section 5.4 of [RFC6265] as follows:

437	   1.  Add the following requirements to the list in step 1:

439	       *  If the cookie's "first-party-only-flag" is true, then exclude
440	          the cookie if the HTTP request is a third-party request (see
441	          Section 2.1).

443	       *  If the cookie's "first-party-only-flag" is true, then exclude
444	          the cookie if the HTTP request's method is not safe and the
445	          registerable domain of the origin of the URI of the document
446	          which originated the request is not the same as the
447	          registerable domain of the origin of the HTTP request's URI.

449	   Note that the modifications suggested here concern themselves only
450	   with the origins of ancestor browsing contexts and the origin of the
451	   resource being requested.  The cookie's "domain", "path", and
452	   "secure" attributes do not come into play for these comparisons.

454	5.  Authoring Considerations

456	5.1.  Mashups and Widgets

458	   The "First-Party-Only" attribute is inappropriate for some important
459	   use-cases.  In particular, note that content intended for embedding
460	   in a third-party context (social networking widgets or commenting
461	   services, for instance) will not have access to first-party-only
462	   cookies.  Non-first-party cookies may be required in order to provide
463	   seamless functionality that relies on a user's state.

465	   Likewise, some forms of Single-Sign-On might require authentication
466	   in a third-party context; these mechanisms will not function as
467	   intended with first-party-only cookies.

469	6.  Privacy Considerations

471	   First-party-only cookies in and of themselves don't do anything to
472	   address the general privacy concerns outlined in Section 7.1 of
473	   [RFC6265].  The attribute is set by the server, and serves to
474	   mitigate the risk of certain kinds of attacks that the server is
475	   worried about.  The user is not involved in this decision.  Moreover,
476	   a number of side-channels exist which could allow a server to link
477	   distinct requests even in the absence of cookies.  Connection and/or
478	   socket pooling, Token Binding, and Channel ID all offer explicit
479	   methods of identification that servers could take advantage of.

481	7.  References

483	7.1.  Normative References

485	   [HTML]     Hickson, I., "HTML Living Standard", n.d.,
486	              <https://html.spec.whatwg.org/>.

488	   [PSL]      "Public Suffix List", n.d., <https://publicsuffix.org/
489	              list/>.

491	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
492	              Requirement Levels", BCP 14, RFC 2119, March 1997.

494	   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
495	              Application Protocol Collation Registry", RFC 4790, March
496	              2007.

498	   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
499	              Specifications: ABNF", STD 68, RFC 5234, January 2008.

501	   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
502	              April 2011.

504	   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
505	              2011.

507	   [RFC7034]  Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
508	              Options", RFC 7034, October 2013.

510	   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
511	              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

513	   [SERVICE-WORKERS]
514	              Russell, A., Song, J., and J. Archibald, "Service
515	              Workers", n.d., <http://www.w3.org/TR/service-workers/>.

517	   [WORKERS]  Hickson, I., "Web Workers", n.d.,
518	              <http://www.w3.org/TR/workers/>.

520	7.2.  Informative References

522	   [app-isolation]
523	              Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
524	              "App Isolation - Get the Security of Multiple Browsers
525	              with Just One", n.d., <http://www.collinjackson.com/
526	              research/papers/appisolation.pdf>.

528	   [pixel-perfect]
529	              Stone, P., "Pixel Perfect Timing Attacks with HTML5",
530	              n.d., <http://www.contextis.com/documents/2/
531	              Browser_Timing_Attacks.pdf>.

533	   [prerendering]
534	              Bentzel, C., "Chrome Prerendering", n.d.,
535	              <https://www.chromium.org/developers/design-documents/
536	              prerender>.

538	   [samedomain-cookies]
539	              Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,
540	              <http://people.mozilla.org/~mgoodwin/SameDomain/
541	              samedomain-latest.txt>.

543	Appendix A.  Acknowledgements

545	   The first-party cookie concept documented here is indebited to Mark
546	   Goodwin's and Joe Walker's [samedomain-cookies].  Michal Zalewski,
547	   Artur Janc, and Ryan Sleevi provided particularly valuable feedback
548	   on this document.

550	Author's Address

552	   Mike West
553	   Google, Inc

555	   Email: mkwst@google.com
556	   URI:   https://mikewest.org/