idnits 2.17.1 draft-west-nonhttp-cookies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Whether or not a cookie is flagged as "NonHttp" MUST not affect eviction behavior in general. Cookies are cookies, no matter their flags, so the "remove excess cookies" constraints, expiration behavior, and "persistent-flag" behavior discussed in the current step 12 of Section 5.3 of [RFC6265] would still apply. -- The document date (June 6, 2017) is 2517 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. West 3 Internet-Draft Google, Inc 4 Updates: 6265 (if approved) June 6, 2017 5 Intended status: Standards Track 6 Expires: December 8, 2017 8 Non-HTTP Cookies 9 draft-west-nonhttp-cookies-00 11 Abstract 13 This document updates RFC6265 by defining a "NonHttp" attribute which 14 ensures that a given cookie is available only to "non-HTTP" APIs. 15 Yes, it is a little strange for "HTTP State Management" to support 16 exclusively non-HTTP use cases, but the internet is a strange place. 17 So it goes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 8, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3 56 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security and Privacy Considerations . . . . . . . . . . . . . 5 58 4.1. Cross-origin storage capabilities . . . . . . . . . . . . 5 59 4.2. Fewer Cookies on the Wire . . . . . . . . . . . . . . . . 5 60 4.3. Legacy Clients . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Other Constraints . . . . . . . . . . . . . . . . . . . . 6 62 5. Aesthetic Considerations . . . . . . . . . . . . . . . . . . 6 63 5.1. Isn't 'DOMOnly' a better name? Or 'NoHttp'? Or 'Insert 64 Bikeshed Here'? . . . . . . . . . . . . . . . . . . . . . 6 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Cookies violate the same-origin policy in well-understood ways, 72 outlined in Sections 8.5 and 8.6 of [RFC6265]. For better or worse, 73 developers rely on this behavior. In particular, it is quite common 74 for developers to use cookies as a cross-origin storage mechanism, 75 allowing state to be shared across all origins in a given registrable 76 domain. A user who signs into "https://m.example.com/" might expect 77 to also be signed into "https://www.example.com/", and vice-versa. 78 Servers can support this expectation by setting a cookie at the apex 79 domain: "uid=1234567;Secure;Domain=example.com". The cookie will be 80 sent along with HTTP requests to both origins, and the user's state 81 can be maintained server-side. 83 Often, though, the fact that a cookie is sent over the wire is an 84 unindended side-effect. Developers may be using cookies to easily 85 share client-side state between related origins, and have pressed 86 cookies into this service due to their unique security properties. 88 For example, web analytics packages might use a user agent's 89 "document.cookie" API to set first-party cookies on a client's site 90 that retain a user's state. This gives them the information they 91 need to do analytics work, but has the very unfortunate side-effect 92 of causing those cookies to be sent along with requests to the first- 93 party's server. This has a substantially negative impact on request 94 size (and therefore performance), and also on privacy, as these 95 cookies often contain identifiers, and are often sent in plaintext 96 over the network. 98 This document aims to reduce both impacts by allowing developers to 99 specify specific cookies as "NonHttp". These cookies cannot be set 100 or modified via "Set-Cookie" HTTP response headers, nor will they be 101 included in "Cookie" HTTP request headers. They are only accessible 102 via "non-HTTP" APIs, satisfying purely client-side storage 103 requirements. 105 1.1. Examples 107 Non-HTTP cookies are only accessible via "non-HTTP" APIs. For 108 example, a developer might use HTML's "document.cookie" to set a non- 109 HTTP cookie as follows: 111 document.cookie = "name=value; Secure; NonHttp"; 113 That cookie would be available via subsequent calls to 114 "document.cookie", but will not be included as a "Cookie" header in 115 HTTP requests to the developer's server. 117 The same cookie would not be accepted if set via a "Set-Cookie" 118 header. That is, the following header would result in no change to 119 the user agent's cookie store: 121 Set-Cookie: name=value; Secure; NonHttp 123 Likewise, cookies that contain both the "NonHttp" and "HttpOnly" 124 flags will be ignored. The following is a no-op: 126 document.cookie = "name=value; Secure; NonHttp; HttpOnly" 128 As is the following: 130 Set-Cookie: name=value; Secure; NonHttp; HttpOnly 132 2. Terminology and notation 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Recommendations 140 This section describes extensions to [RFC6265] necessary to implement 141 the "NonHttp" attribute. 143 1. Extend the "cookie-av" grammar in Section 4.1.1 of [RFC6265] as 144 follows: 146 cookie-av = expires-av / max-age-av / domain-av / 147 path-av / secure-av / httponly-av / 148 nohttp-av / extension-av 149 nohttp-av = "NoHttp" 151 2. Add a section to Section 4.1.2 of [RFC6265] describing the 152 semantics of the "NonHttp" attribute as follows: 154 The "NonHttp" attribute limits the scope of the cookie to "non- 155 HTTP" APIs. That is, the attribute instructs the user agent to 156 omit the cookie when constructing a "Cookie" header for an HTTP 157 request. 159 If both the "NonHttp" and "HttpOnly" attributes are present when 160 setting a cookie, the cookie will be ignored, regardless of its 161 delivery mechanism. 163 3. Alter the storage model defined in Section 5.3 of [RFC6265] as 164 follows: 166 1. Add "no-http-flag" as a field to be stored on each cookie. 168 2. Insert the following two steps after the current step 10: 170 1. If the "cookie-attribute-list" contains an attribute with 171 an "attribute-name" of "NoHttp", set the cookie's "no- 172 http-flag" to "true". Otherwise, set the cookie's "no- 173 http-flag" to "false". 175 2. If the cookie was not received from a "non-HTTP" API, and 176 the cookie's "no-http-flag" is "true", abort these steps 177 and ignore the cookie entirely. 179 3. Insert the following step after the current step 11.2: 181 1. If the newly created cookie was not received from a "non- 182 HTTP" API, and the "old-cookie"'s "no-http-flag" is 183 "true", abort these steps and ignore the newly created 184 cookie entirely. 186 4. Add a section to Section 5.2 of [RFC6265] describing the 187 processing requirements for the "NonHttp" attribute as follows: 189 If the "attribute-name" case-insensitively matches the string 190 "NonHttp", the user agent MUST append an attribute to the 191 "cookie-attribute-list" with an "attribute-name" of "NonHttp" and 192 an empty "attribute-value". 194 5. Alter the "Cookie" header generation in Section 5.4 of [RFC6265] 195 as follows: 197 1. Add the following requirement to the list of requirements in 198 the current step 1: 200 + If the cookie's "no-http-flag" is "true", then exclude the 201 cookie if the "cookie-string" is not being generated for a 202 "non-HTTP" API (as defined by the user agent). 204 4. Security and Privacy Considerations 206 4.1. Cross-origin storage capabilities 208 There's a risk that allowing developers to suppress cookies from HTTP 209 requests might lead to increased usage of cookies as a cross-origin 210 storage mechanism. Given existing usage, however, the worst case 211 seems to be an increase from a high number to a marginally higher 212 number. 214 Note, though, that the capabilities provided here can already be 215 obtained through clever use of the "path" attribute to scope cookies 216 down to paths that aren't frequently requested. These cookies can be 217 accessed through clever use of "