idnits 2.17.1 draft-iesg-http-cookies-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2109], [RFC-XXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '...bition to the contrary, the server MAY...' RFC 2119 keyword, line 186: '...t. Such servers SHOULD gracefully han...' RFC 2119 keyword, line 197: '...State Management MUST NOT be used to l...' RFC 2119 keyword, line 237: '...State Management SHOULD NOT be used to...' RFC 2119 keyword, line 290: '...e user therefore SHOULD be able to con...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 82 has weird spacing: '... appear capit...' == Line 83 has weird spacing: '...of this speci...' == Line 384 has weird spacing: '...rnished to ot...' == Line 385 has weird spacing: '...herwise expla...' == Line 387 has weird spacing: '...without restr...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2000) is 8767 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-XXXX' ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet Draft University of Tennessee 3 Ned Freed 4 Innosoft 5 7 Use of HTTP State Management 9 April 2000 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026. 16 This document is an Internet-Draft. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 To view the entire list of current Internet-Drafts, please 29 check the "1id-abstracts.txt" listing contained in the 30 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 31 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 32 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 33 Coast), or ftp.isi.edu (US West Coast). 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed 39 at http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2000). All Rights 44 Reserved. 46 Abstract 48 The mechanisms described in "HTTP State Management Mechanism" 49 [RFC-XXXX] and its predecessor [RFC-2109] can be used for many 50 different purposes. However, some current and potential uses 51 of the protocol are controversial because they have 52 significant user privacy and security implications. This memo 53 identifies specific uses of HTTP State Management protocol 54 which are either (a) not recommended by the IETF, or (b) 55 believed to be harmful, and discouraged. This memo also 56 details additional privacy considerations which are not 57 covered by the HTTP State Management protocol specification. 59 1. Introduction 61 The HTTP State Management mechanism is both useful and 62 controversial. It is useful because numerous applications of 63 HTTP benefit from the ability to save state between HTTP 64 transactions, without encoding such state in URLs. It is 65 controversial because the mechanism has been used to 66 accomplish things for which it was not designed and is not 67 well-suited. Some of these uses have attracted a great deal 68 of public criticism because they threaten to violate the 69 privacy of web users, specifically by leaking potentially 70 sensitive information to third parties such as the Web sites a 71 user has visited. There are also other uses of HTTP State 72 Management which are inappropriate even though they do not 73 threaten user privacy. 75 This memo therefore identifies uses of the HTTP State 76 Management protocol specified in RFC-XXXX which are not 77 recommended by the IETF, or which are believed to be harmful 78 and are therefore discouraged. 80 This document occasionally uses terms that appear in capital 81 letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD 82 NOT", and "MAY" appear capitalized, they are being used to 83 indicate particular requirements of this specification. A 84 discussion of the meanings of the terms "MUST", "SHOULD", and 85 "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD 86 NOT" are logical extensions of this usage. 88 2. Uses of HTTP State Management 90 The purpose of HTTP State Management is to allow an HTTP-based 91 service to create stateful ``sessions'' which persist across 92 multiple HTTP transactions. A single session may involve 93 transactions with multiple server hosts. Multiple client hosts 94 may also be involved in a single session when the session data 95 for a particular user is shared between client hosts (e.g., 96 via a networked file system). In other words, the ``session'' 97 retains state between a ``user'' and a ``service'', not 98 between particular hosts. 100 It's important to realize that similar capabilities may also 101 be achieved using the ``bare'' HTTP protocol, and/or 102 dynamically-generated HTML, without the State Management 103 extensions. For example, state information can be transmitted 104 from the service to the user by embedding a session identifier 105 in one or more URLs which appear in HTTP redirects, or 106 dynamically generated HTML; and the state information may be 107 returned from the user to the service when such URLs appear in 108 a GET or POST request. HTML forms can also be used to pass 109 state information from the service to the user and back, 110 without the user being aware of this happening. 112 However, the HTTP State Management facility does provide an 113 increase in functionality over ordinary HTTP and HTML. In 114 practice, this additional functionality includes: 116 (1) The ability to exchange URLs between users, of 117 resources accessed during stateful sessions, without 118 leaking the state information associated with those 119 sessions. (e.g. ``Here's the URL for the FooCorp web 120 catalog entry for those sandals that you wanted.'') 122 (2) The ability to maintain session state without ``cache- 123 busting''. That is, separating the session state from 124 the URL allows a web cache to maintain only a single 125 copy of the named resource. If the state is maintained 126 in session-specific URLs, the cache would likely have 127 to maintain several identical copies of the resource. 129 (3) The ability to implement sessions with minimal server 130 configuration and minimal protocol overhead, as 131 compared to other techniques of maintaining session 132 state. 134 (4) The ability to associate the user with session state 135 whenever a user accesses the service, regardless of 136 whether the user enters through a particular ``home 137 page'' or ``portal''. 139 (5) The ability to save session information in stable 140 storage, so that a ``session'' can be maintained across 141 client invocations, system reboots, and client or 142 system crashes. 144 2.1. Recommended Uses 146 Use of HTTP State Management is appropriate whenever it is 147 desirable to maintain state between a user and a service 148 across multiple HTTP transactions, provided that: 150 (1) the user is aware that session state is being 151 maintained and consents to it, 153 (2) the user has the ability to delete the state associated 154 with such a session at any time, 156 (3) the information obtained through the ability to track 157 the user's usage of the service is not disclosed to 158 other parties without the user's explicit consent, and 160 (4) session information itself cannot contain sensitive 161 information and cannot be used to obtain sensitive 162 information that is not otherwise available to an 163 eavesdropper. 165 This last point is important because cookies are usually sent 166 in the clear and hence are readily available to eavesdroppers. 168 An example of such a recommended use would be a ``shopping 169 cart'', where the existence of the shopping cart is explicitly 170 made known to the user, the user can explicitly ``empty'' his 171 or her shopping cart (either by requesting that it be emptied 172 or by purchasing those items) and thus cause the shared state 173 to be discarded, and the service asserts that it will not 174 disclose the user's shopping or browsing habits to third 175 parties without the user's consent. 177 Note that the HTTP State Management protocol effectively 178 allows a service provider to refuse to provide a service, or 179 provide a reduced level of service, if the user or a user's 180 client fails to honor a request to maintain session state. 181 Absent legal prohibition to the contrary, the server MAY 182 refuse to provide the service, or provide a reduced level of 183 service, under these conditions. As a purely practical 184 consideration, services designed to utilize HTTP State 185 Management may be unable to function properly if the client 186 does not provide it. Such servers SHOULD gracefully handle 187 such conditions and explain to the user why the full level of 188 service is not available. 190 2.2. Problematic Uses 192 The following uses of HTTP State Management are deemed 193 inappropriate and contrary to this specification: 195 2.2.1. Leakage of Information to Third Parties 197 HTTP State Management MUST NOT be used to leak information 198 about the user or the user's browsing habits to other parties 199 besides the user or service, without the user's explicit 200 consent. Such usage is prohibited even if the user's name or 201 other externally-assigned identifier are not exposed to other 202 parties, because the state management mechanism itself 203 provides an identifier which can be used to compile 204 information about the user. 206 Because such practices encourage users to defeat HTTP State 207 Management mechanisms, they tend to reduce the effectiveness 208 of HTTP State Management, and are therefore considered 209 detrimental to the operation of the web. 211 2.2.2. Use as an Authentication Mechanism 213 It is generally inappropriate to use the HTTP State Management 214 protocol as an authentication mechanism. HTTP State 215 Management is not designed with such use in mind, and 216 safeguards for protection of authentication credentials are 217 lacking in both the protocol specification and in widely 218 deployed HTTP clients and servers. Most HTTP sessions are not 219 encrypted and ``cookies'' may therefore be exposed to passive 220 eavesdroppers. Furthermore, HTTP clients and servers 221 typically store ``cookies'' in cleartext with little or no 222 protection against exposure. HTTP State Management therefore 223 SHOULD NOT be used as an authentication mechanism to protect 224 information from being exposed to unauthorized parties, even 225 if the HTTP sessions are encrypted. 227 The prohibition against using HTTP State Management for 228 authentication includes both its use to protect information 229 which is provided by the service, and its use to protect 230 potentially sensitive information about the user which is 231 entrusted to the service's care. For example, it would be 232 inappropriate to expose a user's name, address, telephone 233 number, or billing information to a client that merely 234 presented a cookie which had been previously associated with 235 the user. 237 Similarly, HTTP State Management SHOULD NOT be used to 238 authenticate user requests if unauthorized requests might have 239 undesirable side-effects for the user, unless the user is 240 aware of the potential for such side-effects and explicitly 241 consents to such use. For example, a service which allowed a 242 user to order merchandise with a single ``click'', based 243 entirely on the user's stored ``cookies'', could inconvenience 244 the user by requiring her to dispute charges to her credit 245 card, and/or return the unwanted merchandise, in the event 246 that the cookies were exposed to third parties. 248 Some uses of HTTP State Management to identify users may be 249 relatively harmless, for example, if the only information 250 which can be thus exposed belongs to the service, and the 251 service will suffer little harm from the exposure of such 252 information. 254 3. User Interface Considerations for HTTP State Management 256 HTTP State Management has been very controversial because of 257 its potential to expose information about a user's browsing 258 habits to third parties, without the knowledge or consent of 259 the user. While such exposure is possible, this is less a 260 flaw in the protocol itself than a failure of HTTP client 261 implementations (and of some providers of HTTP-based services) 262 to protect users' interests. 264 As implied above, there are other ways to maintain session 265 state than using HTTP State Management, and therefore other 266 ways in which users' browsing habits can be tracked. Indeed, 267 it is difficult to imagine how the HTTP protocol or an HTTP 268 client could actually prevent a service from disclosing a 269 user's ``click trail'' to other parties if the service chose 270 to do so. Protection of such information from inappropriate 271 exposure must therefore be the responsibility of the service. 272 HTTP client implementations inherently cannot provide such 273 protection, though they can implement countermeasures which 274 make it more difficult for HTTP State Management to be used as 275 the mechanism by which such information is exposed. 277 It is arguable that HTTP clients should provide more 278 protection in general against inappropriate exposure of 279 tracking information, regardless of whether the exposure were 280 facilitated by use of HTTP State Management or by some other 281 means. However, issues related to other mechanisms are beyond 282 the scope of this memo. 284 3.1. Capabilities Required of an HTTP Client 286 A user's willingness to consent to use of HTTP State 287 Management is likely to vary from one service to another, 288 according to whether the user trusts the service to use the 289 information appropriately and to limit its exposure to other 290 parties. The user therefore SHOULD be able to control whether 291 his client supports a service's request to use HTTP State 292 Management, on a per-service basis. In particular: 294 (1) Clients MUST NOT respond to HTTP State Management 295 requests unless explicitly enabled by the user. 297 (2) Clients SHOULD provide an effective interface which 298 allows users to review, and approve or refuse, any 299 particular requests from a server to maintain state 300 information, before the client provides any state 301 information to the server. 303 (3) Clients SHOULD provide an effective interface which 304 allows users to instruct their clients to ignore all 305 requests from a particular service to maintain state 306 information, on a per-service basis, immediately in 307 response to any particular request from a server, 308 before the client provides any state information to the 309 server. 311 (4) Clients SHOULD provide an effective interface which 312 allows a user to disable future transmission of any 313 state information to a service, and/or discard any 314 saved state information for that service, even though 315 the user has previously approved a service's request to 316 maintain state information. 318 (5) Clients SHOULD provide an effective interface which 319 allows a user to terminate a previous request not to 320 retain state management information for a given 321 service. 323 3.2. Limitations of the domain-match algorithm 325 The domain-match algorithm in RFC-XXXX section 2 is intended 326 as a heuristic to allow a client to ``guess'' whether or not 327 two domains are part of the same service. There are few rules 328 about how domain names can be used, and the structure of 329 domain names and how they are delegated varies from one top- 330 level domain to another (i.e. the client cannot tell which 331 part of the domain was assigned to the service). Therefore NO 332 string comparison algorithm (including the domain-match 333 algorithm) can be relied on to distinguish a domain that 334 belongs to a particular service, from a domain that belongs to 335 another party. 337 As stated above, each service is ultimately responsible for 338 ensuring that user information is not inappropriately leaked 339 to third parties. Leaking information to third parties via 340 State Management by careful selection of domain names, or by 341 assigning domain names to hosts maintained by third parties, 342 is at least as inappropriate as leaking the same information 343 by other means. 345 4. Security Considerations 347 This entire memo is about security considerations. 349 5. Authors' Addresses 351 Keith Moore 352 104 Ayres Hall 353 Knoxville, TN 37996 354 moore@cs.utk.edu 356 Ned Freed 357 Innosoft International, Inc. 358 1050 Lakes Drive 359 West Covina, CA 81790 360 ned.freed@innosoft.com 362 6. References 364 [RFC-1123] 365 Braden, R., "Requirements for Internet Hosts -- 366 Application and Support", STD 3, RFC 1123, October, 1989. 368 [RFC-XXXX] 369 Kristol, D., Montulli, L., "HTTP State Management 370 Mechanism", Internet-Draft , work in progress. (To be replaced by the 372 RFC name when this memo is published.) 374 [RFC-2109] 375 Kristol, D., Montulli, L., "HTTP State Management 376 Mechanism", RFC 2109, February 1997. 378 7. Full Copyright Statement 380 Copyright (C) The Internet Society (2000). All Rights 381 Reserved. 383 This document and translations of it may be copied and 384 furnished to others, and derivative works that comment on or 385 otherwise explain it or assist in its implementation may be 386 prepared, copied, published and distributed, in whole or in 387 part, without restriction of any kind, provided that the 388 above copyright notice and this paragraph are included on all 389 such copies and derivative works. However, this document 390 itself may not be modified in any way, such as by removing 391 the copyright notice or references to the Internet Society or 392 other Internet organizations, except as needed for the purpose 393 of developing Internet standards in which case the procedures 394 for copyrights defined in the Internet Standards process must 395 be followed, or as required to translate it into languages 396 other than English. 398 The limited permissions granted above are perpetual and will 399 not be revoked by the Internet Society or its successors or 400 assigns. 402 This document and the information contained herein is provided 403 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 404 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 405 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 406 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 407 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 408 PARTICULAR PURPOSE.