draft-ietf-httpbis-rfc6265bis-07.txt   draft-ietf-httpbis-rfc6265bis-latest.txt 
HTTP Working Group M. West, Ed. HTTP Working Group M. West, Ed.
Internet-Draft Google, Inc Internet-Draft Google, Inc
Obsoletes: 6265 (if approved) J. Wilander, Ed. Obsoletes: 6265 (if approved) J. Wilander, Ed.
Intended status: Standards Track Apple, Inc Intended status: Standards Track Apple, Inc
Expires: June 10, 2021 December 7, 2020 Expires: September 3, 2021 March 2, 2021
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-07 draft-ietf-httpbis-rfc6265bis-latest
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 6265. on the Internet. This document obsoletes RFC 6265.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 https://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 June 10, 2021. This Internet-Draft will expire on September 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
(https://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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 41 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 41
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 43 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 43
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 44 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 44
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 45
9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 45 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 45
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 45 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 45
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 45 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . 48
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 50 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 51
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 50 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 51
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 50 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 51
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 51 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 52
A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 52 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 52
A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 52 A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 53
A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 52 A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 53
A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 52 A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 53
A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 53 A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 53
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53 A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
A domain's "public suffix" is the portion of a domain that is A domain's "public suffix" is the portion of a domain that is
controlled by a public registry, such as "com", "co.uk", and controlled by a public registry, such as "com", "co.uk", and
"pvt.k12.wy.us". A domain's "registrable domain" is the domain's "pvt.k12.wy.us". A domain's "registrable domain" is the domain's
public suffix plus the label to its left. That is, for public suffix plus the label to its left. That is, for
"https://www.site.example", the public suffix is "example", and the "https://www.site.example", the public suffix is "example", and the
registrable domain is "site.example". Whenever possible, user agents registrable domain is "site.example". Whenever possible, user agents
SHOULD use an up-to-date public suffix list, such as the one SHOULD use an up-to-date public suffix list, such as the one
maintained by the Mozilla project at [PSL]. maintained by the Mozilla project at [PSL].
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", "target browsing context", and "url list", are defined in
[FETCH].
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header in an To store state, the origin server includes a Set-Cookie header in an
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
skipping to change at page 20, line 33 skipping to change at page 20, line 33
o The cookie-path is a prefix of the request-path, and the last o The cookie-path is a prefix of the request-path, and the last
character of the cookie-path is %x2F ("/"). character of the cookie-path is %x2F ("/").
o The cookie-path is a prefix of the request-path, and the first o The cookie-path is a prefix of the request-path, and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. "Same-site" and "cross-site" Requests 5.2. "Same-site" and "cross-site" Requests
Two origins, A and B, are considered same-site if the following Two origins are same-site if they satisfy the "same site" criteria
algorithm returns true: defined in [SAMESITE]. A request is "same-site" if the following
criteria are true:
1. If A and B are both the same globally unique identifier, return
true.
2. If A and B are both scheme/host/port triples:
1. If A's scheme does not equal B's scheme, return false.
2. Let hostA be A's host, and hostB be B's host.
3. If hostA equals hostB and hostA's registrable domain is null,
return true.
4. If hostA's registrable domain equals hostB's registrable 1. The request is not the result of a cross-site redirect. That is,
domain and is non-null, return true. the origin of every url in the request's url list is same-site
with the request's current url's origin.
3. Return false. 2. The request is not the result of a reload navigation triggered
through a user interface element (as defined by the user agent;
e.g., a request triggered by the user clicking a refresh button
on a toolbar).
Note: The port component of the origins is not considered. 3. The request's current url's origin is same-site with the
request's client's "site for cookies" (which is an origin), or if
the request has no client or the request's client is null.
A request is "same-site" if its target's URI's origin is same-site Requests which are the result of a reload navigation triggered
with the request's client's "site for cookies" (which is an origin), through a user interface element are same-site if the reloaded
or if the request has no client. The request is otherwise "cross- document was originally navigated to via a same-site request. A
site". request that is not "same-site" is instead "cross-site".
The request's client's "site for cookies" is calculated depending The request's client's "site for cookies" is calculated depending
upon its client's type, as described in the following subsections: upon its client's type, as described in the following subsections:
5.2.1. Document-based requests 5.2.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 origin of that URI represents the context a particular website. The origin of that URI represents the context
skipping to change at page 28, line 9 skipping to change at page 28, line 9
3. If cookie-av's attribute-value is a case-insensitive match for 3. If cookie-av's attribute-value is a case-insensitive match for
"Strict", set "enforcement" to "Strict". "Strict", set "enforcement" to "Strict".
4. If cookie-av's attribute-value is a case-insensitive match for 4. If cookie-av's attribute-value is a case-insensitive match for
"Lax", set "enforcement" to "Lax". "Lax", set "enforcement" to "Lax".
5. Append an attribute to the cookie-attribute-list with an 5. 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".
Note: This algorithm maps the "None" value, as well as any unknown
value, to the "None" behavior, which is helpful for backwards
compatibility when introducing new variants.
5.3.7.1. "Strict" and "Lax" enforcement 5.3.7.1. "Strict" and "Lax" enforcement
Same-site cookies in "Strict" enforcement mode will not be sent along Same-site cookies in "Strict" enforcement mode will not be sent along
with top-level navigations which are triggered from a cross-site with top-level navigations which are triggered from a cross-site
document context. As discussed in Section 8.8.2, this might or might document context. As discussed in Section 8.8.2, this might or might
not be compatible with existing session management systems. In the 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-
skipping to change at page 44, line 21 skipping to change at page 44, line 21
SameSite cookies in and of themselves don't do anything to address SameSite 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 "SameSite" attribute is set by the server, and serves to mitigate The "SameSite" attribute is set by the server, and serves to mitigate
the risk of certain kinds of attacks that the server is worried the risk of certain kinds of attacks that the server is worried
about. The user is not involved in this decision. Moreover, a about. The user is not involved in this decision. Moreover, a
number of side-channels exist which could allow a server to link number of side-channels exist which could allow a server to link
distinct requests even in the absence of cookies (for example, distinct requests even in the absence of cookies (for example,
connection and/or socket pooling between same-site and cross-site connection and/or socket pooling between same-site and cross-site
requests). requests).
8.8.5. Reload navigations
Requests issued for reloads triggered through user interface elements
(such as a refresh button on a toolbar) are same-site only if the
reloaded document was originally navigated to via a same-site
request. This differs from the handling of other reload navigations,
which are always same-site if top-level, since the source browsing
context's active document is precisely the document being reloaded.
This special handling of reloads triggered through a user interface
element avoids sending "SameSite" cookies on user-initiated reloads
if they were withheld on the original navigation (i.e., if the
initial navigation were cross-site). If the reload navigation were
instead considered same-site, and sent all the initially withheld
"SameSite" cookies, the security benefits of withholding the cookies
in the first place would be nullified. This is especially important
given that the absence of "SameSite" cookies withheld on a cross-site
navigation request may lead to visible site breakage, prompting the
user to trigger a reload.
For example, suppose the user clicks on a link from
"https://attacker.example/" to "https://victim.example/". This is a
cross-site request, so "SameSite=Strict" cookies are withheld.
Suppose this causes "https://victim.example/" to appear broken,
because the site only displays its sensitive content if a particular
"SameSite" cookie is present in the request. The user, frustrated by
the unexpectedly broken site, presses refresh on their browser's
toolbar. To now consider the reload request same-site and send the
initially withheld "SameSite" cookie would defeat the purpose of
withholding it in the first place, as the reload navigation triggered
through the user interface may replay the original (potentially
malicious) request. Thus, the reload request should be considered
cross-site, like the request that initially navigated to the page.
9. IANA Considerations 9. IANA Considerations
9.1. Cookie 9.1. Cookie
The permanent message header field registry (see [RFC3864]) needs to The permanent message header field registry (see [RFC3864]) needs to
be updated with the following registration: be updated with the following registration:
Header field name: Cookie Header field name: Cookie
Applicable protocol: http Applicable protocol: http
skipping to change at page 47, line 15 skipping to change at page 47, line 46
[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,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[SAMESITE]
WHATWG, "HTML - Living Standard", January 2021,
<https://html.spec.whatwg.org/#same-site>.
[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/>.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
skipping to change at page 50, line 39 skipping to change at page 51, line 21
[32] https://github.com/httpwg/http-extensions/issues/1159 [32] https://github.com/httpwg/http-extensions/issues/1159
[33] https://github.com/httpwg/http-extensions/issues/1234 [33] https://github.com/httpwg/http-extensions/issues/1234
[34] https://github.com/httpwg/http-extensions/pull/1325 [34] https://github.com/httpwg/http-extensions/pull/1325
[35] https://github.com/httpwg/http-extensions/pull/1323 [35] https://github.com/httpwg/http-extensions/pull/1323
[36] https://github.com/httpwg/http-extensions/pull/1324 [36] https://github.com/httpwg/http-extensions/pull/1324
[37] https://github.com/httpwg/http-extensions/pull/1384
[38] https://github.com/httpwg/http-extensions/pull/1348
Appendix A. Changes Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00 A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes. o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01 A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to o Fixes to formatting caused by mistakes in the initial port to
Markdown: Markdown:
skipping to change at page 53, line 29 skipping to change at page 54, line 17
o Add a default enforcement value to the "same-site-flag", o Add a default enforcement value to the "same-site-flag",
equivalent to "SameSite=Lax": https://github.com/httpwg/http- equivalent to "SameSite=Lax": https://github.com/httpwg/http-
extensions/pull/1325 [34]. extensions/pull/1325 [34].
o Require a Secure attribute for "SameSite=None": o Require a Secure attribute for "SameSite=None":
https://github.com/httpwg/http-extensions/pull/1323 [35]. https://github.com/httpwg/http-extensions/pull/1323 [35].
o Consider scheme when running the same-site algorithm: o Consider scheme when running the same-site algorithm:
https://github.com/httpwg/http-extensions/pull/1324 [36]. https://github.com/httpwg/http-extensions/pull/1324 [36].
A.9. draft-ietf-httpbis-rfc6265bis-08
o Define "same-site" for reload navigation requests, e.g. those
triggered via user interface elements: https://github.com/httpwg/
http-extensions/pull/1384 [37]
o Consider redirects when defining same-site:
https://github.com/httpwg/http-extensions/pull/1348 [38]
Acknowledgements Acknowledgements
RFC 6265 was written by Adam Barth. This document is a minor update RFC 6265 was written by Adam Barth. This document is a minor update
of RFC 6265, adding small features, and aligning the specification of RFC 6265, adding small features, and aligning the specification
with the reality of today's deployments. Here, we're standing upon with the reality of today's deployments. Here, we're standing upon
the shoulders of a giant since the majority of the text is still the shoulders of a giant since the majority of the text is still
Adam's. Adam's.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
47 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/