draft-ietf-httpbis-cookie-alone-00.txt   draft-ietf-httpbis-cookie-alone-01.txt 
HTTP Working Group M. West HTTP Working Group M. West
Internet-Draft Google, Inc Internet-Draft Google, Inc
Updates: 6265 (if approved) February 23, 2016 Updates: 6265 (if approved) September 5, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: August 26, 2016 Expires: March 9, 2017
Deprecate modification of 'secure' cookies from non-secure origins Deprecate modification of 'secure' cookies from non-secure origins
draft-ietf-httpbis-cookie-alone-00 draft-ietf-httpbis-cookie-alone-01
Abstract Abstract
This document updates RFC6265 by removing the ability for a non- This document updates RFC6265 by removing the ability for a non-
secure origin to set cookies with a 'secure' flag, and to overwrite secure origin to set cookies with a 'secure' flag, and to overwrite
cookies whose 'secure' flag is set. This deprecation improves the cookies whose 'secure' flag is set. This deprecation improves the
isolation between HTTP and HTTPS origins, and reduces the risk of isolation between HTTP and HTTPS origins, and reduces the risk of
malicious interference. malicious interference.
Note to Readers
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/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/cookie-alone .
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 http://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 August 26, 2016. This Internet-Draft will expire on March 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and notation . . . . . . . . . . . . . . . . . . 2 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 2 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4 5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 5
B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Section 8.5 and Section 8.6 of [RFC6265] spell out some of the Section 8.5 and Section 8.6 of [RFC6265] spell out some of the
drawbacks of cookies' implementation: due to historical accident, drawbacks of cookies' implementation: due to historical accident,
non-secure origins can set cookies which will be delivered to secure non-secure origins can set cookies which will be delivered to secure
origins in a manner indistinguishable from cookies set by that origin origins in a manner indistinguishable from cookies set by that origin
itself. This enables a number of attacks, which have been recently itself. This enables a number of attacks, which have been recently
spelled out in some detail in [COOKIE-INTEGRITY]. spelled out in some detail in [COOKIE-INTEGRITY].
skipping to change at page 3, line 20 skipping to change at page 3, line 38
denote a "secure" protocol, then abort these steps and ignore denote a "secure" protocol, then abort these steps and ignore
the newly created cookie entirely if the cookie store the newly created cookie entirely if the cookie store
contains one or more cookies that meet all of the following contains one or more cookies that meet all of the following
criteria: criteria:
1. Their "name" matches the "name" of the newly created 1. Their "name" matches the "name" of the newly created
cookie. cookie.
2. Their "secure-only-flag" is set. 2. Their "secure-only-flag" is set.
3. Their "domain" domain-matches the "domain" of the newly 3. Their "domain" domain-matches the "domain" of the newly
created cookie, or vice-versa. created cookie, or vice-versa.
4. The "path" of the newly created cookie path-matches the
"path" of the existing cookie.
Note: This comparison intentionally ignores the "path" Note: The "path" comparison is not symmetric, ensuring only
component. The intent is to allow the "secure" flag to that a newly-created non-secure cookie does not overlay an
supercede the "path" restrictions to protect sites against existing secure cookie, providing some mitigation against
cookie fixing attacks. 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".
Note: This allows "secure" pages to override "secure" cookies Note: This allows "secure" pages to override "secure" cookies
with non-secure variants. Perhaps we should restrict that as with non-secure variants. Perhaps we should restrict that as
well? well?
3. In order to ensure that a non-secure site can never cause a 3. In order to ensure that a non-secure site can never cause a
"secure" cookie to be evisted, adjust the "remove excess cookies" "secure" cookie to be evicted, adjust the "remove excess cookies"
priority order at the bottom of Section 5.3 to be the following: priority order at the bottom of Section 5.3 to be the following:
1. Expired cookies. 1. Expired cookies.
2. Cookies whose "secure-only-flag" is not set and which share a 2. Cookies whose "secure-only-flag" is not set and which share a
"domain" field with more than a predetermined number of other "domain" field with more than a predetermined number of other
cookies. cookies.
3. Cookies that share a "domain" field with more than a 3. Cookies that share a "domain" field with more than a
predetermined number of other cookies. predetermined number of other cookies.
4. All cookies. 4. All cookies.
skipping to change at page 5, line 25 skipping to change at page 5, line 48
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>. <http://www.rfc-editor.org/info/rfc6797>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Richard Barnes encouraged a formalization of the deprecation Richard Barnes encouraged a formalization of the deprecation
proposal. [COOKIE-INTEGRITY] was a useful exploration of the issues proposal. [COOKIE-INTEGRITY] was a useful exploration of the issues
[RFC6265] described. [RFC6265] described.
Appendix B. Changes
B.1. Since -00
o Issue 223 addressed by adding a path-match constraint to the
storage algorithm for non-secure cookies. This ensures that non-
secure cookies cannot overlay secure cookies for a given path, but
allows secure and non-secure cookies with the same name to exist
on distinct paths.
Author's Address Author's Address
Mike West Mike West
Google, Inc Google, Inc
Email: mkwst@google.com Email: mkwst@google.com
URI: https://mikewest.org/ URI: https://mikewest.org/
 End of changes. 13 change blocks. 
14 lines changed or deleted 41 lines changed or added

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