draft-ietf-httpbis-cookie-same-site-00.txt		draft-ietf-httpbis-cookie-same-site-latest.txt
	HTTP Working Group M. West		HTTP Working Group M. West
	Internet-Draft Google, Inc		Internet-Draft Google, Inc
	Updates: 6265 (if approved) M. Goodwin		Updates: 6265 (if approved) M. Goodwin
	Intended status: Standards Track Mozilla		Intended status: Standards Track Mozilla
	Expires: December 22, 2016 June 20, 2016		Expires: January 7, 2025 July 6, 2018
	Same-Site Cookies		Same-Site Cookies
	draft-ietf-httpbis-cookie-same-site-00		draft-ietf-httpbis-cookie-same-site-latest
	Abstract		Abstract
	This document updates RFC6265 by defining a "SameSite" attribute		This document updates RFC6265 by defining a "SameSite" attribute
	which allows servers to assert that a cookie ought not to be sent		which allows servers to assert that a cookie ought not to be sent
	along with cross-site requests. This assertion allows user agents to		along with cross-site requests. This assertion allows user agents to
	mitigate the risk of cross-origin information leakage, and provides		mitigate the risk of cross-origin information leakage, and provides
	some protection against cross-site request forgery attacks.		some protection against cross-site request forgery attacks.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	https://lists.w3.org/Archives/Public/ietf-http-wg/.		https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
	Working Group information can be found at http://httpwg.github.io/;		Working Group information can be found at http://httpwg.github.io/
	source code and issues list for this draft can be found at		[2]; source code and issues list for this draft can be found at
	https://github.com/httpwg/http-extensions/labels/cookie-same-site.		https://github.com/httpwg/http-extensions/labels/cookie-same-site
			[3].
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 22, 2016.		This Internet-Draft will expire on January 7, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and notation . . . . . . . . . . . . . . . . . . . 4		2. Terminology and notation . . . . . . . . . . . . . . . . . . 4
	2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 5		2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 5
	2.1.1. Document-based requests . . . . . . . . . . . . . . . 5		2.1.1. Document-based requests . . . . . . . . . . . . . . . 5
	2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6		2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6
	3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 7		3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8		3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8
	4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8		4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8
	4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . . 8		4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . 8
	4.1.1. "Strict" and "Lax" enforcement . . . . . . . . . . . . 8		4.1.1. "Strict" and "Lax" enforcement . . . . . . . . . . . 9
	4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9		4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9
	4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 9		4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 10
	5. Authoring Considerations . . . . . . . . . . . . . . . . . . . 10		5. Authoring Considerations . . . . . . . . . . . . . . . . . . 10
	5.1. Defense in depth . . . . . . . . . . . . . . . . . . . . . 10		5.1. Defense in depth . . . . . . . . . . . . . . . . . . . . 10
	5.2. Top-level Navigations . . . . . . . . . . . . . . . . . . 10		5.2. Top-level Navigations . . . . . . . . . . . . . . . . . . 11
	5.3. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 11		5.3. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 11
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
	6.1. Server-controlled . . . . . . . . . . . . . . . . . . . . 11		6.1. Server-controlled . . . . . . . . . . . . . . . . . . . . 11
	6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . . 11		6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13		7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Changes since draft-ietf-httpbis-cookie-same-site-00 14
			Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Section 8.2 of [RFC6265] eloquently notes that cookies are a form of		Section 8.2 of [RFC6265] eloquently notes that cookies may be
	ambient authority, attached by default to requests the user agent		employed as a form of ambient authority, attached by default to
	sends on a user's behalf. Even when an attacker doesn't know the		requests the user agent sends on a user's behalf. Even when an
	contents of a user's cookies, she can still execute commands on the		attacker doesn't know the contents of a user's cookies, she can still
	user's behalf (and with the user's authority) by asking the user		execute commands on the user's behalf (and with the user's authority)
	agent to send HTTP requests to unwary servers.		by asking the user agent to send HTTP requests to unwary servers.
			These malicious requests will include any of the user's previously-
			set cookies, and therefore can be difficult to distinguish from
			benign requests on the user's behalf.
	Here, we update [RFC6265] with a simple mitigation strategy that		Here, we update [RFC6265] with a simple mitigation strategy that
	allows servers to declare certain cookies as "same-site", meaning		allows servers to declare certain cookies as "same-site", meaning
	they should not be attached to "cross-site" requests (as defined in		they should not be attached to "cross-site" requests (as defined in
	section 2.1).		section 2.1 of this specification).
	Note that the mechanism outlined here is backwards compatible with		Note that the mechanism outlined here is backwards compatible with
	the existing cookie syntax. Servers may serve these cookies to all		the existing cookie syntax. Servers may serve these cookies to all
	user agents; those that do not support the "SameSite" attribute will		user agents; those that do not support the "SameSite" attribute will
	simply store a cookie which is attached to all relevant requests,		simply store a cookie which is attached to all relevant requests,
	just as they do today.		just as they do today.
	1.1. Goals		1.1. Goals
	These cookies are intended to provide a solid layer of defense-in-		Same-site cookies are intended to provide a solid layer of defense-
	depth against attacks which require embedding an authenticated		in-depth against attacks which require embedding an authenticated
	request into an attacker-controlled context:		request into an attacker-controlled context:
	1. Timing attacks which yield cross-origin information leakage (such		1. Timing attacks which yield cross-origin information leakage (such
	as those detailed in [pixel-perfect]) can be substantially		as those detailed in [pixel-perfect]) can be substantially
	mitigated by setting the "SameSite" attribute on authentication		mitigated by setting the "SameSite" attribute on authentication
	cookies. The attacker will only be able to embed unauthenticated		cookies. The attacker will only be able to embed unauthenticated
	resources, as embedding mechanisms such as "<iframe>" will yield		resources, as embedding mechanisms such as "<iframe>" will yield
	cross-site requests.		cross-site requests.
	2. Cross-site script inclusion (XSSI) attacks are likewise mitigated		2. Cross-site script inclusion (XSSI) attacks are likewise mitigated
	by setting the "SameSite" attribute on authentication cookies.		by setting the "SameSite" attribute on authentication cookies.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 9 ¶
	site".		site".
	4. Same-site cookies have some marginal value for policy or		4. Same-site cookies have some marginal value for policy or
	regulatory purposes, as cookies which are not delivered with		regulatory purposes, as cookies which are not delivered with
	cross-site requests cannot be directly used for tracking		cross-site requests cannot be directly used for tracking
	purposes. It may be valuable for an origin to assert that its		purposes. It may be valuable for an origin to assert that its
	cookies should not be sent along with cross-site requests in		cookies should not be sent along with cross-site requests in
	order to limit its exposure to non-technical risk.		order to limit its exposure to non-technical risk.
	1.2. Examples		1.2. Examples
	Same-site cookies are set via the "SameSite" attribute in the		Same-site cookies are set via the "SameSite" attribute in the "Set-
	"Set-Cookie" header field. That is, given a server's response to a		Cookie" header field. That is, given a server's response to a user
	user agent which contains the following header field:		agent which contains the following header field:
	Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict		Set-Cookie: SID=31d4d96e407aad42; SameSite=Strict
	Subsequent requests from that user agent can be expected to contain		Subsequent requests from that user agent can be expected to contain
	the following header field if and only if both the requested resource		the following header field if and only if both the requested resource
	and the resource in the top-level browsing context match the cookie.		and the resource in the top-level browsing context match the cookie.
			Cookie: SID=31d4d96e407aad42
	2. Terminology and notation		2. Terminology and notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234].		notation of [RFC5234].
	Two sequences of octets are said to case-insensitively match each		Two sequences of octets are said to case-insensitively match each
	other if and only if they are equivalent under the "i;ascii-casemap"		other if and only if they are equivalent under the "i;ascii-casemap"
	collation defined in [RFC4790].		collation defined in [RFC4790].
	The terms "active document", "ancestor browsing context", "browsing		The terms "active document", "ancestor browsing context", "browsing
	context", "document", "WorkerGlobalScope", "sandboxed origin browsing		context", "dedicated worker", "Document", "WorkerGlobalScope",
	context flag", "parent browsing context", "the worker's Documents",		"sandboxed origin browsing context flag", "parent browsing context",
	"nested browsing context", and "top-level browsing context" are		"shared worker", "the worker's Documents", "nested browsing context",
	defined in [HTML].		and "top-level browsing context" are defined in [HTML].
	"Service Workers" are defined in the Service Workers specification		"Service Workers" are defined in the Service Workers specification
	[SERVICE-WORKERS].		[SERVICE-WORKERS].
	The term "origin", the mechanism of deriving an origin from a URI,		The term "origin", the mechanism of deriving an origin from a URI,
	and the "the same" matching algorithm for origins are defined in		and the "the same" matching algorithm for origins are defined in
	[RFC6454].		[RFC6454].
	"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as		"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
	defined in Section 4.2.1 of [RFC7231].		defined in Section 4.2.1 of [RFC7231].
	The term "public suffix" is defined in a note in Section 5.3 of		The term "public suffix" is defined in a note in Section 5.3 of
	[RFC6265] as "a domain that is controlled by a public registry". For		[RFC6265] as "a domain that is controlled by a public registry", and
	example, "example.com"'s public suffix is "com". User agents SHOULD		are also know as "effective top-level domains" (eTLDs). For example,
	use an up-to-date public suffix list, such as the one maintained by		"example.com"'s public suffix is "com". User agents SHOULD use an
	Mozilla at [PSL].		up-to-date public suffix list, such as the one maintained by Mozilla
			at [PSL].
	An origin's "registrable domain" is the origin's host's public suffix		An origin's "registered domain" is the origin's host's public suffix
	plus the label to its left. That is, "https://www.example.com"'s		plus the label to its left. That is, for "https://www.example.com",
	registrable domain is "example.com". This concept is defined more		the public suffix is "com", and the registered domain is
	rigorously in [PSL].		"example.com". This concept is defined more rigorously in [PSL], and
			is also know as "effective top-level domain plus one" (eTLD+1).
	The term "request", as well as a request's "client", "current url",		The term "request", as well as a request's "client", "current url",
	"method", and "target browsing context", are defined in [FETCH].		"method", and "target browsing context", are defined in [FETCH].
	2.1. "Same-site" and "cross-site" Requests		2.1. "Same-site" and "cross-site" Requests
	A request is "same-site" if its target's URI's origin's registrable		A request is "same-site" if its target's URI's origin's registered
	domain is an exact match for the request's initiator's "site for		domain is an exact match for the request's client's "site for
	cookies", and "cross-site" otherwise. To be more precise, for a		cookies" or if the request has no client, and "cross-site" otherwise.
	given request ("request"), the following algorithm returns		To be more precise, for a given request ("request"), the following
	"same-site" or "cross-site":		algorithm returns "same-site" or "cross-site":
	1. If "request"'s client is "null", return "same-site".		1. If "request"'s client is "null", return "same-site".
	2. Let "site" be "request"'s client's "site for cookies" (as defined		2. Let "site" be "request"'s client's "site for cookies" (as defined
	in the following sections).		in the following sections).
	3. Let "target" be the registrable domain of "request"'s current		3. Let "target" be the registered domain of "request"'s current url.
	url.
	4. If "site" is an exact match for "target", return "same-site".		4. If "site" is an exact match for "target", return "same-site".
	5. Return "cross-site".		5. Return "cross-site".
	2.1.1. Document-based requests		2.1.1. Document-based requests
	The URI displayed in a user agent's address bar is the only security		The URI displayed in a user agent's address bar is the only security
	context directly exposed to users, and therefore the only signal		context directly exposed to users, and therefore the only signal
	users can reasonably rely upon to determine whether or not they trust		users can reasonably rely upon to determine whether or not they trust
	a particular website. The registrable domain of that URI's origin		a particular website. The registered domain of that URI's origin
	represents the context in which a user most likely believes		represents the context in which a user most likely believes
	themselves to be interacting. We'll label this domain the "top-level		themselves to be interacting. We'll label this domain the "top-level
	site".		site".
	For a document displayed in a top-level browsing context, we can stop		For a document displayed in a top-level browsing context, we can stop
	here: the document's "site for cookies" is the top-level site.		here: the document's "site for cookies" is the top-level site.
	For documents which are displayed in nested browsing contexts, we		For documents which are displayed in nested browsing contexts, we
	need to audit the origins of each of a document's ancestor browsing		need to audit the origins of each of a document's ancestor browsing
	contexts' active documents in order to account for the "multiple-		contexts' active documents in order to account for the "multiple-
	nested scenarios" described in Section 4 of [RFC7034]. These		nested scenarios" described in Section 4 of [RFC7034]. These
	document's "site for cookies" is the top-level site if and only if		document's "site for cookies" is the top-level site if and only if
	the document and each of its ancestor documents' origins have the		the document and each of its ancestor documents' origins have the
	same registrable domain as the top-level site. Otherwise its "site		same registered domain as the top-level site. Otherwise its "site
	for cookies" is the empty string.		for cookies" is the empty string.
	Given a Document ("document"), the following algorithm returns its		Given a Document ("document"), the following algorithm returns its
	"site for cookies" (either a registrable domain, or the empty		"site for cookies" (either a registered domain, or the empty string):
	string):
	1. Let "top-document" be the active document in "document"'s		1. Let "top-document" be the active document in "document"'s
	browsing context's top-level browsing context.		browsing context's top-level browsing context.
	2. Let "top-origin" be the origin of "top-document"'s URI if		2. Let "top-origin" be the origin of "top-document"'s URI if "top-
	"top-document"'s sandboxed origin browsing context flag is set,		document"'s sandboxed origin browsing context flag is set, and
	and "top-document"'s origin otherwise.		"top-document"'s origin otherwise.
	3. Let "documents" be a list containing "document" and each of		3. Let "documents" be a list containing "document" and each of
	"document"'s ancestor browsing contexts' active documents.		"document"'s ancestor browsing contexts' active documents.
	4. For each "item" in "documents":		4. For each "item" in "documents":
	1. Let "origin" be the origin of "item"'s URI if "item"'s		1. Let "origin" be the origin of "item"'s URI if "item"'s
	sandboxed origin browsing context flag is set, and "item"'s		sandboxed origin browsing context flag is set, and "item"'s
	origin otherwise.		origin otherwise.
	2. If "origin"'s host's registrable domain is not an exact match		2. If "origin"'s host's registered domain is not an exact match
	for "top-origin"'s host's registrable domain, return the		for "top-origin"'s host's registered domain, return the empty
	empty string.		string.
	5. Return "top-site".		5. Return "top-site".
	2.1.2. Worker-based requests		2.1.2. Worker-based requests
	Worker-driven requests aren't as clear-cut as document-driven		Worker-driven requests aren't as clear-cut as document-driven
	requests, as there isn't a clear link between a top-level browsing		requests, as there isn't a clear link between a top-level browsing
	context and a worker. This is especially true for Service Workers		context and a worker. This is especially true for Service Workers
	[SERVICE-WORKERS], which may execute code in the background, without		[SERVICE-WORKERS], which may execute code in the background, without
	any document visible at all.		any document visible at all.
	skipping to change at page 6, line 49 ¶		skipping to change at page 7, line 6 ¶
	worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define		worker (via "importScripts", "XMLHttpRequest", "fetch()", etc) define
	their "site for cookies" as that document's "site for cookies".		their "site for cookies" as that document's "site for cookies".
	Shared workers may be bound to multiple documents at once. As it is		Shared workers may be bound to multiple documents at once. As it is
	quite possible for those documents to have distinct "site for cookie"		quite possible for those documents to have distinct "site for cookie"
	values, the worker's "site for cookies" will be the empty string in		values, the worker's "site for cookies" will be the empty string in
	cases where the values diverge, and the shared value in cases where		cases where the values diverge, and the shared value in cases where
	the values agree.		the values agree.
	Given a WorkerGlobalScope ("worker"), the following algorithm returns		Given a WorkerGlobalScope ("worker"), the following algorithm returns
	its "site for cookies" (either a registrable domain, or the empty		its "site for cookies" (either a registered domain, or the empty
	string):		string):
	1. Let "site" be "worker"'s origin's host's registrable domain.		1. Let "site" be "worker"'s origin's host's registered domain.
	2. For each "document" in "worker"'s Documents:		2. For each "document" in "worker"'s Documents:
	1. Let "document-site" be "document"'s "site for cookies" (as		1. Let "document-site" be "document"'s "site for cookies" (as
	defined in Section 2.1.1).		defined in Section 2.1.1).
	2. If "document-site" is not an exact match for "site", return		2. If "document-site" is not an exact match for "site", return
	the empty string.		the empty string.
	3. Return "site".		3. Return "site".
	2.1.2.2. Service Workers		2.1.2.2. Service Workers
	Service Workers are more complicated, as they act as a completely		Service Workers are more complicated, as they act as a completely
	separate execution context with only tangential relationship to the		separate execution context with only tangential relationship to the
	Document which registered them.		Document which registered them.
	Requests which simply pass through a service worker will be handled		Requests which simply pass through a service worker will be handled
	as described above: the request's client will be the Document or		as described above: the request's client will be the Document or
	Worker which initiated the request, and its "site for cookies" will		Worker which initiated the request, and its "site for cookies" will
	be those defined in Section 2.1.1 and Section 2.1.2.1		be those defined in Section 2.1.1 and Section 2.1.2.1
	Requests which are initiated by the Service Worker itself (via a		Requests which are initiated by the Service Worker itself (via a
	direct call to "fetch()", for instance), on the other hand, will have		direct call to "fetch()", for instance), on the other hand, will have
	a client which is a ServiceWorkerGlobalScope. Its "site for cookies"		a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
	will be the registrable domain of the Service Worker's URI.		will be the registered domain of the Service Worker's URI.
	Given a ServiceWorkerGlobalScope ("worker"), the following algorithm		Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
	returns its "site for cookies" (either a registrable domain, or the		returns its "site for cookies" (either a registered domain, or the
	empty string):		empty string):
	1. Return "worker"'s origin's host's registrable domain.		1. Return "worker"'s origin's host's registered domain.
	3. Server Requirements		3. Server Requirements
	This section describes extensions to [RFC6265] necessary to implement		This section describes extensions to [RFC6265] necessary to implement
	the server-side requirements of the "SameSite" attribute.		the server-side requirements of the "SameSite" attribute.
	3.1. Grammar		3.1. Grammar
	Add "SameSite" to the list of accepted attributes in the "Set-Cookie"		Add "SameSite" to the list of accepted attributes in the "Set-Cookie"
	header field's value by replacing the "cookie-av" token definition in		header field's value by replacing the "cookie-av" token definition in
	Section 4.1.1 of [RFC6265] with the following ABNF grammar:		Section 4.1.1 of [RFC6265] with the following ABNF grammar:
	cookie-av = expires-av / max-age-av / domain-av /		cookie-av = expires-av / max-age-av / domain-av /
	path-av / secure-av / httponly-av /		path-av / secure-av / httponly-av /
	samesite-av / extension-av		samesite-av / extension-av
	samesite-av = "SameSite" / "SameSite=" samesite-value		samesite-av = "SameSite=" samesite-value
	samesite-value = "Strict" / "Lax"		samesite-value = "Strict" / "Lax"
	3.2. Semantics of the "SameSite" Attribute (Non-Normative)		3.2. Semantics of the "SameSite" Attribute (Non-Normative)
	The "SameSite" attribute limits the scope of the cookie such that it		The "SameSite" attribute limits the scope of the cookie such that it
	will only be attached to requests if those requests are "same-site",		will only be attached to requests if those requests are same-site, as
	as defined by the algorithm in Section 2.1. For example, requests		defined by the algorithm in Section 2.1. For example, requests for
	for "https://example.com/sekrit-image" will attach same-site cookies		"https://example.com/sekrit-image" will attach same-site cookies if
	if and only if initiated from a context whose "site for cookies" is		and only if initiated from a context whose "site for cookies" is
	"example.com".		"example.com".
	If the "SameSite" attribute's value is "Strict", or if the value is		If the "SameSite" attribute's value is "Strict", the cookie will only
	invalid, the cookie will only be sent along with "same-site"		be sent along with "same-site" requests. If the value is "Lax", the
	requests. If the value is "Lax", the cookie will be sent with "same-		cookie will be sent with same-site requests, and with "cross-site"
	site" requests, and with "cross-site" top-level navigations, as		top-level navigations, as described in Section 4.1.1. If the
	described in Section 4.1.1.		"SameSite" attribute's value is neither of these, the cookie will be
			ignored.
	The changes to the "Cookie" header field suggested in Section 4.3		The changes to the "Cookie" header field suggested in Section 4.3
	provide additional detail.		provide additional detail.
	4. User Agent Requirements		4. User Agent Requirements
	This section describes extensions to [RFC6265] necessary in order to		This section describes extensions to [RFC6265] necessary in order to
	implement the client-side requirements of the "SameSite" attribute.		implement the client-side requirements of the "SameSite" attribute.
	4.1. The "SameSite" attribute		4.1. The "SameSite" attribute
	skipping to change at page 8, line 46 ¶		skipping to change at page 9, line 7 ¶
	1. If "cookie-av"'s "attribute-value" is not a case-insensitive		1. If "cookie-av"'s "attribute-value" is not a case-insensitive
	match for "Strict" or "Lax", ignore the "cookie-av".		match for "Strict" or "Lax", ignore the "cookie-av".
	2. Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is		2. Let "enforcement" be "Lax" if "cookie-av"'s "attribute-value" is
	a case-insensitive match for "Lax", and "Strict" otherwise.		a case-insensitive match for "Lax", and "Strict" otherwise.
	3. Append an attribute to the "cookie-attribute-list" with an		3. Append an attribute to the "cookie-attribute-list" with an
	"attribute-name" of "SameSite" and an "attribute-value" of		"attribute-name" of "SameSite" and an "attribute-value" of
	"enforcement".		"enforcement".
	4.1.1. "Strict" and "Lax" enforcement		4.1.1. "Strict" and "Lax" enforcement
	By default, same-site cookies will not be sent along with top-level		Same-site cookies in "Strict" enforcement mode will not be sent along
	navigations. As discussed in Section 5.2, this might or might not be		with top-level navigations which are triggered from a cross-site
	compatible with existing session management systems. In the		document context. As discussed in Section 5.2, this might or might
			not be compatible with existing session management systems. In the
	interests of providing a drop-in mechanism that mitigates the risk of		interests of providing a drop-in mechanism that mitigates the risk of
	CSRF attacks, developers may set the "SameSite" attribute in a "Lax"		CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
	enforcement mode that carves out an exception which sends same-site		enforcement mode that carves out an exception which sends same-site
	cookies along with cross-site requests if and only if they are top-		cookies along with cross-site requests if and only if they are top-
	level navigations which use a "safe" (in the [RFC7231] sense) HTTP		level navigations which use a "safe" (in the [RFC7231] sense) HTTP
	method.		method.
	Lax enforcement provides reasonable defense in depth against CSRF		Lax enforcement provides reasonable defense in depth against CSRF
	attacks that rely on unsafe HTTP methods (like "POST"), but do not		attacks that rely on unsafe HTTP methods (like "POST"), but does not
	offer a robust defense against CSRF as a general category of attack:		offer a robust defense against CSRF as a general category of attack:
	1. Attackers can still pop up new windows or trigger top-level		1. Attackers can still pop up new windows or trigger top-level
	navigations in order to create a "same-site" request (as		navigations in order to create a "same-site" request (as
	described in section 2.1), which is only a speedbump along the		described in section 2.1), which is only a speedbump along the
	road to exploitation.		road to exploitation.
	2. Features like "<link rel='prerender'>" [prerendering] can be		2. Features like "<link rel='prerender'>" [prerendering] can be
	exploited to create "same-site" requests without the risk of user		exploited to create "same-site" requests without the risk of user
	detection.		detection.
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 41 ¶
	such as that described in Section 5.2 to mitigate the risk of CSRF		such as that described in Section 5.2 to mitigate the risk of CSRF
	more completely.		more completely.
	4.2. Monkey-patching the Storage Model		4.2. Monkey-patching the Storage Model
	Note: There's got to be a better way to specify this. Until I figure		Note: There's got to be a better way to specify this. Until I figure
	out what that is, monkey-patching!		out what that is, monkey-patching!
	Alter Section 5.3 of [RFC6265] as follows:		Alter Section 5.3 of [RFC6265] as follows:
	1. Add "samesite-flag" to the list of fields stored for each cookie.		1. Add "samesite-flag" to the list of each cookie's fields defined
	This field's value is one of "None", "Strict", or "Lax".		in the first paragraph. Note: this field's value is one of
			"None", "Strict", or "Lax".
	2. Before step 11 of the current algorithm, add the following:		2. Before step 11 of the current algorithm, add the following:
	1. If the "cookie-attribute-list" contains an attribute with an		1. If the "cookie-attribute-list" contains an attribute with an
	"attribute-name" of "SameSite", set the cookie's		"attribute-name" of "SameSite", set the cookie's "samesite-
	"samesite-flag" to "attribute-value" ("Strict" or "Lax").		flag" to "attribute-value" ("Strict" or "Lax"). Otherwise,
	Otherwise, set the cookie's "samesite-flag" to "None".		set the cookie's "samesite-flag" to "None".
	2. If the cookie's "samesite-flag" is not "None", and the		2. If the cookie's "samesite-flag" is not "None", and the
	request which generated the cookie's client's "site for		request which generated the cookie's client's "site for
	cookies" is not an exact match for "request-uri"'s host's		cookies" is not an exact match for "request-uri"'s host's
	registrable domain, then abort these steps and ignore the		registered domain, then abort these steps and ignore the
	newly created cookie entirely.		newly created cookie entirely.
	4.3. Monkey-patching the "Cookie" header		4.3. Monkey-patching the "Cookie" header
	Note: There's got to be a better way to specify this. Until I figure		Note: There's got to be a better way to specify this. Until I figure
	out what that is, monkey-patching!		out what that is, monkey-patching!
	Alter Section 5.4 of [RFC6265] as follows:		Alter Section 5.4 of [RFC6265] as follows:
	1. Add the following requirement to the list in step 1:		1. Add the following requirement to the end of the bulleted list in
			step 1:
	* If the cookie's "samesite-flag" is not "None", and the HTTP		* If the cookie's "samesite-flag" is not "None", and the HTTP
	request is cross-site (as defined in Section 2.1 then exclude		request is cross-site (as defined in Section 2.1) then exclude
	the cookie unless all of the following statements hold:		the cookie unless all of the following statements hold:
	1. "samesite-flag" is "Lax"		1. "samesite-flag" is "Lax"
	2. The HTTP request's method is "safe".		2. The HTTP request's method is "safe".
	3. The HTTP request's target browsing context is a top-level		3. The HTTP request's target browsing context is a top-level
	browsing context.		browsing context.
	Note that the modifications suggested here concern themselves only		Note that the modifications suggested here concern themselves only
	with the "site for cookies" of the request's client, and the		with the "site for cookies" of the request's client, and the
	registrable domain of the resource being requested. The cookie's		registered domain of the resource being requested. The cookie's
	"domain", "path", and "secure" attributes do not come into play for		"domain", "path", and "secure" attributes do not come into play for
	these comparisons.		these comparisons.
	5. Authoring Considerations		5. Authoring Considerations
	5.1. Defense in depth		5.1. Defense in depth
	"SameSite" cookies offer a robust defense against CSRF attack when		"SameSite" cookies offer a robust defense against CSRF attack when
	deployed in strict mode, and when supported by the client. It is,		deployed in strict mode, and when supported by the client. It is,
	however, prudent to ensure that this designation is not the extent of		however, prudent to ensure that this designation is not the extent of
	skipping to change at page 10, line 44 ¶		skipping to change at page 11, line 10 ¶
	Additionally, client-side techniques such as those described in		Additionally, client-side techniques such as those described in
	[app-isolation] may also prove effective against CSRF, and are		[app-isolation] may also prove effective against CSRF, and are
	certainly worth exploring in combination with "SameSite" cookies.		certainly worth exploring in combination with "SameSite" cookies.
	5.2. Top-level Navigations		5.2. Top-level Navigations
	Setting the "SameSite" attribute in "strict" mode provides robust		Setting the "SameSite" attribute in "strict" mode provides robust
	defense in depth against CSRF attacks, but has the potential to		defense in depth against CSRF attacks, but has the potential to
	confuse users unless sites' developers carefully ensure that their		confuse users unless sites' developers carefully ensure that their
	session management systems deal reasonably well with top-level		cookie-based session management systems deal reasonably well with
	navigations.		top-level navigations.
	Consider the scenario in which a user reads their email at MegaCorp		Consider the scenario in which a user reads their email at MegaCorp
	Inc's webmail provider "https://example.com/". They might expect		Inc's webmail provider "https://example.com/". They might expect
	that clicking on an emailed link to		that clicking on an emailed link to "https://projects.com/secret/
	"https://projects.com/secret/project" would show them the secret		project" would show them the secret project that they're authorized
	project that they're authorized to see, but if "projects.com" has		to see, but if "projects.com" has marked their session cookies as
	marked their session cookies as "SameSite", then this cross-site		"SameSite", then this cross-site navigation won't send them along
	navigation won't send them along with the request. "projects.com"		with the request. "projects.com" will render a 404 error to avoid
	will render a 404 error to avoid leaking secret information, and the		leaking secret information, and the user will be quite confused.
	user will be quite confused.
	Developers can avoid this confusion by adopting a session management		Developers can avoid this confusion by adopting a session management
	system that relies on not one, but two cookies: one conceptualy		system that relies on not one, but two cookies: one conceptually
	granting "read" access, another granting "write" access. The latter		granting "read" access, another granting "write" access. The latter
	could be marked as "SameSite", and its absence would provide a		could be marked as "SameSite", and its absence would prompt a
	reauthentication step before executing any non-idempotent action.		reauthentication step before executing any non-idempotent action.
	The former could drop the "SameSite" attribute entirely, or choose		The former could drop the "SameSite" attribute entirely, or choose
	the "Lax" version of enforcement, in order to allow users access to		the "Lax" version of enforcement, in order to allow users access to
	data via top-level navigation.		data via top-level navigation.
	5.3. Mashups and Widgets		5.3. Mashups and Widgets
	The "SameSite" attribute is inappropriate for some important use-		The "SameSite" attribute is inappropriate for some important use-
	cases. In particular, note that content intended for embedding in a		cases. In particular, note that content intended for embedding in a
	cross-site contexts (social networking widgets or commenting		cross-site contexts (social networking widgets or commenting
	services, for instance) will not have access to such cookies. Cross-		services, for instance) will not have access to same-site cookies.
	site cookies may be required in order to provide seamless		Cookies may be required for requests triggered in these cross-site
	functionality that relies on a user's state.		contexts in order to provide seamless functionality that relies on a
			user's state.
	Likewise, some forms of Single-Sign-On might require authentication		Likewise, some forms of Single-Sign-On might require cookie-based
	in a cross-site context; these mechanisms will not function as		authentication in a cross-site context; these mechanisms will not
	intended with same-site cookies.		function as intended with same-site cookies.
	6. Privacy Considerations		6. Privacy Considerations
	6.1. Server-controlled		6.1. Server-controlled
	Same-site cookies in and of themselves don't do anything to address		Same-site cookies in and of themselves don't do anything to address
	the general privacy concerns outlined in Section 7.1 of [RFC6265].		the general privacy concerns outlined in Section 7.1 of [RFC6265].
	The attribute is set by the server, and serves to mitigate the risk		The SameSite attribute is set by the server, and serves to mitigate
	of certain kinds of attacks that the server is worried about. The		the risk of certain kinds of attacks that the server is worried
	user is not involved in this decision. Moreover, a number of side-		about. The user is not involved in this decision. Moreover, a
	channels exist which could allow a server to link distinct requests		number of side-channels exist which could allow a server to link
	even in the absence of cookies. Connection and/or socket pooling,		distinct requests even in the absence of cookies. Connection and/or
	Token Binding, and Channel ID all offer explicit methods of		socket pooling, Token Binding, and Channel ID all offer explicit
	identification that servers could take advantage of.		methods of identification that servers could take advantage of.
	6.2. Pervasive Monitoring		6.2. Pervasive Monitoring
	As outlined in [RFC7258], pervasive monitoring is an attack. Cookies		As outlined in [RFC7258], pervasive monitoring is an attack. Cookies
	play a large part in enabling such monitoring, as they are		play a large part in enabling such monitoring, as they are
	responsible for maintaining state in HTTP connections. We considered		responsible for maintaining state in HTTP connections. We considered
	restricting same-site cookies to secure contexts [secure-contexts] as		restricting same-site cookies to secure contexts [secure-contexts] as
	a mitigation but decided against doing so, as this feature should		a mitigation but decided against doing so, as same-site cookies
	result in a strict reduction in the number of cookies floating around		should result in a strict reduction in the number of cookies floating
	in cross-site contexts. That is, even if "http://not-example.com"		around in cross-site contexts. That is, even if "http://not-
	embeds a resource from "http://example.com/", that resource will not		example.com" embeds a resource from "http://example.com/", that
	be "same-site", and "http://example.com"'s cookies simply cannot be		resource will not be "same-site", and "http://example.com"'s cookies
	used to correlate user behavior across distinct origins.		simply cannot be used to correlate user behavior across distinct
			origins.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[FETCH] van Kesteren, A., "Fetch", n.d.,		[FETCH] van Kesteren, A., "Fetch", n.d.,
	<https://fetch.spec.whatwg.org/>.		<https://fetch.spec.whatwg.org/>.
	[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,		[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
	P., and D. Denicola, "HTML", n.d.,		P., and D. Denicola, "HTML", n.d.,
	<https://html.spec.whatwg.org/>.		<https://html.spec.whatwg.org/>.
	[PSL] "Public Suffix List", n.d.,		[PSL] "Public Suffix List", n.d.,
	<https://publicsuffix.org/list/>.		<https://publicsuffix.org/list/>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet		[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
	Application Protocol Collation Registry", RFC 4790,		Application Protocol Collation Registry", RFC 4790,
	DOI 10.17487/RFC4790, March 2007,		DOI 10.17487/RFC4790, March 2007,
	<http://www.rfc-editor.org/info/rfc4790>.		<https://www.rfc-editor.org/info/rfc4790>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234,
	RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<http://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<http://www.rfc-editor.org/info/rfc6454>.		<https://www.rfc-editor.org/info/rfc6454>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<http://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258,		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	May 2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[SERVICE-WORKERS]		[SERVICE-WORKERS]
	Russell, A., Song, J., and J. Archibald, "Service		Russell, A., Song, J., and J. Archibald, "Service
	Workers", n.d., <http://www.w3.org/TR/service-workers/>.		Workers", n.d., <http://www.w3.org/TR/service-workers/>.
	7.2. Informative References		7.2. Informative References
	[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
	Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
	<http://www.rfc-editor.org/info/rfc7034>.
	[app-isolation]		[app-isolation]
	Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,		Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
	"App Isolation - Get the Security of Multiple Browsers		"App Isolation - Get the Security of Multiple Browsers
	with Just One", n.d., <http://www.collinjackson.com/		with Just One", 2011,
	research/papers/appisolation.pdf>.		<http://www.collinjackson.com/research/papers/
			appisolation.pdf>.
	[pixel-perfect]		[pixel-perfect]
	Stone, P., "Pixel Perfect Timing Attacks with HTML5",		Stone, P., "Pixel Perfect Timing Attacks with HTML5",
	n.d., <http://www.contextis.com/documents/2/		n.d., <http://www.contextis.com/documents/2/
	Browser_Timing_Attacks.pdf>.		Browser_Timing_Attacks.pdf>.
	[prerendering]		[prerendering]
	Bentzel, C., "Chrome Prerendering", n.d., <https://		Bentzel, C., "Chrome Prerendering", n.d.,
	www.chromium.org/developers/design-documents/prerender>.		<https://www.chromium.org/developers/design-documents/
			prerender>.
			[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
			Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
			<https://www.rfc-editor.org/info/rfc7034>.
	[samedomain-cookies]		[samedomain-cookies]
	Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,		Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011,
	<http://people.mozilla.org/~mgoodwin/SameDomain/		<http://people.mozilla.org/~mgoodwin/SameDomain/
	samedomain-latest.txt>.		samedomain-latest.txt>.
	[secure-contexts]		[secure-contexts]
	West, M., "Secure Contexts", n.d.,		West, M., "Secure Contexts", n.d.,
	<https://w3c.github.io/webappsec-secure-contexts/>.		<https://w3c.github.io/webappsec-secure-contexts/>.
	Appendix A. Acknowledgements		7.3. URIs
			[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
			[2] http://httpwg.github.io/
			[3] https://github.com/httpwg/http-extensions/labels/cookie-same-site
			Appendix A. Changes since draft-ietf-httpbis-cookie-same-site-00
			1. Cookies whose "SameSite" attribute's value is neither "Strict"
			nor "Lax" are ignored.
			Appendix B. Acknowledgements
	The same-site cookie concept documented here is indebited to Mark		The same-site cookie concept documented here is indebited to Mark
	Goodwin's and Joe Walker's [samedomain-cookies]. Michal Zalewski,		Goodwin's and Joe Walker's [samedomain-cookies]. Michal Zalewski,
	Artur Janc, Ryan Sleevi, and Adam Barth provided particularly		Artur Janc, Ryan Sleevi, Adam Barth, and Jeff Hodges provided
	valuable feedback on this document.		particularly valuable feedback on this document.
	Authors' Addresses		Authors' Addresses
	Mike West		Mike West
	Google, Inc		Google, Inc
	Email: mkwst@google.com		Email: mkwst@google.com
	URI: https://mikewest.org/		URI: https://mikewest.org/
	Mark Goodwin		Mark Goodwin
End of changes. 65 change blocks.
	160 lines changed or deleted		193 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/