--- 1/draft-ietf-httpbis-rfc6265bis-09.txt 2022-04-25 00:13:12.112357411 -0700 +++ 2/draft-ietf-httpbis-rfc6265bis-10.txt 2022-04-25 00:13:12.224360241 -0700 @@ -1,176 +1,179 @@ HTTP L. Chen, Ed. Internet-Draft Google LLC Obsoletes: 6265 (if approved) S. Englehardt, Ed. Intended status: Standards Track Mozilla -Expires: 22 April 2022 M. West, Ed. +Expires: 26 October 2022 M. West, Ed. Google LLC J. Wilander, Ed. Apple, Inc - 19 October 2021 + 24 April 2022 Cookies: HTTP State Management Mechanism - draft-ietf-httpbis-rfc6265bis-09 + draft-ietf-httpbis-rfc6265bis-10 Abstract This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. -Note to Readers +About This Document - Discussion of this draft takes place on the HTTP working group - 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/). + This note is to be removed before publishing as an RFC. - Working Group information can be found at http://httpwg.github.io/ - (http://httpwg.github.io/); source code and issues list for this - draft can be found at https://github.com/httpwg/http-extensions/ - labels/6265bis (https://github.com/httpwg/http-extensions/ - labels/6265bis). + Status information for this document may be found at + https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/. + + Discussion of this document takes place on the HTTP Working Group + mailing list (mailto:ietf-http-wg@w3.org), which is archived at + https://lists.w3.org/Archives/Public/ietf-http-wg/. Working Group + information can be found at https://httpwg.org/. + + Source for this draft and an issue tracker can be found at + https://github.com/httpwg/http-extensions/labels/6265bis. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 22 April 2022. + This Internet-Draft will expire on 26 October 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 - 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 - 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 - 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 15 + 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 - 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 + 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18 - 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 - 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 - 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 + 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 19 + 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 20 + 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 20 + 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 21 5.2.1. Document-based requests . . . . . . . . . . . . . . . 21 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 23 - 5.4. The Set-Cookie Header Field . . . . . . . . . . . . . . . 23 + 5.4. The Set-Cookie Header Field . . . . . . . . . . . . . . . 24 5.4.1. The Expires Attribute . . . . . . . . . . . . . . . . 26 - 5.4.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26 - 5.4.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 - 5.4.4. The Path Attribute . . . . . . . . . . . . . . . . . 27 - 5.4.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 - 5.4.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 - 5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 - 5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 29 - 5.6. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 35 - 5.6.1. The Cookie Header Field . . . . . . . . . . . . . . . 35 + 5.4.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 27 + 5.4.3. The Domain Attribute . . . . . . . . . . . . . . . . 27 + 5.4.4. The Path Attribute . . . . . . . . . . . . . . . . . 28 + 5.4.5. The Secure Attribute . . . . . . . . . . . . . . . . 28 + 5.4.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 28 + 5.4.7. The SameSite Attribute . . . . . . . . . . . . . . . 28 + 5.5. Storage Model . . . . . . . . . . . . . . . . . . . . . . 30 + 5.6. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 36 + 5.6.1. The Cookie Header Field . . . . . . . . . . . . . . . 36 5.6.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 36 - 5.6.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 36 - 6. Implementation Considerations . . . . . . . . . . . . . . . . 38 - 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 5.6.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 37 + 6. Implementation Considerations . . . . . . . . . . . . . . . . 39 + 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Application Programming Interfaces . . . . . . . . . . . 39 - 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 39 - 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 - 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 40 - 7.2. Cookie policy . . . . . . . . . . . . . . . . . . . . . . 40 - 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 41 - 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 41 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 - 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41 - 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 42 - 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 42 - 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 43 - 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 44 - 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 44 - 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 45 - 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 45 - 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 46 - 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 46 - 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 47 - 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 47 - 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 47 - 8.8.6. Top-level requests with "unsafe" methods . . . . . . 48 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 - 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 49 - 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 49 - 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 49 - 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 50 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 - 10.2. Informative References . . . . . . . . . . . . . . . . . 52 - Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 54 - A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 54 - A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 54 - A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 55 - A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 55 - A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 56 - A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 56 - A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 56 - A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 57 - A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 57 - A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 58 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 + 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 40 + 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 + 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 41 + 7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 41 + 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 42 + 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 42 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 + 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 43 + 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 43 + 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 44 + 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 44 + 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 45 + 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 46 + 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 47 + 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 47 + 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 47 + 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 47 + 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 48 + 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 48 + 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 48 + 8.8.6. Top-level requests with "unsafe" methods . . . . . . 49 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 50 + 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 50 + 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 51 + 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 51 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 51 + 10.2. Informative References . . . . . . . . . . . . . . . . . 53 + Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 55 + A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 55 + A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 55 + A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 56 + A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 56 + A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 57 + A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 57 + A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 57 + A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 58 + A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 58 + A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 59 + A.11. draft-ietf-httpbis-rfc6265bis-10 . . . . . . . . . . . . 59 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 1. Introduction This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header field. @@ -437,49 +441,50 @@ ; whitespace DQUOTE, comma, semicolon, ; and backslash cookie-av = expires-av / max-age-av / domain-av / path-av / secure-av / httponly-av / samesite-av / extension-av expires-av = "Expires" BWS "=" BWS sane-cookie-date sane-cookie-date = max-age-av = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT - ; In practice, both expires-av and max-age-av - ; are limited to dates representable by the - ; user agent. non-zero-digit = %x31-39 ; digits 1 through 9 domain-av = "Domain" BWS "=" BWS domain-value domain-value = - ; defined in [RFC1034], Section 3.5, as - ; enhanced by [RFC1123], Section 2.1 + ; see details below path-av = "Path" BWS "=" BWS path-value path-value = *av-octet secure-av = "Secure" httponly-av = "HttpOnly" samesite-av = "SameSite" BWS "=" BWS samesite-value samesite-value = "Strict" / "Lax" / "None" extension-av = *av-octet av-octet = %x20-3A / %x3C-7E ; any CHAR except CTLs or ";" Note that some of the grammatical terms above reference documents that use different grammatical notations than this document (which uses ABNF from [RFC5234]). The semantics of the cookie-value are not defined by this document. To maximize compatibility with user agents, servers that wish to store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 [RFC4648]. + The domain-value is a subdomain as defined by [RFC1034], Section 3.5, + and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a + string of [USASCII] characters, such as one obtained by applying the + "ToASCII" operation defined in Section 4 of [RFC3490]. + Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters. Note that in this case, the initial and trailing DQUOTE characters are not stripped. They are part of the cookie-value, and will be included in Cookie header fields sent to the server. The portions of the set-cookie-string produced by the cookie-av term are known as attributes. To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string. (See Section 5.5 for how user agents handle this case.) @@ -527,28 +532,42 @@ attributes (but not the entire cookie). 4.1.2.1. The Expires Attribute The Expires attribute indicates the maximum lifetime of the cookie, represented as the date and time at which the cookie expires. The user agent is not required to retain the cookie until the specified date has passed. In fact, user agents often evict cookies due to memory pressure or privacy concerns. + The user agent MUST limit the maximum value of the Expires attribute. + The limit SHOULD NOT be greater than 400 days (34560000 seconds) in + the future. The RECOMMENDED limit is 400 days in the future, but the + user agent MAY adjust the limit (see Section 7.2). Expires + attributes that are greater than the limit MUST be reduced to the + limit. + 4.1.2.2. The Max-Age Attribute The Max-Age attribute indicates the maximum lifetime of the cookie, represented as the number of seconds until the cookie expires. The user agent is not required to retain the cookie for the specified duration. In fact, user agents often evict cookies due to memory pressure or privacy concerns. + The user agent MUST limit the maximum value of the Max-Age attribute. + The limit SHOULD NOT be greater than 400 days (34560000 seconds) in + duration. The RECOMMENDED limit is 400 days in duration, but the + user agent MAY adjust the limit (see Section 7.2). Max-Age + attributes that are greater than the limit MUST be reduced to the + limit. + NOTE: Some existing user agents do not support the Max-Age attribute. User agents that do not support the Max-Age attribute ignore the attribute. If a cookie has both the Max-Age and the Expires attribute, the Max- Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent). @@ -764,21 +783,22 @@ flags defined as a part of the algorithm (i.e., found-time, found- day-of-month, found-month, found-year) are initially "not set". 1. Using the grammar below, divide the cookie-date into date-tokens. cookie-date = *delimiter date-token-list *delimiter date-token-list = date-token *( 1*delimiter date-token ) date-token = 1*non-delimiter delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E - non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF + non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA + / %x7F-FF non-digit = %x00-2F / %x3A-FF day-of-month = 1*2DIGIT [ non-digit *OCTET ] month = ( "jan" / "feb" / "mar" / "apr" / "may" / "jun" / "jul" / "aug" / "sep" / "oct" / "nov" / "dec" ) *OCTET year = 2*4DIGIT [ non-digit *OCTET ] time = hms-time [ non-digit *OCTET ] hms-time = time-field ":" time-field ":" time-field time-field = 1*2DIGIT @@ -1077,20 +1097,25 @@ characters that are not cookie-octets according to the grammar in Section 4.1. User agents use this algorithm so as to interoperate with servers that do not follow the recommendations in Section 4. NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm handles them explicitly. Horizontal tab (%x09) is excluded from the CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. + NOTE: The set-cookie-string may contain octet sequences that appear + percent-encoded as per Section 2.1 of [RFC3986]. However, a user + agent MUST NOT decode these sequences and instead parse the + individual octets as specified in this algorithm. + A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string: 1. If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F character (CTL characters excluding HTAB): Abort these steps and ignore the set-cookie-string entirely. 2. If the set-cookie-string contains a %x3B (";") character: 1. The name-value-pair string consists of the characters up to, @@ -1179,50 +1204,58 @@ If the attribute-name case-insensitively matches the string "Expires", the user agent MUST process the cookie-av as follows. 1. Let the expiry-time be the result of parsing the attribute-value as cookie-date (see Section 5.1.1). 2. If the attribute-value failed to parse as a cookie date, ignore the cookie-av. - 3. If the expiry-time is later than the last date the user agent can - represent, the user agent MAY replace the expiry-time with the - last representable date. + 3. Let cookie-age-limit be the maximum age of the cookie (which + SHOULD be 400 days in the future or sooner, see Section 4.1.2.1). - 4. If the expiry-time is earlier than the earliest date the user + 4. If the expiry-time is more than cookie-age-limit, the user agent + MUST set the expiry time to cookie-age-limit in seconds. + + 5. If the expiry-time is earlier than the earliest date the user agent can represent, the user agent MAY replace the expiry-time with the earliest representable date. - 5. Append an attribute to the cookie-attribute-list with an + 6. Append an attribute to the cookie-attribute-list with an attribute-name of Expires and an attribute-value of expiry-time. 5.4.2. The Max-Age Attribute If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows. 1. If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av. 2. If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av. 3. Let delta-seconds be the attribute-value converted to an integer. - 4. If delta-seconds is less than or equal to zero (0), let expiry- + 4. Let cookie-age-limit be the maximum age of the cookie (which + SHOULD be 400 days or less, see Section 4.1.2.2). + + 5. Set delta-seconds to the smaller of its present value and cookie- + age-limit. + + 6. If delta-seconds is less than or equal to zero (0), let expiry- time be the earliest representable date and time. Otherwise, let the expiry-time be the current date and time plus delta-seconds seconds. - 5. Append an attribute to the cookie-attribute-list with an + 7. Append an attribute to the cookie-attribute-list with an attribute-name of Max-Age and an attribute-value of expiry-time. 5.4.3. The Domain Attribute If the attribute-name case-insensitively matches the string "Domain", the user agent MUST process the cookie-av as follows. 1. Let cookie-domain be the attribute-value. 2. If cookie-domain starts with %x2E ("."), let cookie-domain be @@ -1339,31 +1372,33 @@ recently. Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit. If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST apply the following modification to the retrieval algorithm defined in Section 5.6.3: Replace the condition in the penultimate bullet point of step 1 of the retrieval algorithm reading - * The HTTP request associated with the retrieval uses a "safe" method. + * The HTTP request associated with the retrieval uses a "safe" + method. with * At least one of the following is true: - 1. The HTTP request associated with the retrieval uses a "safe" method. + 1. The HTTP request associated with the retrieval uses a "safe" + method. - 2. The cookie's same-site-flag is "Default" and the amount of time - elapsed since the cookie's creation-time is at most a duration of the - user agent's choosing. + 2. The cookie's same-site-flag is "Default" and the amount of + time elapsed since the cookie's creation-time is at most a + duration of the user agent's choosing. 5.5. Storage Model The user agent stores the following fields about each cookie: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, http-only-flag, and same-site-flag. When the user agent "receives a cookie" from a request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute- @@ -1421,80 +1456,84 @@ attribute-name of "Domain" and an attribute-value whose length is no more than 1024 octets. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.) Otherwise: 1. Let the domain-attribute be the empty string. - 8. If the user agent is configured to reject "public suffixes" and + 8. If the domain-attribute contains a character that is not in the + range of [USASCII] characters, abort these steps and ignore the + cookie entirely. + + 9. If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix: 1. If the domain-attribute is identical to the canonicalized request-host: 1. Let the domain-attribute be the empty string. Otherwise: - 1. Ignore the cookie entirely and abort these steps. + 1. Abort these steps and ignore the cookie entirely. NOTE: This step prevents attacker.example from disrupting the integrity of site.example by setting a cookie with a Domain attribute of "example". - 9. If the domain-attribute is non-empty: + 10. If the domain-attribute is non-empty: 1. If the canonicalized request-host does not domain-match the domain-attribute: - 1. Ignore the cookie entirely and abort these steps. + 1. Abort these steps and ignore the cookie entirely. Otherwise: 1. Set the cookie's host-only-flag to false. 2. Set the cookie's domain to the domain-attribute. Otherwise: 1. Set the cookie's host-only-flag to true. 2. Set the cookie's domain to the canonicalized request-host. - 10. If the cookie-attribute-list contains an attribute with an + 11. If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute- value of the last attribute in the cookie-attribute-list with both an attribute-name of "Path" and an attribute-value whose length is no more than 1024 octets. Otherwise, set the cookie's path to the default-path of the request-uri. - 11. If the cookie-attribute-list contains an attribute with an + 12. If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", set the cookie's secure-only-flag to true. Otherwise, set the cookie's secure-only-flag to false. - 12. If the scheme component of the request-uri does not denote a + 13. If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. - 13. If the cookie-attribute-list contains an attribute with an + 14. If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false. - 14. If the cookie was received from a "non-HTTP" API and the + 15. If the cookie was received from a "non-HTTP" API and the cookie's http-only-flag is true, abort these steps and ignore the cookie entirely. - 15. If the cookie's secure-only-flag is false, and the scheme + 16. If the cookie's secure-only-flag is false, and the scheme component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: 1. Their name matches the name of the newly-created cookie. 2. Their secure-only-flag is true. 3. Their domain domain-matches the domain of the newly-created @@ -1504,28 +1543,28 @@ of the existing cookie. Note: The path comparison is not symmetric, ensuring only that a newly-created, non-secure cookie does not overlay an existing secure cookie, providing some mitigation against cookie-fixing attacks. That is, given an existing secure cookie named 'a' with a path of '/login', a non-secure cookie named 'a' could be set for a path of '/' or '/foo', but not for a path of '/login' or '/login/en'. - 16. If the cookie-attribute-list contains an attribute with an + 17. If the cookie-attribute-list contains an attribute with an attribute-name of "SameSite", and an attribute-value of "Strict", "Lax", or "None", set the cookie's same-site-flag to the attribute-value of the last attribute in the cookie- attribute-list with an attribute-name of "SameSite". Otherwise, set the cookie's same-site-flag to "Default". - 17. If the cookie's same-site-flag is not "None": + 18. If the cookie's same-site-flag is not "None": 1. If the cookie was received from a "non-HTTP" API, and the API was called from a browsing context's active document whose "site for cookies" is not same-site with the top-level origin, then abort these steps and ignore the newly created cookie entirely. 2. If the cookie was received from a "same-site" request (as defined in Section 5.2), skip the remaining substeps and continue processing the cookie. @@ -1538,57 +1577,57 @@ processing the cookie. Note: Top-level navigations can create a cookie with any SameSite value, even if the new cookie wouldn't have been sent along with the request had it already existed prior to the navigation. 4. Abort these steps and ignore the newly created cookie entirely. - 18. If the cookie's "same-site-flag" is "None", abort these steps + 19. If the cookie's "same-site-flag" is "None", abort these steps and ignore the cookie entirely unless the cookie's secure-only- flag is true. - 19. If the cookie-name begins with a case-sensitive match for the + 20. If the cookie-name begins with a case-sensitive match for the string "__Secure-", abort these steps and ignore the cookie entirely unless the cookie's secure-only-flag is true. - 20. If the cookie-name begins with a case-sensitive match for the + 21. If the cookie-name begins with a case-sensitive match for the string "__Host-", abort these steps and ignore the cookie entirely unless the cookie meets all the following criteria: 1. The cookie's secure-only-flag is true. 2. The cookie's host-only-flag is true. 3. The cookie-attribute-list contains an attribute with an attribute-name of "Path", and the cookie's path is /. - 21. If the cookie store contains a cookie with the same name, + 22. If the cookie store contains a cookie with the same name, domain, host-only-flag, and path as the newly-created cookie: 1. Let old-cookie be the existing cookie with the same name, domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) 2. If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps and ignore the newly created cookie entirely. 3. Update the creation-time of the newly-created cookie to match the creation-time of the old-cookie. 4. Remove the old-cookie from the cookie store. - 22. Insert the newly-created cookie into the cookie store. + 23. Insert the newly-created cookie into the cookie store. A cookie is "expired" if the cookie has an expiry date in the past. The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store. At any time, the user agent MAY "remove excess cookies" from the cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies). @@ -1804,70 +1843,109 @@ have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895] in order to facilitate their IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490]. 7. Privacy Considerations - Cookies are often criticized for letting servers track users. For - example, a number of "web analytics" companies use cookies to - recognize when a user returns to a web site or visits another web - site. Although cookies are not the only mechanism servers can use to - track users across HTTP requests, cookies facilitate tracking because - they are persistent across user agent sessions and can be shared - between hosts. + Cookies' primary privacy risk is their ability to correlate user + activity. This can happen on a single site, but is most problematic + when activity is tracked across different, seemingly unconnected Web + sites to build a user profile. -7.1. Third-Party Cookies + Over time, this capability (warned against explicitly in [RFC2109] + and all of its successors) has become widely used for varied reasons + including: - Particularly worrisome are so-called "third-party" cookies. In - rendering an HTML document, a user agent often requests resources - from other servers (such as advertising networks). These third-party - servers can use cookies to track the user even if the user never - visits the server directly. For example, if a user visits a site - that contains content from a third party and then later visits - another site that contains content from the same third party, the - third party can track the user between the two sites. + * authenticating users across sites, - Given this risk to user privacy, some user agents restrict how third- - party cookies behave, and those restrictions vary widly. For - instance, user agents might block third-party cookies entirely by - refusing to send Cookie header fields or process Set-Cookie header - fields during third-party requests. They might take a less draconian - approach by partitioning cookies based on the first-party context, - sending one set of cookies to a given third party in one first-party - context, and another to the same third party in another. Or they - might even allow some third-party cookies but block others depending - on user-agent cookie policy or user controls. + * assembling information on users, - This document grants user agents wide latitude to experiment with - third-party cookie policies that balance the privacy and - compatibility needs of their users. However, this document does not - endorse any particular third-party cookie policy. + * protecting against fraud and other forms of undesirable traffic, - Third-party cookie blocking policies are often ineffective at - achieving their privacy goals if servers attempt to work around their - restrictions to track users. In particular, two collaborating - servers can often track users without using cookies at all by - injecting identifying information into dynamic URLs. + * targeting advertisements at specific users or at users with + specified attributes, -7.2. Cookie policy + * measuring how often ads are shown to users, and + + * recognizing when an ad resulted in a change in user behavior. + + While not every use of cookies is necessarily problematic for + privacy, their potential for abuse has become a widespread concern in + the Internet community and broader society. In response to these + concerns, user agents have actively constrained cookie functionality + in various ways (as allowed and encouraged by previous + specifications), while avoiding disruption to features they judge + desirable for the health of the Web. + + It is too early to declare consensus on which specific mechanism(s) + should be used to mitigate cookies' privacy impact; user agents' + ongoing changes to how they are handled are best characterised as + experiments that can provide input into that eventual consensus. + + Instead, this document describes limited, general mitigations against + the privacy risks associated with cookies that enjoy wide deployment + at the time of writing. It is expected that implementations will + continue to experiment and impose stricter, more well-defined + limitations on cookies over time. Future versions of this document + might codify those mechanisms based upon deployment experience. If + functions that currently rely on cookies can be supported by + separate, targeted mechanisms, they might be documented in separate + specifications and stricter limitations on cookies might become + feasible. + + Note that cookies are not the only mechanism that can be used to + track users across sites, so while these mitigations are necessary to + improve Web privacy, they are not sufficient on their own. + +7.1. Third-Party Cookies + + A "third-party" or cross-site cookie is one that is associated with + embedded content (such as scripts, images, stylesheets, frames) that + is obtained from a different server than the one that hosts the + primary resource (usually, the Web page that the user is viewing). + Third-party cookies are often used to correlate users' activity on + different sites. + + Because of their inherent privacy issues, most user agents now limit + third-party cookies in a variety of ways. Some completely block + third-party cookies by refusing to process third-party Set-Cookie + header fields and refusing to send third-party Cookie header fields. + Some partition cookies based upon the first-party context, so that + different cookies are sent depending on the site being browsed. Some + block cookies based upon user agent cookie policy and/or user + controls. + + While this document does not endorse or require a specific approach, + it is RECOMMENDED that user agents adopt a policy for third-party + cookies that is as restrictive as compatibility constraints permit. + Consequently, resources cannot rely upon third-party cookies being + treated consistently by user agents for the foreseeable future. + +7.2. Cookie Policy User agents MAY enforce a cookie policy consisting of restrictions on how cookies may be used or ignored (see Section 5.3). A cookie policy may govern which domains or parties, as in first and third parties (see Section 7.1), for which the user agent will allow cookie access. The policy can also define limits on cookie size, - cookie expiry, and the number of cookies per domain or in total. + cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the + number of cookies per domain or in total. + + The recomended cookie expiry upper limit is 400 days. User agents + may set a lower limit to enforce shorter data retention timelines, or + set the limit higher to support longer retention when appropriate + (e.g., server-to-server communication over HTTPS). The goal of a restrictive cookie policy is often to improve security or privacy. User agents often allow users to change the cookie policy (see Section 7.3). 7.3. User Controls User agents SHOULD provide users with a mechanism for managing the cookies stored in the cookie store. For example, a user agent might let users delete all cookies received during a specified time period @@ -2427,20 +2508,24 @@ cookie-same-site-00>. [prerendering] Bentzel, C., "Chrome Prerendering", n.d., . [PSL] "Public Suffix List", n.d., . + [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management + Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, + . + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, @@ -2678,38 +2763,41 @@ extensions/pull/1576) * No longer treat horizontal tab as a control character: https://github.com/httpwg/http-extensions/pull/1589 (https://github.com/httpwg/http-extensions/pull/1589) * Specify empty domain attribute handling: https://github.com/httpwg/http-extensions/pull/1709 (https://github.com/httpwg/http-extensions/pull/1709) +A.11. draft-ietf-httpbis-rfc6265bis-10 + + * Standardize Max-Age/Expires upper bound: + https://github.com/httpwg/http-extensions/pull/1732 + (https://github.com/httpwg/http-extensions/pull/1732) + Acknowledgements RFC 6265 was written by Adam Barth. This document is an update of RFC 6265, adding features and aligning the specification 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 Adam's. Authors' Addresses + Lily Chen (editor) Google LLC - Email: chlily@google.com Steven Englehardt (editor) Mozilla - Email: senglehardt@mozilla.com Mike West (editor) Google LLC - Email: mkwst@google.com URI: https://mikewest.org/ John Wilander (editor) Apple, Inc - Email: wilander@apple.com