draft-ietf-httpbis-rfc6265bis-04.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: July 23, 2020 January 20, 2020 Expires: July 25, 2020 January 22, 2020
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-04 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 July 23, 2020. This Internet-Draft will expire on July 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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", and [RFC6265] as "a domain that is controlled by a public registry", and
are also known as "effective top-level domains" (eTLDs). For are also known as "effective top-level domains" (eTLDs). For
example, "site.example"'s public suffix is "com". User agents SHOULD example, "site.example"'s public suffix is "example". User agents
use an up-to-date public suffix list, such as the one maintained by SHOULD use an up-to-date public suffix list, such as the one
Mozilla at [PSL]. maintained by Mozilla at [PSL].
An origin's "registered 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, for "https://www.site.example", plus the label to its left. That is, for "https://www.site.example",
the public suffix is "example", and the registered domain is the public suffix is "example", and the registered domain is
"site.example". This concept is defined more rigorously in [PSL], "site.example". This concept is defined more rigorously in [PSL],
and is also known as "effective top-level domain plus one" (eTLD+1). and is also known 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].
skipping to change at page 30, line 16 skipping to change at page 30, line 16
request-host: request-host:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
Otherwise: Otherwise:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us". public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from This step is essential for preventing "attacker.example" from
disrupting the integrity of site.example by setting a cookie disrupting the integrity of "site.example" by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of with a Domain attribute of "example". Unfortunately, the set of
public suffixes (also known as "registry controlled domains") public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an up- changes over time. If feasible, user agents SHOULD use an up-
to-date public suffix list, such as the one maintained by the to-date public suffix list, such as the one maintained by the
Mozilla project at http://publicsuffix.org/ [4]. Mozilla project at http://publicsuffix.org/ [4].
6. If the domain-attribute is non-empty: 6. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If the canonicalized request-host does not domain-match the
domain-attribute: domain-attribute:
skipping to change at page 43, line 29 skipping to change at page 43, line 29
confuse users unless sites' developers carefully ensure that their confuse users unless sites' developers carefully ensure that their
cookie-based session management systems deal reasonably well with cookie-based session management systems deal reasonably well with
top-level 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://site.example/". They might expect Inc's webmail provider "https://site.example/". They might expect
that clicking on an emailed link to "https://projects.example/secret/ that clicking on an emailed link to "https://projects.example/secret/
project" would show them the secret project that they're authorized project" would show them the secret project that they're authorized
to see, but if "projects.example" has marked their session cookies as to see, but if "projects.example" has marked their session cookies as
"SameSite", then this cross-site navigation won't send them along "SameSite", then this cross-site navigation won't send them along
with the request. "projects.com" will render a 404 error to avoid with the request. "projects.example" will render a 404 error to avoid
leaking secret information, and the user will be quite confused. leaking secret information, and the 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 conceptually 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 prompt 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.
 End of changes. 6 change blocks. 
10 lines changed or deleted 10 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/