idnits 2.17.1 draft-thomson-http-replay-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 09, 2017) is 2451 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) ** 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-21 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-04 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpbis M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track M. Nottingham 5 Expires: February 10, 2018 true 6 W. Tarreau 7 HAProxy Technologies 8 August 09, 2017 10 Using Early Data in HTTP 11 draft-thomson-http-replay-01 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 http://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 February 10, 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 (http://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 4NN (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 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 TLS 1.3 [TLS13] introduces the concept of early data (also known as 76 zero round trip data or 0-RTT data). Early data allows a client to 77 send data to a server in the first round trip of a connection, 78 without waiting for the TLS handshake to complete if the client has 79 spoken to the same server recently. 81 When used with HTTP [HTTP], early data allows clients to send 82 requests immediately, avoiding the one or two round trip delay needed 83 for the TLS handshake. This is a significant performance 84 enhancement; however, it has significant limitations. 86 The primary risk of using early data is that an attacker might 87 capture and replay the request(s) it contains. TLS [TLS13] describes 88 techniques that can be used to reduce the likelihood that an attacker 89 can successfully replay a request, but these techniques can be 90 difficult to deploy, and still leave some possibility of a successful 91 attack. 93 Note that this is different from automated or user-initiated retries; 94 replays are initiated by an attacker without the awareness of the 95 client. 97 To help mitigate the risk of replays in HTTP, this document gives an 98 overview of techniques for controlling these risks in servers, and 99 defines requirements for clients when sending requests in early data. 101 The advice in this document also applies to use of 0-RTT in HTTP over 102 QUIC [HQ]. 104 1.1. Conventions and Definitions 106 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 107 document. It's not shouting; when they are capitalized, they have 108 the special meaning defined in [RFC2119]. 110 2. Early Data in HTTP 112 Conceptually, early data is concatenated with other application to 113 form a single stream. This can mean that requests are entirely 114 contained within early data, or only part of a request is early. In 115 a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], 116 multiple requests might be partially delivered in early data. 118 The model that this document assumes is that once the TLS handshake 119 completes, early data is not replayed. However, it is important to 120 note that this does not mean that early data will not be or has not 121 been replayed on another connection. 123 3. Supporting Early Data in HTTP Servers 125 A server decides whether or not to offer a client the ability to send 126 early data on future connections when sending the TLS session ticket. 128 When a server enables early data, there are a number of techniques it 129 can use to mitigate the risks of replay: 131 1. The server can choose whether it will process early data before 132 the TLS handshake completes. By deferring processing, it can 133 ensure that only a successfully completed connection is used for 134 the request(s) therein. Assuming that a replayed ClientHello 135 will not result in additional connections being made by the 136 client, this provides the server with some assurance that the 137 early data was not replayed. 139 2. If the server receives multiple requests in early data, it can 140 determine whether to defer HTTP processing on a per-request 141 basis. This may require buffering the responses to preserve 142 ordering in HTTP/1.1. 144 3. The server can cause a client to retry a request and not use 145 early data by responding with the 4NN (Too Early) status code 146 (Section 5.2), in cases where the risk of replay is judged too 147 great. 149 4. Finally, TLS [TLS13] describes several mitigation strategies that 150 reduce the ability of an attacker to successfully replay early 151 data. Servers are strongly encouraged to implement these 152 techniques, but to also recognize that they are imperfect. These 153 anti-replay techniques can reduce the number of replays that will 154 be successful from being essentially unbounded to a fixed value. 156 For a given request, the level of tolerance to replay risk is 157 specific to the resource it operates upon (and therefore only known 158 to the origin server). In general, if processing a request does not 159 have state-changing side effects, the consequences of replay are not 160 significant. 162 The request method's safety ([RFC7231], Section 4.2.1) is one way to 163 determine this. However, some resources do elect to associate side 164 effects with safe methods, so this cannot be universally relied upon. 166 It is RECOMMENDED that origin servers allow resources to explicitly 167 configure whether early data is appropriate in requests. Absent such 168 explicit information, they SHOULD mitigate against early data in 169 requests that have unsafe methods, using the techniques outlined 170 above. 172 A request might be sent partially in early data with the remainder of 173 the request being sent after the handshake completes. This does not 174 necessarily affect handling of that request; what matters is when the 175 server starts acting upon the contents of a request. Any time a 176 server might initiate processing prior to completion of the handshake 177 needs to consider how a possible replay of early data could affect 178 that processing (see also Section 6.2). 180 A server can partially process requests that are incomplete. Parsing 181 header fields - without acting on the values - and determining 182 request routing is likely to be safe from side-effects, but other 183 actions might not be. 185 Intermediary servers do not have sufficient information to make this 186 determination, so Section 5.2 describes a way for the origin to 187 signal to them that a particular request isn't appropriate for early 188 data. Intermediaries that accept early data MUST implement that 189 mechanism. 191 Note that a server cannot choose to selectively reject early data at 192 the TLS layer. TLS only permits a server to accept all early data, 193 or none of it. Once a server has decided to accept early data, it 194 MUST process all requests in early data, even if the server rejects 195 the request by sending a 4NN (Too Early) response. 197 A server can limit the amount of early data with the 198 "max_early_data_size" field of the "early_data" TLS extension. This 199 can be used to avoid committing an arbitrary amount of memory for 200 deferred requests. A server SHOULD ensure that when it accepts early 201 data, it can defer processing of requests until after the TLS 202 handshake completes. 204 4. Using Early Data in HTTP Clients 206 A client that wishes to use early data commences sending HTTP 207 requests immediately after sending the TLS ClientHello. 209 By their nature, clients have control over whether a given request is 210 sent in early data - thereby giving the client control over risk of 211 replay. Absent other information, clients MAY send requests with 212 safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when 213 it is available, and SHOULD NOT send unsafe methods (or methods whose 214 safety is not known) in early data. 216 If the server rejects early data at the TLS layer, a client MUST 217 start sending again as though the connection was new. For HTTP/2, 218 this means re-sending the connection preface. Any requests sent in 219 early data MUST be sent again, unless the client decides to abandon 220 those requests. 222 This automatic retry exposes the request to a potential replay 223 attack. An attacker sends early data to one server instance that 224 accepts and processes the early data, but allows that connection to 225 proceed no further. The attacker then forwards the same messages 226 from the client to another server instance that will reject early 227 data. The client the retries the request, resulting in the request 228 being processed twice. Replays are also possible if there are 229 multiple server instances that will accept early data, or if the same 230 server accepts early data multiple times (though this would be in 231 violation of requirements in TLS). 233 Clients that use early data MUST retry requests upon receipt of a 4NN 234 (Too Early) status code; see Section 5.2. 236 An intermediary MUST NOT use early data when forwarding a request 237 unless early data was used on a previous hop, or it knows that the 238 request can be retried safely without consequences (typically, using 239 out-of-band configuration). Absent better information, that means 240 that an intermediary can only use early data if the request either 241 arrived in early data or arrived with the "Early-Data" header field 242 set to "1". 244 5. Extensions for Early Data in HTTP 246 Because HTTP requests can span multiple "hops", it is necessary to 247 explicitly communicate whether a request has been sent in early data 248 on a previous connection. Likewise, some means of explicitly 249 triggering a retry when early data is not desirable is necessary. 250 Finally, it is necessary to know whether the client will actually 251 perform such a retry. 253 To meet these needs, two signalling mechanisms are defined: 255 o The "Early-Data" header field is included in requests that are 256 received in early data. 258 o The 4NN (Too Early) status code is defined for an server to 259 indicate that a request could not be processed due to the 260 consequences of a possible replay attack. 262 They are designed to enable better coordination of the use of early 263 data between the user agent and origin server, and also when a 264 gateway (also "reverse proxy", "Content Delivery Network", or 265 "surrogate") is present. 267 Gateways typically don't have specific information about whether a 268 given request can be processed safely when it is sent in early data. 269 In many cases, only the origin server has the necessary information 270 to decide whether the risk of replay is acceptable. These extensions 271 allow coordination between a gateway and its origin server. 273 5.1. The Early-Data Header Field 275 The "Early-Data" request header field indicates that the request has 276 been conveyed in early data, and additionally indicates that a client 277 understands the 4NN (Too Early) status code. 279 It has just one valid value: "1". Its syntax is defined by the 280 following ABNF [ABNF]: 282 Early-Data = "1" 284 For example: 286 GET /resource HTTP/1.0 287 Host: example.com 288 Early-Data: 1 290 An intermediary that forwards a request received in TLS early data 291 MUST send it with the "Early-Data" header field set to "1" (i.e., it 292 adds it if not present in the request). 294 An intermediary MUST NOT remove this header field if it is present in 295 a request. 297 The "Early-Data" header field is not intended for use by user agents 298 (that is, the original initiator of a request). Sending a request in 299 early data implies that the client understands this specification and 300 is willing to retry a request in response to a 4NN (Too Early) status 301 code. A user agent that sends a request in early data does not need 302 to include the "Early-Data" header field. 304 A server cannot make a request that contains the Early-Data header 305 field safe for processing by waiting for the handshake to complete. 306 A request that is marked with Early-Data was sent in early data on a 307 previous hop. Requests that contain the Early-Data field and cannot 308 be safely processed MUST be rejected using the 4NN (Too Early) status 309 code. 311 5.2. The 4NN (Too Early) Status Code 313 A 4NN (Too Early) status code indicates that the server is unwilling 314 to risk processing a request that might be replayed. 316 Clients (user-agents and intermediaries) that sent the request in 317 early data MUST automatically retry the request when receiving a 4NN 318 (Too Early) response status code. Such retries MUST NOT be sent in 319 early data, and SHOULD NOT be sent if the TLS handshake on the 320 original connection does not successfully complete. 322 Intermediaries that receive a 4NN (Too Early) status code MAY 323 automatically retry requests after allowing the handshake to complete 324 unless the original request contained the "Early-Data" header field 325 when it was received. Otherwise, an intermediary MUST forward the 326 4NN (Too Early) status code. 328 The server cannot assume that a client is able to retry a request 329 unless the request is received in early data or the "Early-Data" 330 header field is set to "1". A server SHOULD NOT emit the 4NN status 331 code unless one of these conditions is met. 333 The 4NN (Too Early) status code is not cacheable by default. Its 334 payload is not the representation of any identified resource. 336 6. Security Considerations 338 Using early data exposes a client to the risk that their request is 339 replayed. A retried or replayed request can produce different side 340 effects on the server. In addition to those side effects, replays 341 and retries might be used for traffic analysis to recover information 342 about requests or the resources those requests target. 344 6.1. Gateways and Early Data 346 A gateway that forwards requests that were received in early data 347 MUST only do so if it knows that the server that receives those 348 requests understands the "Early-Data" header field and will correctly 349 generate a 4NN (Too Early) status code. A gateway that isn't certain 350 about server support SHOULD either delay forwarding the request until 351 the TLS handshake completes, or send a 4NN (Too Early) status code in 352 response. A gateway that is uncertain about whether an origin server 353 supports the "Early-Data" header field SHOULD disable early data. 355 6.2. Consistent Handling of Early Data 357 Consistent treatment of a request that arrives in - or partially in - 358 early data is critical to avoiding inappropriate processing of 359 replayed requests. If a request is not safe to process before the 360 TLS handshake completes, then all instances of the server need to 361 agree and either reject the request or delay processing. 363 6.3. Denial of Service 365 Accepting early data exposes a server to potential denial of service 366 through the replay of requests that are expensive to handle. A 367 server that is under load SHOULD prefer rejecting TLS early data as a 368 whole rather than accepting early data and selectively processing 369 requests. Generating a 503 (Service Unavailable) or 4NN (Too Early) 370 status code often leads to clients retrying requests, which could 371 result in increased load. 373 7. IANA Considerations 375 This document registers the "Early-Data" header field in the "Message 376 Headers" registry [HEADERS]. 378 Header field name: Early-Data 380 Applicable protocol: http 381 Status: standard 383 Author/Change controller: IETF 385 Specification document(s): This document 387 Related information: (empty) 389 This document registers the 4NN (Too Early) status code in the 390 "Hypertext Transfer Protocol (HTTP) Status Code" registry established 391 in [RFC7231]. 393 Value: 4NN 395 Description: Too Early 397 Reference: This document 399 8. References 401 8.1. Normative References 403 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 404 Specifications: ABNF", STD 68, RFC 5234, 405 DOI 10.17487/RFC5234, January 2008, 406 . 408 [HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration 409 Procedures for Message Header Fields", BCP 90, RFC 3864, 410 DOI 10.17487/RFC3864, September 2004, 411 . 413 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 414 Protocol (HTTP/1.1): Message Syntax and Routing", 415 RFC 7230, DOI 10.17487/RFC7230, June 2014, 416 . 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 424 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 425 DOI 10.17487/RFC7231, June 2014, 426 . 428 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 429 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 430 July 2017. 432 8.2. Informative References 434 [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over 435 QUIC", draft-ietf-quic-http-04 (work in progress), June 436 2017. 438 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 439 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 440 DOI 10.17487/RFC7540, May 2015, 441 . 443 Appendix A. Acknowledgments 445 This document was not easy to produce. The following people made 446 substantial contributions to the quality and completeness of the 447 document: Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho 448 Oku, and Victor Vasiliev. 450 Authors' Addresses 452 Martin Thomson 453 Mozilla 455 Email: martin.thomson@gmail.com 457 Mark Nottingham 458 true 460 Email: mnot@mnot.net 462 Willy Tarreau 463 HAProxy Technologies 465 Email: willy@haproxy.org