idnits 2.17.1 

draft-west-first-party-cookies-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 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 (October 27, 2014) is 3468 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'


     Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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)                             October 27, 2014
5	Intended status: Standards Track
6	Expires: April 30, 2015

8	                          First-Party Cookies
9	                   draft-west-first-party-cookies-00

11	Abstract

13	   This document updates RFC6265, defining the "First-Party" attribute
14	   for cookies, which allows servers to mitigate the risk of cross-site
15	   request forgery and related information leakage attacks by asserting
16	   that a particular cookie should only be sent in a "first-party"
17	   context.

19	Status of This Memo

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

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

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

34	   This Internet-Draft will expire on April 30, 2015.

36	Copyright Notice

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

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

51	Table of Contents

53	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
54	     1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   3
55	   2.  Terminology and notation  . . . . . . . . . . . . . . . . . .   3
56	     2.1.  First-party and Third-party Requests  . . . . . . . . . .   3
57	   3.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   4
58	     3.1.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . .   4
59	     3.2.  Semantics of the "First-Party" Attribute (Non-Normative)    4
60	   4.  User Agent Requirements . . . . . . . . . . . . . . . . . . .   5
61	     4.1.  The "First-Party" attribute . . . . . . . . . . . . . . .   5
62	     4.2.  Monkey-patching the Storage Model . . . . . . . . . . . .   5
63	     4.3.  Monkey-patching the "Cookie" header . . . . . . . . . . .   6
64	   5.  Authoring Considerations  . . . . . . . . . . . . . . . . . .   6
65	     5.1.  Mashups and Widgets . . . . . . . . . . . . . . . . . . .   6
66	   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
67	     6.1.  User Controls . . . . . . . . . . . . . . . . . . . . . .   6
68	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
69	     7.1.  Limitations . . . . . . . . . . . . . . . . . . . . . . .   7
70	   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
71	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
72	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
73	     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
74	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

76	1.  Introduction

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

85	   Here, we update [RFC6265] with a simple mitigation strategy that
86	   allows servers to declare certain cookies as "First-party cookies"
87	   which should be attached to requests if and only if they occur in a
88	   first-party context.

90	   Note that the mechanism outlined here is backwards compatible with
91	   the existing cookie syntax.  Servers may serve first-party cookies to
92	   all user agents; those that do not support the "First-Party"
93	   attribute will simply store a non-first-party cookie, just as they do
94	   today.

96	1.1.  Examples

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

102	   Set-Cookie: SID=31d4d96e407aad42; First-Party

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

108	2.  Terminology and notation

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

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

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

121	   The terms "active document", and "top-level browsing context" are
122	   defined in the HTML Living Standard.  [HTML]

124	   The term "origin" and the mechanism of deriving an origin from a URI
125	   are defined in [RFC6454].

127	2.1.  First-party and Third-party Requests

129	   The URL displayed in a user agent's address bar is the only security
130	   context directly exposed to users, and therefore the only signal
131	   users can reasonably rely upon to determine who they're talking to.

133	   Broadly speaking, then, a "first-party" request is an HTTP request
134	   for a resource whose URL's origin matches the origin of the URL the
135	   user sees in the address bar.  A "third-party" request is an HTTP
136	   request for a resource at any other origin.

138	   To be slightly more precise, given an HTTP request "request":

140	   1.  Let "context" be the top-level browsing context in the window
141	       responsible for "request".

143	   2.  Let "top-origin" be the origin of the location of the active
144	       document in "context".

146	   3.  If the origin of "request"'s URL is the same as "top-origin",
147	       "request" is a *first-party request*. Otherwise, "request" is a
148	       *third-party request*.

150	   Note that we deal with the document's _location_ in step 2 above, not
151	   with the document's origin.  For example, a top-level document from
152	   "https://example.com" which has been sandboxed into a unique origin
153	   still creates a non-unique first-party context for subsequent
154	   requests.

156	   This definition has a few implications:

158	   o  New windows create new first-party contexts.

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

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

167	3.  Server Requirements

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

172	3.1.  Grammar

174	   Add "First-Party" to the list of accepted attributes in the "Set-
175	   Cookie" header field's value by replacing the "cookie-av" token
176	   definition in Section 4.1.1 of [RFC6265] with the following ABNF
177	   grammar:

179	   cookie-av         = expires-av / max-age-av / domain-av /
180	                       path-av / secure-av / httponly-av /
181	                       first-party-av / extension-av
182	   first-party-av    = "First-Party"

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

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

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

196	4.  User Agent Requirements

