idnits 2.17.1 draft-ietf-httpbis-replay-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2018) is 2123 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) -- Looks like a reference, but probably isn't: '1' on line 521 -- Looks like a reference, but probably isn't: '2' on line 523 -- Looks like a reference, but probably isn't: '3' on line 525 -- Looks like a reference, but probably isn't: '4' on line 527 -- Looks like a reference, but probably isn't: '5' on line 529 ** Obsolete normative reference: RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-22 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-08 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track M. Nottingham 5 Expires: December 29, 2018 Fastly 6 W. Tarreau 7 HAProxy Technologies 8 June 27, 2018 10 Using Early Data in HTTP 11 draft-ietf-httpbis-replay-04 13 Abstract 15 Using TLS early data creates an exposure to the possibility of a 16 replay attack. This document defines mechanisms that allow clients 17 to communicate with servers about HTTP requests that are sent in 18 early data. Techniques are described that use these mechanisms to 19 mitigate the risk of replay. 21 Note to Readers 23 RFC Editor: Please remove this section before publication. 25 Discussion of this draft takes place on the HTTP working group 26 mailing list (ietf-http-wg@w3.org), which is archived at 27 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 29 Working Group information can be found at http://httpwg.github.io/ 30 [2]; source code and issues list for this draft can be found at 31 https://github.com/httpwg/http-extensions/labels/replay [3]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 29, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 69 2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3 70 3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3 71 4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5 72 5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6 73 5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 7 74 5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 9 77 6.2. Consistent Handling of Early Data . . . . . . . . . . . . 9 78 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 79 6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 8.2. Informative References . . . . . . . . . . . . . . . . . 11 84 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 TLS 1.3 [TLS13] introduces the concept of early data (also known as 91 zero round trip data or 0-RTT data). Early data allows a client to 92 send data to a server in the first round trip of a connection, 93 without waiting for the TLS handshake to complete, if the client has 94 spoken to the same server recently. 96 When used with HTTP [HTTP], early data allows clients to send 97 requests immediately, avoiding the one or two round trip delay needed 98 for the TLS handshake. This is a significant performance 99 enhancement; however, it has significant limitations. 101 The primary risk of using early data is that an attacker might 102 capture and replay the request(s) it contains. TLS [TLS13] describes 103 techniques that can be used to reduce the likelihood that an attacker 104 can successfully replay a request, but these techniques can be 105 difficult to deploy, and still leave some possibility of a successful 106 attack. 108 Note that this is different from automated or user-initiated retries; 109 replays are initiated by an attacker without the awareness of the 110 client. 112 To help mitigate the risk of replays in HTTP, this document gives an 113 overview of techniques for controlling these risks in servers, and 114 defines requirements for clients when sending requests in early data. 116 The advice in this document also applies to use of 0-RTT in HTTP over 117 QUIC [HQ]. 119 1.1. Conventions and Definitions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Early Data in HTTP 129 Conceptually, early data is concatenated with other application data 130 to form a single stream. This can mean that requests are entirely 131 contained within early data, or only part of a request is early. In 132 a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], 133 multiple requests might be partially delivered in early data. 135 The model that this document assumes is that once the TLS handshake 136 completes, the early data received on that TLS connection is known to 137 not be a replayed copy of that data. However, it is important to 138 note that this does not mean that early data will not be or has not 139 been replayed on another connection. 141 3. Supporting Early Data in HTTP Servers 143 A server decides whether or not to offer a client the ability to send 144 early data on future connections when sending the TLS session ticket. 146 TLS [TLS13] mandates the use of replay detection strategies that 147 reduce the ability of an attacker to successfully replay early data. 148 These anti-replay techniques reduce but don't completely eliminate 149 the chance of data being replayed and ensure a fixed upper limit to 150 the number of replays. 152 When a server enables early data, there are a number of techniques it 153 can use to mitigate the risks of replay: 155 1. The server can reject early data at the TLS layer. A server 156 cannot selectively reject early data, so this results in all 157 requests sent in early data being discarded. 159 2. The server can choose to delay processing of early data until 160 after the TLS handshake completes. By deferring processing, it 161 can ensure that only a successfully completed connection is used 162 for the request(s) therein. This provides the server with some 163 assurance that the early data was not replayed. If the server 164 receives multiple requests in early data, it can determine 165 whether to defer HTTP processing on a per-request basis. 167 3. The server can cause a client to retry individual requests and 168 not use early data by responding with the 425 (Too Early) status 169 code (Section 5.2), in cases where the risk of replay is judged 170 too great. 172 Any of these techniques is equally effective and a server can use the 173 method that best suits it. 175 For a given request, the level of tolerance to replay risk is 176 specific to the resource it operates upon (and therefore only known 177 to the origin server). The primary risk associated with using early 178 data is in the actions a server takes when processing a request; 179 processing a duplicated request might result in duplicated effects 180 and side effects. Appendix E.5 of [TLS13] also describes other 181 effects produced by processing duplicated requests. 183 The request method's safety ([RFC7231], Section 4.2.1) is one way to 184 determine this. However, some resources do produce side effects with 185 safe methods, so this cannot be universally relied upon. 187 It is RECOMMENDED that origin servers allow resources to explicitly 188 configure whether early data is appropriate in requests. Absent such 189 explicit information, origin servers MUST either reject early data or 190 implement the techniques described in this document for ensuring that 191 requests are not processed prior to TLS handshake completion. 193 A request might be sent partially in early data with the remainder of 194 the request being sent after the handshake completes. This does not 195 necessarily affect handling of that request; what matters is when the 196 server starts acting upon the contents of a request. Any time any 197 server instance might initiate processing prior to completion of the 198 handshake, all server instances need to account for the possibility 199 of replay of early data and how that could affect that processing 200 (see also Section 6.2). 202 A server can partially process requests that are incomplete. Parsing 203 header fields - without acting on the values - and determining 204 request routing is likely to be safe from side-effects, but other 205 actions might not be. 207 Intermediary servers do not have sufficient information to decide 208 whether early data can be processed, so Section 5.2 describes a way 209 for the origin to signal to them that a particular request isn't 210 appropriate for early data. Intermediaries that accept early data 211 MUST implement that mechanism. 213 Note that a server cannot choose to selectively reject early data at 214 the TLS layer. TLS only permits a server to accept all early data, 215 or none of it. Once a server has decided to accept early data, it 216 MUST process all requests in early data, even if the server rejects 217 the request by sending a 425 (Too Early) response. 219 A server can limit the amount of early data with the 220 "max_early_data_size" field of the "early_data" TLS extension. This 221 can be used to avoid committing an arbitrary amount of memory for 222 requests that it might defer until the handshake completes. 224 4. Using Early Data in HTTP Clients 226 A client that wishes to use early data commences sending HTTP 227 requests immediately after sending the TLS ClientHello. 229 By their nature, clients have control over whether a given request is 230 sent in early data - thereby giving the client control over risk of 231 replay. Absent other information, clients MAY send requests with 232 safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when 233 it is available, and MUST NOT send unsafe methods (or methods whose 234 safety is not known) in early data. 236 If the server rejects early data at the TLS layer, a client MUST 237 start sending again as though the connection were new. This could 238 entail using a different negotiated protocol [ALPN] than the one 239 optimistically used for the early data. Any requests sent in early 240 data will need to be sent again, unless the client decides to abandon 241 those requests. 243 Automatic retry creates the potential for a replay attack. An 244 attacker intercepts a connection that uses early data and copies the 245 early data to another server instance. The second server instance 246 accepts and processes the early data, even though it will not 247 complete the TLS handshake. The attacker then allows the original 248 connection to complete. Even if the early data is detected as a 249 duplicate and rejected, the first server instance might allow the 250 connection to complete. If the client then retries requests that 251 were sent in early data, the request will be processed twice. 253 Replays are also possible if there are multiple server instances that 254 will accept early data, or if the same server accepts early data 255 multiple times (though the latter would be in violation of 256 requirements in Section 8 of [TLS13]). 258 Clients that use early data MUST retry requests upon receipt of a 425 259 (Too Early) status code; see Section 5.2. 261 An intermediary MUST NOT use early data when forwarding a request 262 unless early data was used on a previous hop, or it knows that the 263 request can be retried safely without consequences (typically, using 264 out-of-band configuration). Absent better information, that means 265 that an intermediary can only use early data if the request either 266 arrived in early data or arrived with the "Early-Data" header field 267 set to "1" (see Section 5.1). 269 5. Extensions for Early Data in HTTP 271 Because HTTP requests can span multiple "hops", it is necessary to 272 explicitly communicate whether a request has been sent in early data 273 on a previous hop. Likewise, some means of explicitly triggering a 274 retry when early data is not desirable is necessary. Finally, it is 275 necessary to know whether the client will actually perform such a 276 retry. 278 To meet these needs, two signalling mechanisms are defined: 280 o The "Early-Data" header field is included in requests that might 281 have been forwarded by an intermediary prior to the TLS handshake 282 with its client completing. 284 o The 425 (Too Early) status code is defined for a server to 285 indicate that a request could not be processed due to the 286 consequences of a possible replay attack. 288 They are designed to enable better coordination of the use of early 289 data between the user agent and origin server, and also when a 290 gateway (also "reverse proxy", "Content Delivery Network", or 291 "surrogate") is present. 293 Gateways typically don't have specific information about whether a 294 given request can be processed safely when it is sent in early data. 295 In many cases, only the origin server has the necessary information 296 to decide whether the risk of replay is acceptable. These extensions 297 allow coordination between a gateway and its origin server. 299 5.1. The Early-Data Header Field 301 The "Early-Data" request header field indicates that the request has 302 been conveyed in early data, and additionally indicates that a client 303 understands the 425 (Too Early) status code. 305 It has just one valid value: "1". Its syntax is defined by the 306 following ABNF [ABNF]: 308 Early-Data = "1" 310 For example: 312 GET /resource HTTP/1.0 313 Host: example.com 314 Early-Data: 1 316 An intermediary that forwards a request prior to the completion of 317 the TLS handshake with its client MUST send it with the "Early-Data" 318 header field set to "1" (i.e., it adds it if not present in the 319 request). An intermediary MUST use the "Early-Data" header field if 320 it - or another instance (see Section 6.2) - could have forwarded the 321 request prior to handshake completion if circumstances were 322 different. 324 An intermediary MUST NOT remove this header field if it is present in 325 a request. "Early-Data" MUST NOT appear in a "Connection" header 326 field. 328 The "Early-Data" header field is not intended for use by user agents 329 (that is, the original initiator of a request). Sending a request in 330 early data implies that the client understands this specification and 331 is willing to retry a request in response to a 425 (Too Early) status 332 code. A user agent that sends a request in early data does not need 333 to include the "Early-Data" header field. 335 A server cannot make a request that contains the Early-Data header 336 field safe for processing by waiting for the handshake to complete. 337 A request that is marked with Early-Data was sent in early data on a 338 previous hop. Requests that contain the Early-Data field and cannot 339 be safely processed MUST be rejected using the 425 (Too Early) status 340 code. 342 The "Early-Data" header field carries a single bit of information and 343 clients MUST include at most one instance. Multiple or invalid 344 instances of the header field MUST be treated as equivalent to a 345 single instance with a value of 1 by a server. 347 A "Early-Data" header field MUST NOT be included in responses or 348 request trailers. 350 5.2. The 425 (Too Early) Status Code 352 A 425 (Too Early) status code indicates that the server is unwilling 353 to risk processing a request that might be replayed. 355 User agents that send a request in early data are expected to retry 356 the request when receiving a 425 (Too Early) response status code. A 357 user agent MAY do so automatically, but any retries MUST NOT be sent 358 in early data. 360 In all cases, an intermediary can forward a 425 (Too Early) status 361 code. Intermediaries MUST forward a 425 (Too Early) status code if 362 the request that it received and forwarded contained an "Early-Data" 363 header field. Otherwise, an intermediary that receives a request in 364 early data MAY automatically retry that request in response to a 425 365 (Too Early) status code, but it MUST wait for the TLS handshake to 366 complete on the connection where it received the request. 368 The server cannot assume that a client is able to retry a request 369 unless the request is received in early data or the "Early-Data" 370 header field is set to "1". A server SHOULD NOT emit the 425 status 371 code unless one of these conditions is met. 373 The 425 (Too Early) status code is not cacheable by default. Its 374 payload is not the representation of any identified resource. 376 6. Security Considerations 378 Using early data exposes a client to the risk that their request is 379 replayed. A retried or replayed request can produce different side 380 effects on the server. In addition to those side effects, replays 381 and retries might be used for traffic analysis to recover information 382 about requests or the resources those requests target. In 383 particular, a request that is replayed might result in a different 384 response, which might be observable from the length of protected data 385 even if the content remains confidential. 387 6.1. Gateways and Early Data 389 A gateway MUST NOT forward requests that were received in early data 390 unless it knows that the origin server it will forward to understands 391 the "Early-Data" header field and will correctly generate a 425 (Too 392 Early) status code. A gateway that is uncertain about origin server 393 support for a given request SHOULD either delay forwarding the 394 request until the TLS handshake with its client completes, or send a 395 425 (Too Early) status code in response. 397 A gateway without at least one potential origin server that supports 398 "Early-Data" header field expends significant effort for what can at 399 best be a modest performance benefit from enabling early data. If no 400 origin server supports early data, disabling early data entirely is 401 more efficient. 403 6.2. Consistent Handling of Early Data 405 Consistent treatment of a request that arrives in - or partially in - 406 early data is critical to avoiding inappropriate processing of 407 replayed requests. If a request is not safe to process before the 408 TLS handshake completes, then all instances of the server (including 409 gateways) need to agree and either reject the request or delay 410 processing. 412 Disabling early data, delaying requests, or rejecting requests with 413 the 425 (Too Early) status code are all equally good measures for 414 mitigating replay attacks on requests that might be vulnerable to 415 replay. Server instances can implement any of these measures and be 416 considered to be consistent, even if different instances use 417 different methods. Critically, this means that it is possible to 418 employ different mitigations in reaction to other conditions, such as 419 server load. 421 A server MUST NOT act on early data before the handshake completes if 422 it and any other server instance could make a different decision 423 about how to handle the same data. 425 6.3. Denial of Service 427 Accepting early data exposes a server to potential denial of service 428 through the replay of requests that are expensive to handle. A 429 server that is under load SHOULD prefer rejecting TLS early data as a 430 whole rather than accepting early data and selectively processing 431 requests. Generating a 503 (Service Unavailable) or 425 (Too Early) 432 status code often leads to clients retrying requests, which could 433 result in increased load. 435 6.4. Out of Order Delivery 437 In protocols that deliver data out of order (such as QUIC [HQ]) early 438 data can arrive after the handshake completes. A server MAY process 439 requests received in early data after handshake completion only if it 440 can rely on other instances correctly handling replays of the same 441 requests. 443 7. IANA Considerations 445 This document registers the "Early-Data" header field in the "Message 446 Headers" registry located at https://www.iana.org/assignments/ 447 message-headers [4]. 449 Header field name: Early-Data 451 Applicable protocol: http 453 Status: standard 455 Author/Change controller: IETF 457 Specification document(s): This document 459 Related information: (empty) 461 This document registers the 425 (Too Early) status code in the 462 "Hypertext Transfer Protocol (HTTP) Status Code" registry located at 463 https://www.iana.org/assignments/http-status-codes [5]. 465 Value: 425 467 Description: Too Early 469 Reference: This document 471 8. References 473 8.1. Normative References 475 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 476 Specifications: ABNF", STD 68, RFC 5234, 477 DOI 10.17487/RFC5234, January 2008, 478 . 480 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 481 Protocol (HTTP/1.1): Message Syntax and Routing", 482 RFC 7230, DOI 10.17487/RFC7230, June 2014, 483 . 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 491 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 492 DOI 10.17487/RFC7231, June 2014, 493 . 495 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 496 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 497 May 2017, . 499 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 500 Version 1.3", draft-ietf-tls-tls13-22 (work in progress), 501 November 2017. 503 8.2. Informative References 505 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 506 "Transport Layer Security (TLS) Application-Layer Protocol 507 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 508 July 2014, . 510 [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over 511 QUIC", draft-ietf-quic-http-08 (work in progress), 512 December 2017. 514 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 515 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 516 DOI 10.17487/RFC7540, May 2015, 517 . 519 8.3. URIs 521 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 523 [2] http://httpwg.github.io/ 525 [3] https://github.com/httpwg/http-extensions/labels/replay 527 [4] https://www.iana.org/assignments/message-headers 529 [5] https://www.iana.org/assignments/http-status-codes 531 Acknowledgments 533 This document was not easy to produce. The following people made 534 substantial contributions to the quality and completeness of the 535 document: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari 536 Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor 537 Vasiliev. 539 Authors' Addresses 541 Martin Thomson 542 Mozilla 544 Email: martin.thomson@gmail.com 546 Mark Nottingham 547 Fastly 549 Email: mnot@mnot.net 551 Willy Tarreau 552 HAProxy Technologies 554 Email: willy@haproxy.org