idnits 2.17.00 (12 Aug 2021) /tmp/idnits38460/draft-ietf-httpbis-replay-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2017) is 1638 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) == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track M. Nottingham 5 Expires: May 28, 2018 Fastly 6 W. Tarreau 7 HAProxy Technologies 8 November 24, 2017 10 Using Early Data in HTTP 11 draft-ietf-httpbis-replay-02 13 Abstract 15 This document explains the risks of using early data for HTTP and 16 describes techniques for reducing them. In particular, it defines a 17 mechanism that enables clients to communicate with servers about 18 early data, to assure correct operation. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 28, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 56 2. Early Data in HTTP . . . . . . . . . . . . . . . . . . . . . 3 57 3. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3 58 4. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 5 59 5. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 6 60 5.1. The Early-Data Header Field . . . . . . . . . . . . . . . 6 61 5.2. The 425 (Too Early) Status Code . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6.1. Gateways and Early Data . . . . . . . . . . . . . . . . . 8 64 6.2. Consistent Handling of Early Data . . . . . . . . . . . . 8 65 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 8 66 6.4. Out of Order Delivery . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 TLS 1.3 [TLS13] introduces the concept of early data (also known as 77 zero round trip data or 0-RTT data). Early data allows a client to 78 send data to a server in the first round trip of a connection, 79 without waiting for the TLS handshake to complete if the client has 80 spoken to the same server recently. 82 When used with HTTP [HTTP], early data allows clients to send 83 requests immediately, avoiding the one or two round trip delay needed 84 for the TLS handshake. This is a significant performance 85 enhancement; however, it has significant limitations. 87 The primary risk of using early data is that an attacker might 88 capture and replay the request(s) it contains. TLS [TLS13] describes 89 techniques that can be used to reduce the likelihood that an attacker 90 can successfully replay a request, but these techniques can be 91 difficult to deploy, and still leave some possibility of a successful 92 attack. 94 Note that this is different from automated or user-initiated retries; 95 replays are initiated by an attacker without the awareness of the 96 client. 98 To help mitigate the risk of replays in HTTP, this document gives an 99 overview of techniques for controlling these risks in servers, and 100 defines requirements for clients when sending requests in early data. 102 The advice in this document also applies to use of 0-RTT in HTTP over 103 QUIC [HQ]. 105 1.1. Conventions and Definitions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 2. Early Data in HTTP 115 Conceptually, early data is concatenated with other application to 116 form a single stream. This can mean that requests are entirely 117 contained within early data, or only part of a request is early. In 118 a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], 119 multiple requests might be partially delivered in early data. 121 The model that this document assumes is that once the TLS handshake 122 completes, the early data received on that TLS connection is known to 123 not be a replayed copy of that data. However, it is important to 124 note that this does not mean that early data will not be or has not 125 been replayed on another connection. 127 3. Supporting Early Data in HTTP Servers 129 A server decides whether or not to offer a client the ability to send 130 early data on future connections when sending the TLS session ticket. 132 When a server enables early data, there are a number of techniques it 133 can use to mitigate the risks of replay: 135 1. TLS [TLS13] mandates the use of replay detection strategies that 136 reduce the ability of an attacker to successfully replay early 137 data. These anti-replay techniques reduce but don't completely 138 eliminate the chance of data being replayed and ensure a fixed 139 upper limit to the number of replays. 141 2. The server can choose whether it will process early data before 142 the TLS handshake completes. By deferring processing, it can 143 ensure that only a successfully completed connection is used for 144 the request(s) therein. This provides the server with some 145 assurance that the early data was not replayed. 147 3. If the server receives multiple requests in early data, it can 148 determine whether to defer HTTP processing on a per-request 149 basis. This may require buffering the responses to preserve 150 ordering in HTTP/1.1. 152 4. The server can cause a client to retry a request and not use 153 early data by responding with the 425 (Too Early) status code 154 (Section 5.2), in cases where the risk of replay is judged too 155 great. 157 For a given request, the level of tolerance to replay risk is 158 specific to the resource it operates upon (and therefore only known 159 to the origin server). In general, if processing a request does not 160 have state-changing side effects, the consequences of replay are not 161 significant. 163 The request method's safety ([RFC7231], Section 4.2.1) is one way to 164 determine this. However, some resources do elect to associate side 165 effects with safe methods, so this cannot be universally relied upon. 167 It is RECOMMENDED that origin servers allow resources to explicitly 168 configure whether early data is appropriate in requests. Absent such 169 explicit information, they SHOULD mitigate against early data in 170 requests that have unsafe methods, using the techniques outlined 171 above. 173 A request might be sent partially in early data with the remainder of 174 the request being sent after the handshake completes. This does not 175 necessarily affect handling of that request; what matters is when the 176 server starts acting upon the contents of a request. Any time any 177 server instance might initiate processing prior to completion of the 178 handshake, all server instances need to consider how a possible 179 replay of early data could affect that processing (see also 180 Section 6.2). 182 A server can partially process requests that are incomplete. Parsing 183 header fields - without acting on the values - and determining 184 request routing is likely to be safe from side-effects, but other 185 actions might not be. 187 Intermediary servers do not have sufficient information to make this 188 determination, so Section 5.2 describes a way for the origin to 189 signal to them that a particular request isn't appropriate for early 190 data. Intermediaries that accept early data MUST implement that 191 mechanism. 193 Note that a server cannot choose to selectively reject early data at 194 the TLS layer. TLS only permits a server to accept all early data, 195 or none of it. Once a server has decided to accept early data, it 196 MUST process all requests in early data, even if the server rejects 197 the request by sending a 425 (Too Early) response. 199 A server can limit the amount of early data with the 200 "max_early_data_size" field of the "early_data" TLS extension. This 201 can be used to avoid committing an arbitrary amount of memory for 202 deferred requests. A server SHOULD ensure that when it accepts early 203 data, it can defer processing of requests until after the TLS 204 handshake completes. 206 4. Using Early Data in HTTP Clients 208 A client that wishes to use early data commences sending HTTP 209 requests immediately after sending the TLS ClientHello. 211 By their nature, clients have control over whether a given request is 212 sent in early data - thereby giving the client control over risk of 213 replay. Absent other information, clients MAY send requests with 214 safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when 215 it is available, and SHOULD NOT send unsafe methods (or methods whose 216 safety is not known) in early data. 218 If the server rejects early data at the TLS layer, a client MUST 219 start sending again as though the connection was new. This could 220 entail using a different negotiated protocol [ALPN] than the one 221 optimistically used for the early data. If HTTP/2 is selected after 222 early data is rejected, a client sends another connection preface. 223 Any requests sent in early data MUST be sent again, unless the client 224 decides to abandon those requests. 226 This automatic retry exposes the request to a potential replay 227 attack. An attacker sends early data to one server instance that 228 accepts and processes the early data, but allows that connection to 229 proceed no further. The attacker then forwards the same messages 230 from the client to another server instance that will reject early 231 data. The client then retries the request, resulting in the request 232 being processed twice. Replays are also possible if there are 233 multiple server instances that will accept early data, or if the same 234 server accepts early data multiple times (though this would be in 235 violation of requirements in Section 8 of [TLS13]). 237 Clients that use early data MUST retry requests upon receipt of a 425 238 (Too Early) status code; see Section 5.2. 240 An intermediary MUST NOT use early data when forwarding a request 241 unless early data was used on a previous hop, or it knows that the 242 request can be retried safely without consequences (typically, using 243 out-of-band configuration). Absent better information, that means 244 that an intermediary can only use early data if the request either 245 arrived in early data or arrived with the "Early-Data" header field 246 set to "1" (see Section 5.1). 248 5. Extensions for Early Data in HTTP 250 Because HTTP requests can span multiple "hops", it is necessary to 251 explicitly communicate whether a request has been sent in early data 252 on a previous connection. Likewise, some means of explicitly 253 triggering a retry when early data is not desirable is necessary. 254 Finally, it is necessary to know whether the client will actually 255 perform such a retry. 257 To meet these needs, two signalling mechanisms are defined: 259 o The "Early-Data" header field is included in requests that might 260 have been forwarded by an intermediary prior to the TLS handshake 261 completing. 263 o The 425 (Too Early) status code is defined for a server to 264 indicate that a request could not be processed due to the 265 consequences of a possible replay attack. 267 They are designed to enable better coordination of the use of early 268 data between the user agent and origin server, and also when a 269 gateway (also "reverse proxy", "Content Delivery Network", or 270 "surrogate") is present. 272 Gateways typically don't have specific information about whether a 273 given request can be processed safely when it is sent in early data. 274 In many cases, only the origin server has the necessary information 275 to decide whether the risk of replay is acceptable. These extensions 276 allow coordination between a gateway and its origin server. 278 5.1. The Early-Data Header Field 280 The "Early-Data" request header field indicates that the request has 281 been conveyed in early data, and additionally indicates that a client 282 understands the 425 (Too Early) status code. 284 It has just one valid value: "1". Its syntax is defined by the 285 following ABNF [ABNF]: 287 Early-Data = "1" 289 For example: 291 GET /resource HTTP/1.0 292 Host: example.com 293 Early-Data: 1 295 An intermediary that forwards a request prior to the completion of 296 the TLS handshake MUST send it with the "Early-Data" header field set 297 to "1" (i.e., it adds it if not present in the request). An 298 intermediary MUST use the "Early-Data" header field if it might have 299 forwarded the request prior to handshake completion (see Section 6.2 300 for details). 302 An intermediary MUST NOT remove this header field if it is present in 303 a request. 305 The "Early-Data" header field is not intended for use by user agents 306 (that is, the original initiator of a request). Sending a request in 307 early data implies that the client understands this specification and 308 is willing to retry a request in response to a 425 (Too Early) status 309 code. A user agent that sends a request in early data does not need 310 to include the "Early-Data" header field. 312 A server cannot make a request that contains the Early-Data header 313 field safe for processing by waiting for the handshake to complete. 314 A request that is marked with Early-Data was sent in early data on a 315 previous hop. Requests that contain the Early-Data field and cannot 316 be safely processed MUST be rejected using the 425 (Too Early) status 317 code. 319 5.2. The 425 (Too Early) Status Code 321 A 425 (Too Early) status code indicates that the server is unwilling 322 to risk processing a request that might be replayed. 324 User agents that send a request in early data MUST automatically 325 retry the request when receiving a 425 (Too Early) response status 326 code. Such retries MUST NOT be sent in early data. 328 In all cases, an intermediary can forward a 425 (Too Early) status 329 code. Intermediaries MUST forward a 425 (Too Early) status code if 330 the request that it received and forwarded contained an "Early-Data" 331 header field. Otherwise, an intermediary that receives a request in 332 early data MAY automatically retry that request in response to a 425 333 (Too Early) status code, but it MUST wait for the TLS handshake to 334 complete on the connection where it received the request. 336 The server cannot assume that a client is able to retry a request 337 unless the request is received in early data or the "Early-Data" 338 header field is set to "1". A server SHOULD NOT emit the 425 status 339 code unless one of these conditions is met. 341 The 425 (Too Early) status code is not cacheable by default. Its 342 payload is not the representation of any identified resource. 344 6. Security Considerations 346 Using early data exposes a client to the risk that their request is 347 replayed. A retried or replayed request can produce different side 348 effects on the server. In addition to those side effects, replays 349 and retries might be used for traffic analysis to recover information 350 about requests or the resources those requests target. 352 6.1. Gateways and Early Data 354 A gateway that forwards requests that were received in early data 355 MUST only do so if it knows that the origin server that receives 356 those requests understands the "Early-Data" header field and will 357 correctly generate a 425 (Too Early) status code. A gateway that 358 isn't certain about origin server support SHOULD either delay 359 forwarding the request until the TLS handshake with its client 360 completes, or send a 425 (Too Early) status code in response. A 361 gateway that is uncertain about whether an origin server supports the 362 "Early-Data" header field SHOULD disable early data. 364 6.2. Consistent Handling of Early Data 366 Consistent treatment of a request that arrives in - or partially in - 367 early data is critical to avoiding inappropriate processing of 368 replayed requests. If a request is not safe to process before the 369 TLS handshake completes, then all instances of the server (including 370 gateways) need to agree and either reject the request or delay 371 processing. 373 A server MUST NOT act on early data before the handshake completes if 374 it and any other server instance could make a different decision 375 about how to handle the same data. 377 6.3. Denial of Service 379 Accepting early data exposes a server to potential denial of service 380 through the replay of requests that are expensive to handle. A 381 server that is under load SHOULD prefer rejecting TLS early data as a 382 whole rather than accepting early data and selectively processing 383 requests. Generating a 503 (Service Unavailable) or 425 (Too Early) 384 status code often leads to clients retrying requests, which could 385 result in increased load. 387 6.4. Out of Order Delivery 389 In protocols that deliver data out of order (such as QUIC [HQ]) early 390 data can arrive after the handshake completes. This leads to 391 potential ambiguity about the status of requests and could lead to 392 inconsistent treatment (see Section 6.2). Implementations MUST 393 either ensure that any early data that is delivered late is either 394 discarded or consistently identified and processed. 396 7. IANA Considerations 398 This document registers the "Early-Data" header field in the "Message 399 Headers" registry [HEADERS]. 401 Header field name: Early-Data 403 Applicable protocol: http 405 Status: standard 407 Author/Change controller: IETF 409 Specification document(s): This document 411 Related information: (empty) 413 This document registers the 425 (Too Early) status code in the 414 "Hypertext Transfer Protocol (HTTP) Status Code" registry established 415 in [RFC7231]. 417 Value: 425 419 Description: Too Early 421 Reference: This document 423 8. References 425 8.1. Normative References 427 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 428 Specifications: ABNF", STD 68, RFC 5234, 429 DOI 10.17487/RFC5234, January 2008, 430 . 432 [HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration 433 Procedures for Message Header Fields", BCP 90, RFC 3864, 434 DOI 10.17487/RFC3864, September 2004, 435 . 437 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 438 Protocol (HTTP/1.1): Message Syntax and Routing", 439 RFC 7230, DOI 10.17487/RFC7230, June 2014, 440 . 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 448 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 449 DOI 10.17487/RFC7231, June 2014, 450 . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 457 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 458 July 2017. 460 8.2. Informative References 462 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 463 "Transport Layer Security (TLS) Application-Layer Protocol 464 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 465 July 2014, . 467 [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over 468 QUIC", draft-ietf-quic-http-07 (work in progress), October 469 2017. 471 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 472 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 473 DOI 10.17487/RFC7540, May 2015, 474 . 476 Acknowledgments 478 This document was not easy to produce. The following people made 479 substantial contributions to the quality and completeness of the 480 document: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho 481 Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev. 483 Authors' Addresses 485 Martin Thomson 486 Mozilla 488 Email: martin.thomson@gmail.com 490 Mark Nottingham 491 Fastly 493 Email: mnot@mnot.net 495 Willy Tarreau 496 HAProxy Technologies 498 Email: willy@haproxy.org