RFC 2964

Use of HTTP State Management

📅 published October 2000, from ietf

Use of HTTP State Management 🎀

Okay bestie, this is RFC 2964, a Best Current Practice (BCP 44) from the Network Working Group, and it is giving "read this before you build a cookie thing" 💅✨

It was written by K. Moore (University of Tennessee) and N. Freed (Innosoft). The category is Best Current Practice, and the date is October 2000 📅 The title block doesn't say it obsoletes or updates anything, so it's just vibing on its own 🌸

Status of this Memo 📝

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 🦋

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

IESG Note 🚨

The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. 🙈

Abstract ✨

Okay so the mechanisms in "HTTP State Management Mechanism" (RFC-2965), and its predecessor (RFC-2109), can be used for a LOT of different purposes 🍓 The thing is, some current and potential uses are controversial, because they have big user privacy and security implications 😬

This memo calls out specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol that are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. It also goes into extra privacy considerations that the HTTP State Management protocol specification doesn't cover. Main character energy for privacy 🔥

1. Introduction 🧚

HTTP State Management is both useful and controversial, and that's the tea ☕ It's useful because lots of HTTP applications benefit from being able to save state between HTTP transactions, without encoding that state in URLs. It's controversial because the mechanism has been used for things it was never designed for, and it's not well-suited to them. Some of these uses got a lot of public criticism because they threaten to violate the privacy of web users, specifically by leaking potentially sensitive information to third parties such as the Web sites a user has visited 😭 There are also other uses of HTTP State Management that are inappropriate even though they don't threaten user privacy.

So this memo identifies uses of the HTTP State Management protocol specified in RFC-2965 that are not recommended by the IETF, or that are believed to be harmful and are therefore discouraged. 🚫

This document sometimes uses terms written in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of what "MUST", "SHOULD", and "MAY" mean appears in [RFC-1123]. The terms "MUST NOT" and "SHOULD NOT" are logical extensions of that same usage. 📚

2. Uses of HTTP State Management 💖

The whole point of HTTP State Management is to let an HTTP-based service create stateful "sessions" that persist across multiple HTTP transactions. A single session can involve transactions with multiple server hosts. Multiple client hosts can also be part of one session when the session data for a particular user is shared between client hosts (for example, via a networked file system) 🗂️ In other words, the "session" holds state between a "user" and a "service", not between particular hosts. It's giving relationship, not hardware 🫶

It's important to realize that similar capabilities can also be achieved using the "bare" HTTP protocol and/or dynamically-generated HTML, without the State Management extensions 🤓 For example, state information can be sent from the service to the user by embedding a session identifier in one or more URLs that appear in HTTP redirects or dynamically generated HTML. The state information can then come back from the user to the service when those URLs show up in a GET or POST request. HTML forms can also pass state information from the service to the user and back, without the user ever being aware of it 👀

BUT the HTTP State Management facility does give you extra functionality compared to ordinary HTTP and HTML, and it's honestly iconic. In practice, that extra functionality includes:

  1. The ability to exchange URLs between users, for resources accessed during stateful sessions, without leaking the state information associated with those sessions. (e.g. "Here's the URL for the FooCorp web catalog entry for those sandals that you wanted.") 👡
  2. The ability to maintain session state without "cache-busting". Separating the session state from the URL lets a web cache keep only a single copy of the named resource. If the state lived in session-specific URLs, the cache would likely have to keep several identical copies of the resource 🗃️
  3. The ability to implement sessions with minimal server configuration and minimal protocol overhead, compared to other techniques of maintaining session state. ⚡
  4. The ability to associate the user with session state whenever they access the service, no matter whether they enter through a particular "home page" or "portal". 🚪
  5. The ability to save session information in stable storage, so that a "session" can be maintained across client invocations, system reboots, and client or system crashes. 💾

Using HTTP State Management is appropriate whenever it's desirable to maintain state between a user and a service across multiple HTTP transactions, provided that:

  1. the user is aware that session state is being maintained and consents to it,
  2. the user has the ability to delete the state associated with such a session at any time,
  3. the information obtained through the ability to track the user's usage of the service is not disclosed to other parties without the user's explicit consent, and
  4. session information itself cannot contain sensitive information and cannot be used to obtain sensitive information that is not otherwise available to an eavesdropper. 🕵️

This last point is important because cookies are usually sent in the clear, and hence are readily available to eavesdroppers. Not a vibe 💀

An example of a recommended use would be a "shopping cart". The existence of the shopping cart is explicitly made known to the user, and the user can explicitly "empty" their shopping cart (either by requesting that it be emptied or by purchasing those items). That causes the shared state to be discarded. The service also promises that it will not disclose the user's shopping or browsing habits to third parties without the user's consent. Consent-coded and iconic 🛒🌈

Note that HTTP State Management effectively lets a service provider refuse to provide a service, or provide a reduced level of service, if the user or a user's client fails to honor a request to maintain session state. Absent legal prohibition to the contrary, the server MAY refuse to provide the service, or provide a reduced level of service, under these conditions. As a purely practical matter, services designed to use HTTP State Management may be unable to function properly if the client doesn't provide it. Such servers SHOULD gracefully handle these conditions and explain to the user why the full level of service isn't available 🙏

2.2. Problematic Uses 🙅‍♀️

The following uses of HTTP State Management are deemed inappropriate and contrary to this specification:

2.2.1. Leakage of Information to Third Parties 🚨

