draft-ietf-httpbis-cookie-prefixes-00.txt   draft-ietf-httpbis-cookie-prefixes-latest.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) July 6, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: August 26, 2016 Expires: January 7, 2025
Cookie Prefixes Cookie Prefixes
draft-ietf-httpbis-cookie-prefixes-00 draft-ietf-httpbis-cookie-prefixes-00
Abstract Abstract
This document updates RFC6265 by adding a set of restrictions upon This document updates RFC6265 by adding a set of restrictions upon
the names which may be used for cookies with specific properties. the names which may be used for cookies with specific properties.
These restrictions enable user agents to smuggle cookie state to the These restrictions enable user agents to smuggle cookie state to the
server within the confines of the existing "Cookie" request header server within the confines of the existing "Cookie" request header
syntax, and limits the ways in which cookies may be abused in a syntax, and limits the ways in which cookies may be abused in a
conforming user agent. conforming user agent.
Status of this Memo 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/ [1].
Working Group information can be found at http://httpwg.github.io/
[2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/cookie-prefixes [3].
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 August 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and notation . . . . . . . . . . . . . . . . . . . 3 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3
3. Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The "__Secure-" prefix . . . . . . . . . . . . . . . . . . 3 3.1. The "__Secure-" prefix . . . . . . . . . . . . . . . . . 3
3.2. The "__Host-" prefix . . . . . . . . . . . . . . . . . . . 4 3.2. The "__Host-" prefix . . . . . . . . . . . . . . . . . . 3
4. User Agent Requirements . . . . . . . . . . . . . . . . . . . . 4 4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 4
5. Aesthetic Considerations . . . . . . . . . . . . . . . . . . . 5 5. Aesthetic Considerations . . . . . . . . . . . . . . . . . . 4
5.1. Not pretty. . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Not pretty. . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Why "__"? . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Why "__"? . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. Secure Origins Only . . . . . . . . . . . . . . . . . . . . 5 6.1. Secure Origins Only . . . . . . . . . . . . . . . . . . . 5
6.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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, it drawbacks of cookies' implementation: due to historical accident, it
is impossible for a server to have confidence that a cookie set in a is impossible for a server to have confidence that a cookie set in a
secure way (e.g., as a domain cookie with the "Secure" (and possibly secure way (e.g., as a domain cookie with the "Secure" (and possibly
"HttpOnly") flags set) remains intact and untouched by non-secure "HttpOnly") flags set) remains intact and untouched by non-secure
subdomains. subdomains.
skipping to change at page 6, line 4 skipping to change at page 5, line 41
6.2. Limitations 6.2. Limitations
This scheme gives no assurance to the server that the restrictions on This scheme gives no assurance to the server that the restrictions on
cookie names are enforced. Servers could certainly probe the user cookie names are enforced. Servers could certainly probe the user
agent's functionality to determine support, or sniff based on the agent's functionality to determine support, or sniff based on the
"User-Agent" request header, if such assurances were deemed "User-Agent" request header, if such assurances were deemed
necessary. necessary.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[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>.
7.2. Informative References 7.2. Informative References
[DEPRECATING-HTTP] [DEPRECATING-HTTP]
Barnes, R., "Deprecating Non-Secure HTTP", April 2015, <ht Barnes, R., "Deprecating Non-Secure HTTP", April 2015,
tps://blog.mozilla.org/security/2015/04/30/ <https://blog.mozilla.org/security/2015/04/30/deprecating-
deprecating-non-secure-http/>. non-secure-http/>.
[Lawrence2015] [Lawrence2015]
Lawrence, E., "Duct Tape and Baling Wire -- Cookie Lawrence, E., "Duct Tape and Baling Wire -- Cookie
Prefixes", October 2015, <http://textslashplain.com/2015/ Prefixes", October 2015,
10/09/duct-tape-and-baling-wirecookie-prefixes/>. <http://textslashplain.com/2015/10/09/duct-tape-and-
baling-wirecookie-prefixes/>.
[POWERFUL-FEATURES] [POWERFUL-FEATURES]
Palmer, C., "Prefer Secure Origins for Powerful New Palmer, C., "Prefer Secure Origins for Powerful New
Features", 2015, <https://www.chromium.org/Home/ Features", 2015, <https://www.chromium.org/Home/chromium-
chromium-security/ security/prefer-secure-origins-for-powerful-new-features>.
prefer-secure-origins-for-powerful-new-features>.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997,
<http://www.rfc-editor.org/info/rfc2109>. <https://www.rfc-editor.org/info/rfc2109>.
[SECURE-CONTEXTS] [SECURE-CONTEXTS]
West, M., "Secure Contexts", 2016, West, M., "Secure Contexts", 2016,
<https://w3c.github.io/webappsec-secure-contexts/>. <https://w3c.github.io/webappsec-secure-contexts/>.
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-prefixes
Appendix A. Acknowledgements Appendix A. Acknowledgements
Eric Lawrence had this idea a million years ago, and wrote about its Eric Lawrence had this idea a million years ago, and wrote about its
genesis in [Lawrence2015]. Devdatta Akhawe helped justify the genesis in [Lawrence2015]. Devdatta Akhawe helped justify the
potential impact of the scheme on real-world websites. Thomas Broyer potential impact of the scheme on real-world websites. Thomas Broyer
pointed out the issues with a leading "$" in the prefixes, and Brian pointed out the issues with a leading "$" in the prefixes, and Brian
Smith provided valuable contributions to the discussion around a Smith provided valuable contributions to the discussion around a
replacement (ISO C indeed). replacement (ISO C indeed).
Author's Address Author's Address
 End of changes. 17 change blocks. 
38 lines changed or deleted 58 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/