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