198	   This section describes extensions to [RFC6265] necessary in order to
199	   implement the client-side requirements of the "First-Party"
200	   attribute.

202	4.1.  The "First-Party" attribute

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

207	   If the attribute-name case-insensitively matches the string "First-
208	   Party", the user agent MUST append an attribute to the "cookie-
209	   attribute-list" with an "attribute-name" of "First-Party" and an
210	   empty "attribute-value".

212	4.2.  Monkey-patching the Storage Model

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

217	   Alter Section 5.3 of [RFC6265] as follows:

219	   1.  Add "firstparty-flag" to the list of fields stored for each
220	       cookie.

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

224	       1.  If the "cookie-attribute-list" contains an attribute with an
225	           "attribute-name" of "First-Party", set the cookie's "first-
226	           party-flag" to true.  Otherwise, set the cookie's "first-
227	           party-flag" to false.

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

234	4.3.  Monkey-patching the "Cookie" header

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

239	   Alter Section 5.4 of [RFC6265] as follows:

241	   1.  Add the following requirement to the list in step 1:

243	       *  If the cookie's "first-party-flag" is true, then exclude the
244	          cookie if the HTTP request is a third-party request (see
245	          Section 2.1).

247	   Note that the modifications suggested here concern themselves only
248	   with the origin of the top-level browsing context and the origin of
249	   the resource being requested.  The cookie's "domain", "path", and
250	   "secure" attributes do not come into play for this comparison.

252	5.  Authoring Considerations

254	5.1.  Mashups and Widgets

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

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

267	6.  Privacy Considerations

269	6.1.  User Controls

271	   First-party cookies in and of themselves don't do anything to address
272	   the general privacy concerns outlined in Section 7.1 of [RFC6265].
273	   The attribute is set by the server, and serves to mitigate the risk
274	   of certain kinds of attacks that the server is worried about.  The
275	   user is not involved in this decision.

277	   User agents, however, could offer users the ability to toggle a
278	   cookie's "first-party-flag" themselves, perhaps as part of a more
279	   general cookie management interface.  This could provide an
280	   interesting middle-ground between the options (e.g.  "Block all",
281	   "Block third-party", and "Allow all") that many user agents offer to
282	   users.

284	7.  Security Considerations

286	7.1.  Limitations

288	   It is possible to bypass the protection that first-party cookies
289	   offer against cross-site request forgery attacks by creating first-
290	   party contexts in which to execute the attack.  Consider, for
291	   instance, the URL "https://example.com/logout" which logs the current
292	   user out of "example.com".  If the user's session cookie is first-
293	   party cookie, then embedding the logout URL in an "<iframe>" element
294	   or an "<img>" element won't log her out, as the cookie won't be sent.
295	   Popping up a new window, or doing a top-level navigation, on the
296	   other hand, will create a first-party context, attach cookies, and
297	   perform the logout.

299	   Note, though, that popping up a window, or doing a top-level
300	   navigation are both significantly more visible to the user than
301	   loading a subresource.  Users will at least have the opportunity to
302	   notice that something strange is going on, which hopefully reduces an
303	   attacker's ability to perform untargeted attacks.

305	   Further, note that certain kinds of attacks are no longer possible if
306	   a first-party context is required.  Information leakage attacks which
307	   rely on visible side-effects of loading a session-protected image,
308	   for example, can no longer access those side-effects if the image is
309	   loaded in a new window.  Timing attacks like those Paul Stone
310	   outlines in [pixel-perfect] are no longer possible if the session
311	   cookie is first-party, as they rely on "<iframes>" to contain the
312	   protected content in a way the attacker can manipulate.

314	8.  Acknowledgements

316	   The first-party cookie concept documented here is similar to (but
317	   stricter than) Mark Goodwin's and Joe Walker's [samedomain-cookies].

319	9.  References

321	9.1.  Normative References

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

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

329	   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
330	              Application Protocol Collation Registry", RFC 4790, March
331	              2007.

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

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

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

342	9.2.  Informative References

344	   [pixel-perfect]
345	              Stone, P., "Pixel Perfect Timing Attacks with HTML5",
346	              n.d., <http://www.contextis.com/documents/2/
347	              Browser_Timing_Attacks.pdf>.

349	   [samedomain-cookies]
350	              Goodwin,, M. and J. Walker, "SameDomain Cookie Flag",
351	              2011, <http://people.mozilla.org/~mgoodwin/SameDomain/
352	              samedomain-latest.txt>.

354	Author's Address

356	   Mike West
357	   Google, Inc

359	   Email: mkwst@google.com
360	   URI:   https://mikewest.org/