idnits 2.17.1 draft-ietf-httpstate-cookie-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 draft header indicates that this document obsoletes RFC2109, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2010) is 5169 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) == Missing Reference: 'USASCII' is mentioned on line 168, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpstate A. Barth 3 Internet-Draft U.C. Berkeley 4 Obsoletes: 2109 (if approved) February 23, 2010 5 Intended status: Standards Track 6 Expires: August 27, 2010 8 HTTP State Management Mechanism 9 draft-ietf-httpstate-cookie-04 11 Abstract 13 This document defines the HTTP Cookie and Set-Cookie headers. These 14 headers can be used by HTTP servers to store state on HTTP user 15 agents, letting the servers maintain a stateful session over the 16 mostly stateless HTTP protocol. The cookie protocol has many 17 historical infelicities and should be avoided for new applications of 18 HTTP. 20 NOTE: If you have suggestions for improving the draft, please send 21 email to http-state@ietf.org. Suggestions with test cases are 22 especially appreciated. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 27, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5 78 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 79 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 9 83 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 86 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 88 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 12 89 5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 14 90 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 14 91 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 16 93 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 16 94 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17 95 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 19 96 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 19 97 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20 98 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20 99 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21 100 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21 101 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21 102 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24 103 6. Implementation Considerations . . . . . . . . . . . . . . . . 26 104 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 6.2. Application Programmer Interfaces . . . . . . . . . . . . 26 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 107 7.1. General Recommendations . . . . . . . . . . . . . . . . . 27 108 7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 27 109 7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 27 110 7.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 28 111 7.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 28 112 7.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 29 113 7.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 30 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 116 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 117 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 1. Introduction 122 This document defines the HTTP Cookie and Set-Cookie header. Using 123 the Set-Cookie header, an HTTP server can store name/value pairs and 124 associated metadata (called cookies) at the user agent. When the 125 user agent makes subsequent requests to the server, the user agent 126 uses the metadata to determine whether to return the name/value pairs 127 in the Cookie header. 129 Although simple on its surface, the cookie protocol has a number of 130 complexities. For example, the server indicates a scope for each 131 cookie when sending them to the user agent. The scope indicates the 132 maximum amount of time the user agent should retain the cookie, to 133 which servers the user agent should return the cookie, and for which 134 protocols the cookie is applicable. 136 For historical reasons, the cookie protocol contains a number of 137 security and privacy infelicities. For example, a server can 138 indicate that a given cookie is intended for "secure" connections, 139 but the Secure attribute provides only confidentiality (not 140 integrity) from active network attackers. Similarly, cookies for a 141 given host are shared across all the ports on that host, even though 142 the usual "same-origin policy" used by web browsers isolates content 143 retrieved from different ports. 145 2. General Nonsense 147 2.1. Conformance Criteria 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 150 "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be 151 interpreted as described in [RFC2119]. 153 Requirements phrased in the imperative as part of algorithms (such as 154 "strip any leading space characters" or "return false and abort these 155 steps") are to be interpreted with the meaning of the key word 156 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 158 2.2. Syntax Notation 160 This specification uses the Augmented Backus-Naur Form (ABNF) 161 notation of [RFC5234]. 163 The following core rules are included by reference, as defined in 164 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 165 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 166 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 167 sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any 168 visible [USASCII] character), and WSP (whitespace). 170 2.3. Terminology 172 The terms user agent, client, server, proxy, and origin server have 173 the same meaning as in the HTTP/1.1 specification ([RFC2616]). 175 The terms request-host and request-URI refer to the values the user 176 agent would send to the server as, respectively, the host (but not 177 port) and abs_path portions of the absoluteURI (http_URL) of the HTTP 178 Request-Line. 180 3. Overview 182 We outline here a way for an origin server to send state information 183 to a user agent, and for the user agent to return the state 184 information to the origin server. 186 To initiate a session, the origin server includes a Set-Cookie header 187 in an HTTP response. (Note that "session" here does not refer to a 188 persistent network connection but to a logical session created from 189 HTTP requests and responses. The presence or absence of a persistent 190 connection should have no effect on the use of cookie-derived 191 sessions). 193 The user agent returns a Cookie request header to the origin server 194 if it chooses to continue a session. The Cookie header contains a 195 number of cookies the user agent received in previous Set-Cookie 196 headers. The origin server MAY ignore the Cookie header or use the 197 header to determine the current state of the session. The origin 198 server MAY send the user agent a Set-Cookie response header with the 199 same or different information, or it MAY send no Set-Cookie header at 200 all. 202 Servers MAY return a Set-Cookie response header with any response. 203 User agents SHOULD send a Cookie request header, subject to other 204 rules detailed below, with every request. 206 An origin server MAY include multiple Set-Cookie header fields in a 207 single response. Note that an intervening gateway MUST NOT fold 208 multiple Set-Cookie header fields into a single header field. 210 3.1. Examples 212 Using the cookie protocol, a server can send the user agent a short 213 string in an HTTP response that the user agent will return in future 214 HTTP requests. For example, the server can send the user agent a 215 "session identifier" named SID with the value 31d4d96e407aad42. The 216 user agent then returns the session identifier in subsequent 217 requests. 219 == Server -> User Agent == 220 Set-Cookie: SID=31d4d96e407aad42 222 == User Agent -> Server == 223 Cookie: SID=31d4d96e407aad42 225 The server can alter the default scope of the cookie using the Path 226 and Domain attributes. For example, the server can instruct the user 227 agent to return the cookie to every path and every subdomain of 228 example.com. 230 == Server -> User Agent == 231 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=.example.com 233 == User Agent -> Server == 234 Cookie: SID=31d4d96e407aad42 236 The server can store multiple cookies in the user agent. For 237 example, the server can store a session identifier as well as the 238 user's preferred language by returning two Set-Cookie response 239 headers. Notice that the server uses the Secure and HttpOnly 240 attributes to provide additional security protections for the more- 241 sensitive session identifier. 243 == Server -> User Agent == 244 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly 245 Set-Cookie: lang=en-US; Path=/; Domain=.example.com 247 == User Agent -> Server == 248 Cookie: SID=31d4d96e407aad42; lang=en-US 250 If the server wishes the user agent to persist the cookie over 251 multiple sessions, the server can specify a expiration date in the 252 Expires attribute. Note that the user agent might might delete the 253 cookie before the expiration date if the user agent's cookie store 254 exceeds its quota or if the user manually deletes the server's 255 cookie. 257 == Server -> User Agent == 258 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 260 == User Agent -> Server == 261 Cookie: lang=en-US 263 Finally, to remove a cookie, the server returns a Set-Cookie header 264 with an expiration date in the past. The server will be successful 265 in removing the cookie only if the Path and the Domain attribute in 266 the Set-Cookie header match the values used when the cookie was 267 created. 269 == Server -> User Agent == 270 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 272 == User Agent -> Server == 273 (No Cookie header) 275 4. A Well-Behaved Profile 277 This section describes the syntax and semantics of a well-behaved 278 profile of the protocol. Servers SHOULD use the profile described in 279 this section, both to maximize interoperability with existing user 280 agents and because a future version of the cookie protocol could 281 remove support for some of the most esoteric aspects of the protocol. 282 User agents, however, MUST implement the full protocol to ensure 283 interoperability with servers making use of the full protocol. 285 4.1. Set-Cookie 287 The Set-Cookie header is used to send cookies from the server to the 288 user agent. 290 4.1.1. Syntax 292 Informally, the Set-Cookie response header comprises the token Set- 293 Cookie:, followed by a cookie. Each cookie begins with a name-value- 294 pair, followed by zero or more attribute-value pairs. Servers SHOULD 295 NOT send Set-Cookie headers that fail to conform to the following 296 grammar: 298 set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS 299 set-cookie-string = cookie-pair *( ";" cookie-av ) 300 cookie-pair = cookie-name "=" cookie-value 301 cookie-name = token 302 cookie-value = token 303 token = 305 cookie-av = expires-av / domain-av / path-av / 306 secure-av / httponly-av 307 expires-av = "Expires" "=" sane-cookie-date 308 sane-cookie-date = 309 domain-av = "Domain" "=" domain-value 310 domain-value = token 311 path-av = "Path" "=" path-value 312 path-value = 313 secure-av = "Secure" 314 httponly-av = "HttpOnly" 316 Servers SHOULD NOT include two attributes with the same name. 318 The cookie-value is opaque to the user agent and MAY be anything the 319 origin server chooses to send. "Opaque" implies that the content is 320 of interest and relevance only to the origin server. The content is, 321 in fact, readable by anyone who examines the Set-Cookie header. 323 To maximize compatibility with user agents, servers that wish to 324 store non-ASCII data in a cookie-value SHOULD encode that data using 325 a printable ASCII encoding, such as base64. 327 NOTE: The syntax above allows whitespace between the attribute and 328 the U+003D ("=") character. Servers wishing to interoperate with 329 some legacy user agents might wish to elide this whitespace. 331 4.1.2. Semantics (Non-Normative) 333 This section describes a simplified semantics of the Set-Cookie 334 header. These semantics are detailed enough to be useful for 335 understanding the most common uses of the cookie protocol. The full 336 semantics are described in Section 5. 338 When the user agent receives a Set-Cookie header, the user agent 339 stores the cookie in its cookie store. When the user agent 340 subsequently makes an HTTP request, the user agent consults its 341 cookie store and includes the applicable, non-expired cookies in the 342 Cookie header. 344 If the cookie store already contains a cookie with the same cookie- 345 name, domain-value, and path-value, the existing cookie is evicted 346 from the cookie store and replaced with the new value. Notice that 347 servers can delete cookies by including an Expires attribute with a 348 value in the past. 350 Unless the cookie's attributes indicate otherwise, the cookie is 351 returned only to the origin server, and it expires at the end of the 352 current session (as defined by the user agent). User agents ignore 353 unrecognized cookie attributes. 355 4.1.2.1. Expires 357 The Expires attribute indicates the maximum lifetime of the cookie, 358 represented as the date and time at which the cookie expires. The 359 user agent is not required to retain the cookie until the specified 360 date has passed. In fact, user agents often evict cookies from the 361 cookie store due to memory pressure or privacy concerns. 363 4.1.2.2. Domain 365 The Domain attribute specifies those hosts for which the cookie will 366 be sent. For example, if the Domain attribute contains the value 367 ".example.com", the user agent will include the cookie in the Cookie 368 header when making HTTP requests to example.com, www.example.com, and 369 www.corp.example.com. (Note that a leading U+002E ("."), if present, 370 is ignored.) If the server omits the Domain attribute, the user 371 agent will return the cookie only to the origin server. 373 WARNING: Some legacy user agents treat an absent Domain attribute 374 as if the Domain attribute were present and contained the current 375 host name. For example, if example.com returns a Set-Cookie 376 header without a Domain attribute, these user agents will send the 377 cookie to www.example.com. 379 The user agent will reject cookies (refuse to store them in the 380 cookie store) unless the Domain attribute specifies a scope for the 381 cookie that would include the origin server. For example, the user 382 agent will accept a Domain attribute of ".example.com" or of 383 ".foo.example.com" from foo.example.com, but the user agent will not 384 accept a Domain attribute of ".bar.example.com" or of 385 ".baz.foo.example.com". 387 NOTE: For security reasons, some user agents are configured to reject 388 Domain attributes that do not correspond to a "registry controlled" 389 domain (or a subdomain of a registry controlled domain). For 390 example, some user agents will reject Domain attributes of ".com". 392 4.1.2.3. Path 394 The Path attribute limits the scope of the cookie to a set of paths. 395 When a cookie has a Path attribute, the user agent will include the 396 cookie in an HTTP request only if the path portion of the Request-URI 397 matches (or is a subdirectory of) the cookie's Path attribute, where 398 the U+002F ("/") character is interpreted as a directory separator. 399 If the server omits the Path attribute, the user agent will use the 400 directory of the Request-URI's path component as the default value. 402 Although seemingly useful for isolating cookies between different 403 paths within a given domain, the Path attribute cannot be relied upon 404 for security for two reasons: First, user agents do not prevent one 405 path from overwriting the cookies for another path. For example, if 406 a response to a request for /foo/bar.html attempts to set a cookie 407 with a Path attribute of "/baz" the user agent will store that cookie 408 in the cookie store. Second, the "same-origin" policy implemented by 409 many user agents does not isolate different paths within an origin. 410 For example, /foo/bar.html can read cookies with a Path attribute of 411 "/baz" because they are within the "same origin". 413 4.1.2.4. Secure 415 The Secure attribute limits the scope of the cookie to "secure" 416 channels (where "secure" is defined by the user agent). When a 417 cookie has the Secure attribute, the user agent will include the 418 cookie in an HTTP request only if the request is transmitted over a 419 secure channel (typically TLS [RFC5246]). 421 Although seemingly useful for protecting cookies from active network 422 attackers, the Secure attribute protects only the cookie's 423 confidentiality. An active network attacker can overwrite Secure 424 cookies from an insecure channel, disrupting the integrity of the 425 cookies. 427 4.1.2.5. HttpOnly 429 The HttpOnly attribute limits the scope of the cookie to HTTP 430 requests. In particular, the attribute instructs the user agent to 431 elide the cookie when providing access to its cookie store via "non- 432 HTTP" APIs (as defined by the user agent). 434 4.2. Cookie 436 4.2.1. Syntax 438 The user agent returns stored cookies to the origin server in the 439 Cookie header. If the server conforms to the requirements in this 440 section, the requirements in the next section will cause the user 441 agent to return a Cookie header that conforms to the following 442 grammar: 444 cookie-header = "Cookie:" OWS cookie-string OWS 445 cookie-string = cookie-pair *( ";" cookie-pair ) 447 4.2.2. Semantics 449 Each cookie-pair represents a cookie stored by the user agent. The 450 cookie-name and the cookie-value are returned verbatim from the 451 corresponding parts of the Set-Cookie header. 453 Notice that the cookie attributes are not returned. In particular, 454 the server cannot determine from the Cookie header alone when a 455 cookie will expire, for which domains the cookie is valid, for which 456 paths the cookie is valid, or whether the cookie was set with the 457 Secure or HttpOnly attributes. 459 The semantics of individual cookies in the Cookie header is not 460 defined by this document. Servers are expected to imbue these 461 cookies with server-specific semantics. 463 Although cookies are serialized linearly in the Cookie header, 464 servers SHOULD NOT rely upon the serialization order. In particular, 465 if the Cookie header contains two cookies with the same name, servers 466 SHOULD NOT rely upon the order in which these cookies appear in the 467 header. 469 5. The Cookie Protocol 471 For historical reasons, the full cookie protocol contains a number of 472 exotic quirks. This section is intended to specify the cookie 473 protocol in enough detail to enable a user agent that implements the 474 protocol precisely as specified to interoperate with existing 475 servers. 477 Conformance requirements phrased as algorithms or specific steps may 478 be implemented in any manner, so long as the end result is 479 equivalent. (In particular, the algorithms defined in this 480 specification are intended to be easy to follow, and not intended to 481 be performant.) 483 5.1. Algorithms 485 This section defines a number of algorithms used by the cookie 486 protocol. 488 5.1.1. Dates 490 The user agent MUST use the following algorithm to *parse a cookie- 491 date*: 493 1. Using the grammar below, divide the cookie-date into date-tokens. 495 cookie-date = *delimiter date-token-list *delimiter 496 date-token-list = date-token *( 1*delimiter date-token ) 497 delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 / 498 %x25 / %x26 / %x27 / %x28 / %x29 / %x2A / 499 %x2B / %x2C / %x2D / %x2E / %x2F / %x3B / 500 %x3C / %x3D / %x3E / %x3F / %x40 / %x5B / 501 %x5C / %x5D / %x5E / %x5F / %x60 / %x7B / 502 %x7C / %x7D / %x7E 503 date-token = day-of-month / month / year / time / mystery 504 day-of-month = 2DIGIT / DIGIT 505 month = "jan" [ mystery ] / "feb" [ mystery ] / 506 "mar" [ mystery ] / "apr" [ mystery ] / 507 "may" [ mystery ] / "jun" [ mystery ] / 508 "jul" [ mystery ] / "aug" [ mystery ] / 509 "sep" [ mystery ] / "oct" [ mystery ] / 510 "nov" [ mystery ] / "dec" [ mystery ] 511 year = 5DIGIT / 4DIGIT / 3DIGIT / 2DIGIT / DIGIT 512 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 513 mystery = 514 2. Process each date-token sequentially in the order the date-tokens 515 appear in the cookie-date: 517 1. If the found-day-of-month flag is not set and the date-token 518 matches the day-of-month production, set the found-day-of- 519 month flag and set the day-of-month-value to the number 520 denoted by the date-token. Skip the remaining sub-steps and 521 continue to the next date-token. 523 2. If the found-month flag is not set and the date-token matches 524 the month production, set the found-month flag and set the 525 month-value to the month denoted by the date-token. Skip the 526 remaining sub-steps and continue to the next date-token. 528 3. If the found-year flag is not set and the date-token matches 529 the year production, set the found-year flag and set the 530 year-value to the number denoted by the date-token. Skip the 531 remaining sub-steps and continue to the next date-token. 533 4. If the found-time flag is not set and the token matches the 534 time production, set the found-time flag and set the hour- 535 value, minute-value, and second-value to the numbers denoted 536 by the digits in the date-token, respectively. Skip the 537 remaining sub-steps and continue to the next date-token. 539 3. Abort these steps and *fail to parse* if 541 * at least one of the found-day-of-month, found-month, found- 542 year, or found-time flags is not set, 544 * the day-of-month-value is less than 1 or greater than 31, 546 * the year-value is less than 1601 or greater than 30827, 548 * the hour-value is greater than 23, 550 * the minute-value is greater than 59, or 552 * the second-value is greater than 59. 554 4. If the year-value is greater than 68 and less than 100, increment 555 the year-value by 1900. 557 5. If the year-value is greater than or equal to 0 and less than 69, 558 increment the year-value by 2000. 560 6. Let the parsed-cookie-date be the date whose day-of-month, month, 561 year, hour, minute, and second (in GMT) are the day-of-month- 562 value, the month-value, the year-value, the hour-value, the 563 minute-value, and the second-value, respectively. 565 7. Return the parsed-cookie-date as the result of this algorithm. 567 5.1.2. Domains 569 A *canonicalized* host-name is the host-name converted to lower case. 571 A request-host *domain-matches* a cookie-domain if at least one of 572 the following conditions hold: 574 o The cookie-domain and the canonicalized request-host are 575 identical. 577 o The cookie-domain is a suffix of the canonicalized request-host, 578 the last character of the canonicalized request-host that is not 579 included in the cookie-domain is a U+002E (".") character, and 580 request-host is a host name (i.e., not an IP address). [TODO: Is 581 this the right way to spec this???] 583 5.1.3. Paths 585 The user agent MUST use the following algorithm to compute the 586 *default-path* of a cookie: 588 1. Let uri-path be the path portion of the Request-URI. 590 2. If the first character of the uri-path is not a U+002F ("/") 591 character, output U+002F ("/") and skip the remaining steps. 593 3. If the uri-path contains only a single U+002F ("/") character, 594 output U+002F ("/") and skip the remaining steps. 596 4. Output the characters of the uri-path from the first character up 597 to, but not including, the right-most U+002F ("/"). 599 A request-path *path-matches* a cookie-path if at least one of the 600 following conditions hold: [TODO: This isn't exactly what IE or 601 Firefox does.] 603 o The cookie-path and the request-path are identical. 605 o The cookie-path is a prefix of the request-path and the last 606 character of the cookie-path is U+002F ("/"). 608 o The cookie-path is a prefix of the request-path and the first 609 character of the request-path that is not included in the cookie- 610 path is a U+002F ("/") character. 612 5.2. The Set-Cookie Header 614 When a user agent receives a Set-Cookie header in an HTTP response, 615 the user agent *receives a set-cookie-string* consisting of the value 616 of the header. 618 A user agent MUST use the following algorithm to parse set-cookie- 619 strings: 621 1. If the set-cookie-string is empty or consists entirely of WSP 622 characters, the user agent MAY ignore the set-cookie-string 623 entirely. 625 2. If the set-cookie-string contains a U+003B (";") character: 627 The name-value-pair string consists of the characters up to, 628 but not including, the first U+003B (";"), and the unparsed- 629 attributes consist of the remainder of the set-cookie-string 630 (including the U+003B (";") in question). 632 Otherwise: 634 The name-value-pair string consists of all the characters 635 contained in the set-cookie-string, and the unparsed- 636 attributes is the empty string. 638 3. If the name-value-pair string contains a U+003D ("=") character: 640 The (possibly empty) name string consists of the characters up 641 to, but not including, the first U+003D ("=") character, and 642 the (possibly empty) value string consists of the characters 643 after the first U+003D ("=") character. 645 Otherwise: 647 The name string is empty, and the value string consists of the 648 entire name-value-pair string. 650 4. Remove any leading or trailing WSP characters from the name 651 string and the value string. 653 5. The cookie-name is the name string, and the cookie-value is the 654 value string. 656 The user agent MUST use the following algorithm to parse the 657 unparsed-attributes: 659 1. If the unparsed-attributes string is empty, skip the rest of 660 these steps. 662 2. Consume the first character of the unparsed-attributes (which 663 will be a U+003B (";") character). 665 3. If the remaining unparsed-attributes contains a U+003B (";") 666 character: 668 Consume the characters of the unparsed-attributes up to, but 669 not including, the first U+003B (";") character. 671 Otherwise: 673 Consume the remainder of the unparsed-attributes. 675 Let the cookie-av string be the characters consumed in this step. 677 4. If the cookie-av string contains a U+003D ("=") character: 679 The (possibly empty) attribute-name string consists of the 680 characters up to, but not including, the first U+003D ("=") 681 character, and the (possibly empty) attribute-value string 682 consists of the characters after the first U+003D ("=") 683 character. 685 Otherwise: 687 The attribute-name string consists of the entire cookie-av 688 string, and the attribute-value string is empty. (Note that 689 this step differs from the analogous step when parsing the 690 name-value-pair string.) 692 5. Remove any leading or trailing WSP characters from the attribute- 693 name string and the attribute-value string. 695 6. Process the attribute-name and attribute-value according to the 696 requirements in the following subsections. 698 7. Return to Step 1. 700 When the user agent finishes parsing the set-cookie-string, the user 701 agent *receives a cookie* from the Request-URI with name cookie-name, 702 value cookie-value, and attributes cookie-attribute-list. 704 5.2.1. The Max-Age Attribute 706 If the attribute-name case-insensitively matches the string "Max- 707 Age", the user agent MUST process the cookie-av as follows. 709 If the first character of the attribute-value is not a DIGIT or a "-" 710 character, ignore the cookie-av. 712 If the remainder of attribute-value contains a non-DIGIT character, 713 ignore the cookie-av. 715 Let delta-seconds be the attribute-value converted to an integer. 717 If delta-seconds is less than or equal to zero (0), let expiry-time 718 be the current date and time. Otherwise, let the expiry-time be the 719 current date and time plus delta-seconds seconds. 721 Append an attribute to the cookie-attribute-list with an attribute- 722 name of Expires (note the name conversion) and an attribute-value of 723 expiry-time. 725 5.2.2. The Expires Attribute 727 If the attribute-name case-insensitively matches the string 728 "Expires", the user agent MUST process the cookie-av as follows. 730 Let the parsed-cookie-date be the result of parsing the attribute- 731 value as cookie-date. 733 If the attribute-value failed to parse as a cookie date, ignore the 734 cookie-av. 736 If the user agent received the set-cookie-string from an HTTP 737 response that contains a Date header field and the contents of the 738 last Date header field successfully parse as a cookie-date: 740 Let server-date be the date obtained by parsing the contents of 741 the last Date header field as a cookie-date. 743 Let delta-seconds be the number of seconds between the server-date 744 and the parsed-cookie-date (i.e., parsed-cookie-date - server- 745 date). 747 Let the expiry-time be the current date and time plus delta- 748 seconds seconds. 750 Otherwise: 752 Let the expiry-time be the parsed-cookie-date. 754 If the expiry-time is later than the last date the user agent can 755 represent, the user agent MAY replace the expiry-time with the last 756 representable date. 758 If the expiry-time is earlier than the first date the user agent can 759 represent, the user agent MAY replace the expiry-time with the first 760 representable date. 762 Append an attribute to the cookie-attribute-list with an attribute- 763 name of Expires and an attribute-value of expiry-time. 765 5.2.3. The Domain Attribute 767 If the attribute-name case-insensitively matches the string "Domain", 768 the user agent MUST process the cookie-av as follows. 770 If the attribute-value is empty, the behavior is undefined. However, 771 user agent SHOULD ignore the cookie-av entirely. 773 If the first character of the attribute-value string is U+002E ("."): 775 Let cookie-domain be the attribute-value without the leading 776 U+002E (".") character. 778 Otherwise: 780 Let cookie-domain be the entire attribute-value. 782 Convert the cookie-domain to lower case. 784 [TODO: Test ".127.0.0.1" and "127.0.0.1"] 786 Append an attribute to the cookie-attribute-list with an attribute- 787 name of Domain and an attribute-value of cookie-domain. 789 5.2.4. The Path Attribute 791 If the attribute-name case-insensitively matches the string "Path", 792 the user agent MUST process the cookie-av as follows. 794 If the attribute-value is empty or if the first character of the 795 attribute-value is not U+002F ("/"): 797 Let cookie-path be the default-path. [TODO: We need more tests 798 for this, including with " characters and with multiple Path 799 attributes.] 801 Otherwise: 803 Let cookie-path be the attribute-value. 805 Append an attribute to the cookie-attribute-list with an attribute- 806 name of Path and an attribute-value of cookie-path. 808 5.2.5. The Secure Attribute 810 If the attribute-name case-insensitively matches the string "Secure", 811 the user agent MUST append an attribute to the cookie-attribute-list 812 with an attribute-name of Secure and an empty attribute-value. 814 5.2.6. The HttpOnly Attribute 816 If the attribute-name case-insensitively matches the string 817 "HttpOnly", the user agent MUST append an attribute to the cookie- 818 attribute-list with an attribute-name of HttpOnly and an empty 819 attribute-value. 821 5.3. Storage Model 823 When the user agent receives a cookie, the user agent SHOULD record 824 the cookie in its cookie store as follows. 826 A user agent MAY ignore a received cookie in its entirety if the user 827 agent is configured to block receiving cookies. For example, the 828 user agent might wish to block receiving cookies from "third-party" 829 responses. 831 The user agent stores the following fields about each cookie: name, 832 value, expiry-time, domain, path, creation-time, last-access-time, 833 persistent-flag, host-only-flag, secure-only-flag, and http-only- 834 flag. 836 When the user agent receives a cookie from a Request-URI with name 837 cookie-name, value cookie-value, and attributes cookie-attribute- 838 list, the user agent MUST process the cookie as follows: 840 1. Create a new cookie with name cookie-name, value cookie-value. 841 Set the creation-time and the last-access-time to the current 842 date and time. 844 2. If the cookie-attribute-list contains an attribute with an 845 attribute-name of "Expires": 847 Set the cookie's persistent-flag to true. 849 Set the cookie's expiry-time to attribute-value of the last 850 attribute in the cookie-attribute-list with an attribute-name 851 of "Expires". [TODO: Test that this really works when mixing 852 Max-Age and Expires.] 854 Otherwise: 856 Set the cookie's persistent-flag to false. 858 Set the cookie's expiry-time to the latest representable 859 date. 861 3. If the cookie-attribute-list contains an attribute with an 862 attribute-name of "Domain": 864 Let the domain-attribute be the attribute-value of the last 865 attribute in the cookie-attribute-list with an attribute-name 866 of "Domain". 868 Otherwise: 870 Let the domain-attribute be the empty string. 872 4. If the user agent is configured to use a "public suffix" list 873 and the domain-attribute is a public suffix: 875 If the domain-attribute is identical to the canonicalized 876 Request-URI's host: 878 Let the domain-attribute be the empty string. 880 Otherwise: 882 Ignore the cookie entirely and abort these steps 884 NOTE: A "public suffix" is a domain that is controlled by a 885 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 886 This step is essential for preventing attacker.com from 887 disrupting the integrity of example.com by setting a cookie 888 with a Domain attribute of "com". Unfortunately, the set of 889 public suffixes (also known as "registry controlled domains") 890 changes over time. If feasible, user agents SHOULD use an 891 up-to-date public suffix list, such as the one maintained by 892 the Mozilla project at http://publicsuffix.org/. 894 5. If the domain-attribute is non-empty: 896 If the Request-URI's host does not domain-match the domain- 897 attribute, ignore the cookie entirely and abort these steps. 899 Set the cookie's host-only-flag to false. 901 Set the cookie's domain to the domain-attribute. 903 Otherwise: 905 Set the cookie's host-only-flag to true. 907 Set the cookie's domain to the host of the Request-URI. 909 6. If the cookie-attribute-list contains an attribute with an 910 attribute-name of "Path", set the cookie's path to attribute- 911 value of the last attribute in the cookie-attribute-list with an 912 attribute-name of "Path". Otherwise, set cookie's path to the 913 default-path of the Request-URI. 915 7. If the cookie-attribute-list contains an attribute with an 916 attribute-name of "Secure", set the cookie's secure-only-flag to 917 true. Otherwise, set cookie's secure-only-flag to false. 919 8. If the cookie-attribute-list contains an attribute with an 920 attribute-name of "HttpOnly", set the cookie's http-only-flag to 921 true. Otherwise, set cookie's http-only-flag to false. 923 9. Remove from the cookie store all cookies that share the same 924 name, domain, path, and host-only-flag as the newly created 925 cookie. [TODO: Validate this list!] [TODO: There's some funny 926 business around http-only here.] 928 10. If the cookie's name and value are both empty, abort these 929 steps. 931 11. If the cookie's expiry-time is not in the future, abort these 932 steps. 934 12. Insert the newly created cookie into the cookie store. 936 The user agent MUST evict a cookie from the cookie store if, at any 937 time, a cookie exists in the cookie store with an expiry date in the 938 past. 940 The user agent MAY evict a cookie from the cookie store if the number 941 of cookies sharing a domain field exceeds some predetermined upper 942 bound (such as 50 cookies). 944 The user agent MAY evict a cookie from the cookie store if the cookie 945 store exceeds some predetermined upper bound (such as 3000 cookies). 947 When the user agent evicts a cookie from the cookie store, the user 948 agent MUST evict cookies in the following priority order: 950 1. Cookies with an expiry date in the past. 952 2. Cookies that share a domain field with more than a predetermined 953 number of other cookies. 955 3. All cookies. 957 If two cookies have the same removal priority, the user agent MUST 958 evict the cookie with the least recent last-access date first. 960 When "the current session is over" (as defined by the user agent), 961 the user agent MUST remove from the cookie store all cookies with the 962 persistent-flag set to false. 964 5.4. The Cookie Header 966 When the user agent generates an HTTP request, the user agent SHOULD 967 attach exactly one HTTP header named Cookie if the cookie-string 968 (defined below) for the Request-URI is non-empty. 970 A user agent MAY elide the Cookie header in its entirety if the user 971 agent is configured to block sending cookies. For example, the user 972 agent might wish to block sending cookies during "third-party" 973 requests. 975 The user agent MUST use the following algorithm to compute the 976 cookie-string from a cookie store and a Request-URI: 978 1. Let cookie-list be the set of cookies from the cookie store that 979 meet all of the following requirements: 981 * Let request-host be the Request-URI's host. Either: 983 The cookie's host-only-flag is true and the canonicalized 984 request-host is identical to the cookie's domain. 986 Or: 988 The cookie's host-only-flag is false and the request-host 989 domain-matches cookie's domain. 991 * The Request-URI's path patch-matches cookie's path. 993 * If the cookie's secure-only field is true, then the Request- 994 URI's scheme must denote a "secure" protocol (as defined by 995 the user agent). 997 NOTE: The notion of a "secure" protocol is not defined by 998 this document. Typically, user agents consider a protocol 999 secure if the protocol makes use of transport-layer 1000 security, such as TLS. For example, most user agents 1001 consider "https" to be a scheme that denotes a secure 1002 protocol. 1004 * If the cookie's http-only field is true, then exclude the 1005 cookie unless the cookie-string is being generated for an 1006 "HTTP" API (as defined by the user agent). 1008 2. Sort the cookie-list in the following order: 1010 * Cookies with longer paths are listed before cookies with 1011 shorter paths. 1013 * Among cookies that have equal length path fields, cookies with 1014 earlier creation-times are listed before cookies with later 1015 creation-times. 1017 3. Update the last-access-time of each cookie in the cookie-list to 1018 the current date and time. 1020 4. Serialize the cookie-list into a cookie-string by processing each 1021 cookie in the cookie-list in order: 1023 1. If the cookie's name is non-empty, output the cookie's name 1024 followed by the U+003D ("=") character. 1026 2. Output the cookie's value. 1028 3. If there is an unprocessed cookie in the cookie-list, output 1029 the characters U+003B and U+0020 ("; "). 1031 6. Implementation Considerations 1033 6.1. Limits 1035 Practical user agent implementations have limits on the number and 1036 size of cookies that they can store. General-use user agents SHOULD 1037 provide each of the following minimum capabilities: 1039 o At least 4096 bytes per cookie (as measured by the sum of the 1040 length of the cookie's name, value, and attributes). 1042 o At least 50 cookies per domain. 1044 o At least 3000 cookies total. 1046 Servers SHOULD use as few and as small cookies as possible to avoid 1047 reaching these implementation limits and to avoid network latency due 1048 to the Cookie header being included in every request. 1050 Servers should gracefully degrade if the user agent fails to return 1051 one or more cookies in the Cookie header because the user agent might 1052 evict any cookie at any time on orders from the user. 1054 6.2. Application Programmer Interfaces 1056 One reason the cookie protocol uses such an esoteric syntax is 1057 because many platforms (both in servers and user agents) provide 1058 string-based application programmer interfaces (APIs), requiring 1059 application-layer programmers to generate and parse the syntax used 1060 by the cookie protocol. 1062 Instead of providing string-based APIs to the cookie protocols, 1063 implementations would be well-served by providing more semantic APIs. 1064 It is beyond the scope of this document to recommend specific API 1065 designs, but there are clear benefits to accepting a abstract "Date" 1066 object instead of a serialized date string. 1068 7. Security Considerations 1070 7.1. General Recommendations 1072 The cookie protocol is NOT RECOMMENDED for new applications. 1074 For applications that do use the cookie protocol, servers SHOULD NOT 1075 rely upon cookies for security. 1077 7.2. Ambient Authority 1079 A server that uses cookies to authenticate users can suffer security 1080 vulnerabilities because some user agents let remote parties issue 1081 HTTP requests from the user agent (e.g., via HTTP redirects and HTML 1082 forms). When issuing those requests, user agent attaches cookies 1083 even if the entity does not know the contents of the cookies, 1084 possibly letting the remote entity exercise authority at an unwary 1085 server. 1087 Although this security concern goes by a number of names (e.g., 1088 cross-site request forgery, confused deputy), the issue stems from 1089 cookies being a form of ambient authority. Cookies encourage server 1090 operators to separate designation (in the form of URLs) from 1091 authorization (in the form of cookies). Consequently, the user agent 1092 might supply the authorization for a resource designated by the 1093 attacker, possibly causing the server or its clients to undertake 1094 actions designated by the attacker as though they were authorized by 1095 the user. 1097 Instead of using cookies for authorization, server operators might 1098 wish to consider entangling designation and authorization by treating 1099 URLs as capabilities. Instead of storing secrets in cookies, this 1100 approach stores secrets in URLs, requiring the remote entity to 1101 supply the secret itself. Although this approach is not a panacea, 1102 judicious use of these principles can lead to more robust security. 1104 7.3. Clear Text 1106 Unless sent over a secure channel (such as TLS), the information in 1107 the Set-Cookie and Cookie headers is transmitted in the clear. 1109 1. All sensitive information conveyed in these headers is exposed to 1110 an eavesdropper. 1112 2. A malicious intermediary could alter the headers as they travel 1113 in either direction, with unpredictable results. 1115 3. A malicious client could alter the Cookie header before 1116 transmission, with unpredictable results. 1118 Servers SHOULD encrypt and sign the contents of cookies when 1119 transmitting them to the user agent (even when sending the cookies 1120 over a secure channel). However, encrypting and signing cookie 1121 contents does not prevent an attacker from transplanting a cookie 1122 from one user agent to another or from replaying the cookie at a 1123 later time. 1125 In addition to encrypting and signing the contents of every cookie, 1126 servers that require a higher level of security SHOULD use the cookie 1127 protocol only over a secure channel. When using the cookie protocol 1128 over a secure channel, servers SHOULD set the Secure attribute in 1129 every cookie. If a server does not set the Secure attribute, the 1130 protection provided by the secure channel will be largely moot. 1132 7.4. Session Identifiers 1134 Instead of storing session information directly in a cookie (where it 1135 might be exposed to or replayed by an attacker), servers commonly 1136 store a nonce (or "session identifier") in a cookie. When the server 1137 receives an HTTP request with a nonce, the server can look up state 1138 information associated with the cookie using the nonce as a key. 1140 Using session identifier cookies limits the damage an attacker can 1141 cause if the attacker learns the contents of a cookie because the 1142 nonce is useful only for interacting with the server (unlike non- 1143 nonce cookie content, which might itself be sensitive). Furthermore, 1144 using a single nonce prevents an attacker from "splicing" together 1145 cookie content from two interactions with the server, which could 1146 cause the server to behave unexpectedly. 1148 Using session identifiers is not without risk. For example, the 1149 server SHOULD take care to avoid "session fixation" vulnerabilities. 1150 A session fixation attack proceeds in three steps. First, the 1151 attacker transplants a session identifier from his or her user agent 1152 to the victim's user agent. Second, the victim uses that session 1153 identifier to interact with the server, possibly imbuing the session 1154 identifier with the user's credentials or confidential information. 1155 Third, the attacker uses the session identifier to interact with 1156 server directly, possibly obtaining the user's authority or 1157 confidential information. 1159 7.5. Weak Confidentiality 1161 Cookies do not provide isolation by port. If a cookie is readable by 1162 a service running on one port, the cookie is also readable by a 1163 service running on another port of the same server. If a cookie is 1164 writable by a service on one port, the cookie is also writable by a 1165 service running on another port of the same server. For this reason, 1166 servers SHOULD NOT both run mutually distrusting services on 1167 different ports of the same host and use cookies to store security- 1168 sensitive information. 1170 Cookies do not provide isolation by scheme. Although most commonly 1171 used with the http and https schemes, the cookies for a given host 1172 might also available to other schemes, such as ftp and gopher. 1173 Although this lack of isolation by scheme is most apparent in via 1174 non-HTTP APIs that permit access to cookies (e.g., HTML's 1175 document.cookie API), the lack of isolation by scheme is actually 1176 present in the cookie protocol itself (e.g., consider retrieving a 1177 URI with the gopher scheme via HTTP). 1179 Cookies do not always provide isolation by path. Although the 1180 network-level protocol does not send cookie stored for one path to 1181 another, some user agents expose cookies via non-HTTP APIs, such as 1182 HTML's document.cookie API. Because some of these user agents (e.g., 1183 web browsers) do not isolate resources received from different paths, 1184 a resource retrieved from one path might be able to access cookies 1185 stored for another path. 1187 7.6. Weak Integrity 1189 Cookies do not provide integrity guarantees for sibling domains (and 1190 their subdomains). For example, consider foo.example.com and 1191 bar.example.com. The foo.example.com server can set a cookie with a 1192 Domain attribute of ".example.com" (possibly overwriting an existing 1193 ".example.com" cookie set by bar.example.com), and the user agent 1194 will include that cookie in HTTP requests to bar.example.com. In the 1195 worst case, bar.example.com will be unable to distinguish this cookie 1196 from a cookie it set itself. The foo.example.com server might be 1197 able to leverage this ability to mount an attack against 1198 bar.example.com. 1200 Even though the cookie protocol supports the Path attribute, the Path 1201 attribute does not provide any integrity protection because the user 1202 agent with accept an arbitrary Path attribute in a Set-Cookie header. 1203 For example, an HTTP response to a request for 1204 http://example.com/foo/bar can set a cookie with a Path attribute of 1205 "/qux". Consequently, servers SHOULD NOT both run mutually 1206 distrusting services on different paths of the same host and use 1207 cookies store security sensitive information. 1209 An active network attacker can also inject cookies into the Cookie 1210 header sent to https://example.com/ by impersonating a response from 1211 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1212 server at example.com will be unable to distinguish these cookies 1213 from cookies that it set itself in an HTTPS response. An active 1214 network attacker might be able to leverage this ability to mount an 1215 attack against example.com even if example.com uses HTTPS 1216 exclusively. 1218 Servers can partially mitigate these attacks by encrypting and 1219 signing the contents of their cookies. However, using cryptography 1220 does not mitigate the issue completely because an attacker can replay 1221 a cookie he or she received from the authentic example.com server in 1222 the user's session, with unpredictable results. 1224 Finally, an attacker might be able to force the user agent to delete 1225 cookies by storing large number of cookies. Once the user agent 1226 reaches its storage limit, the user agent will be forced to evict 1227 some cookies. Servers SHOULD NOT rely upon user agents retaining 1228 cookies. 1230 7.7. Reliance on DNS 1232 The cookie protocol relies upon the Domain Name System (DNS) for 1233 security. If the DNS is partially or fully compromised, the cookie 1234 protocol might fail to provide the security properties required by 1235 applications. 1237 8. References 1239 8.1. Normative References 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, March 1997. 1244 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1245 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1246 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1248 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1249 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1251 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1252 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1254 8.2. Informative References 1256 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1257 Mechanism", RFC 2109, February 1997. 1259 Appendix A. Acknowledgements 1261 This document borrows heavily from RFC 2109 [RFC2109]. [TODO: Figure 1262 out the proper way to credit the authors of RFC 2109.] 1264 Author's Address 1266 Adam Barth 1267 University of California, Berkeley 1269 Email: abarth@eecs.berkeley.edu 1270 URI: http://www.adambarth.com/