HTTP State Management MUST NOT be used to leak information about the user or the user's browsing habits to other parties besides the user or service, without the user's explicit consent. This is prohibited even if the user's name or other externally-assigned identifier isn't exposed to other parties, because the state management mechanism itself provides an identifier that can be used to compile information about the user. Not okay, periodt 💅

Because these practices encourage users to defeat HTTP State Management mechanisms, they tend to reduce the effectiveness of HTTP State Management, and are therefore considered detrimental to the operation of the web. 🕸️

2.2.2. Use as an Authentication Mechanism 🔐

It's generally inappropriate to use the HTTP State Management protocol as an authentication mechanism. HTTP State Management isn't designed with that use in mind, and safeguards for protecting authentication credentials are lacking in both the protocol specification and in widely deployed HTTP clients and servers. Most HTTP sessions aren't encrypted, so "cookies" may be exposed to passive eavesdroppers. On top of that, HTTP clients and servers typically store "cookies" in cleartext with little or no protection against exposure 😱 So HTTP State Management SHOULD NOT be used as an authentication mechanism to protect information from being exposed to unauthorized parties, even if the HTTP sessions are encrypted.

The prohibition against using HTTP State Management for authentication covers both its use to protect information provided by the service, and its use to protect potentially sensitive information about the user that has been entrusted to the service's care. For example, it would be inappropriate to expose a user's name, address, telephone number, or billing information to a client that merely presented a cookie that had previously been associated with the user. 🙈

Similarly, HTTP State Management SHOULD NOT be used to authenticate user requests if unauthorized requests might have undesirable side-effects for the user, unless the user is aware of the potential for such side-effects and explicitly consents to that use. For example, a service that let a user order merchandise with a single "click", based entirely on the user's stored "cookies", could inconvenience the user. They'd have to dispute charges to their credit card and/or return the unwanted merchandise, in the event that the cookies were exposed to third parties. Nobody wants that energy 💀💸

Some uses of HTTP State Management to identify users may be relatively harmless. For example, that's the case if the only information that can be exposed belongs to the service, and the service will suffer little harm from its exposure 🌷

3. User Interface Considerations for HTTP State Management 🎀

okay so HTTP State Management has been SUCH a drama queen 😭 because it can expose a user's browsing habits to third parties without the user knowing or agreeing to it. but bestie, this is less a flaw in the protocol itself and more a failure of HTTP client implementations (and some HTTP-based services) to actually protect users' interests 💅

as implied above, there are other ways to keep session state that don't use HTTP State Management, which means other ways browsing habits can get tracked too 👀 honestly it's hard to picture how HTTP or an HTTP client could stop a service from spilling a user's "click trail" to other parties if the service just decided to do it. so protecting that info from inappropriate exposure has to be the service's responsibility 🫶 HTTP client implementations inherently cannot provide that protection, but they CAN use countermeasures that make it harder for HTTP State Management to be the thing that exposes the info ✨

it's arguable that HTTP clients should give more protection in general against inappropriate exposure of tracking info, whether it happened through HTTP State Management or some other way 🧚 but issues with other mechanisms are out of scope for this memo, so we're not going there rn 🙈

3.1. Capabilities Required of an HTTP Client 🌸

a user's willingness to consent to HTTP State Management is likely to vary from one service to another, depending on whether they trust the service to use the info properly and limit who else sees it 💖 so the user SHOULD be able to control whether their client supports a service's request to use HTTP State Management, on a per-service basis. in particular:

  1. Clients MUST NOT respond to HTTP State Management requests unless explicitly enabled by the user. 🚫
  2. Clients SHOULD provide an effective interface which allows users to review, and approve or refuse, any particular requests from a server to maintain state information, before the client provides any state information to the server. 👑
  3. Clients SHOULD provide an effective interface which allows users to instruct their clients to ignore all requests from a particular service to maintain state information, on a per-service basis, immediately in response to any particular request from a server, before the client provides any state information to the server. 🦋
  4. Clients SHOULD provide an effective interface which allows a user to disable future transmission of any state information to a service, and/or discard any saved state information for that service, even though the user has previously approved a service's request to maintain state information. 🍓
  5. Clients SHOULD provide an effective interface which allows a user to terminate a previous request not to retain state management information for a given service. 🌈

3.2. Limitations of the domain-match algorithm 💜

the domain-match algorithm in RFC-2965 section 2 is meant as a heuristic so a client can "guess" whether two domains are part of the same service 🔍 but bestie, there are few rules about how domain names can be used, and the structure and delegation of domain names varies from one top-level domain to another. so the client can't tell which part of the domain was assigned to the service 😭 therefore NO string comparison algorithm (including the domain-match algorithm) can be relied on to tell apart a domain that belongs to a particular service from one that belongs to another party 💀

as stated above, each service is ultimately responsible for making sure user info isn't inappropriately leaked to third parties ✨ leaking info to third parties through State Management by carefully picking domain names, or by assigning domain names to hosts run by third parties, is at least as inappropriate as leaking the same info by other means 🙅‍♀️

4. Security Considerations 🔥

this entire memo is about security considerations 😤🔐 literally the whole thing, no cap 💅

5. Authors' Addresses 🖊️

Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450

EMail: moore@cs.utk.edu

Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 81790

EMail: ned.freed@innosoft.com

6. References 📚

[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.

[RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.

Copyright (C) The Internet Society (2000). All Rights Reserved.

this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️

this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫠

Acknowledgement 🙏

Funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from