idnits 2.17.1 draft-thomson-http-replay-00.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 (June 22, 2017) is 2494 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-20 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: December 24, 2017 true 6 W. Tarreau 7 HAProxy Technologies 8 June 22, 2017 10 Using Early Data in HTTP 11 draft-thomson-http-replay-00 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 December 24, 2017. 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. Supporting Early Data in HTTP Servers . . . . . . . . . . . . 3 57 3. Using Early Data in HTTP Clients . . . . . . . . . . . . . . 4 58 4. Extensions for Early Data in HTTP . . . . . . . . . . . . . . 5 59 4.1. The Early-Data Header Field . . . . . . . . . . . . . . . 6 60 4.2. The 4NN (Too Early) Status Code . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 TLS 1.3 [TLS13] introduces the concept of early data (also known as 71 zero round trip data or 0-RTT data). Early data allows a client to 72 send data to a server in the first round trip of a connection, 73 without waiting for the TLS handshake to complete if the client has 74 spoken to the same server recently. 76 When used with HTTP [HTTP], early data allows clients to send 77 requests immediately, avoiding the one or two round trip delay needed 78 for the TLS handshake. This is a significant performance 79 enhancement; however, it has significant limitations. 81 The primary risk of using early data is that an attacker might 82 capture and replay the request(s) it contains. TLS [TLS13] describes 83 techniques that can be used to reduce the likelihood that an attacker 84 can successfully replay a request, but these techniques can be 85 difficult to deploy, and still leave some possibility of a successful 86 attack. 88 Note that this is different from automated or user-initiated retries; 89 replays are under the control of an attacker, and are therefore 90 malicious. 92 To help mitigate the risk of replays in HTTP, this document gives an 93 overview of techniques for controlling these risks in servers, and 94 defines requirements for clients when sending requests in early data. 96 The advice in this document also applies to use of 0-RTT in HTTP over 97 QUIC [HQ]. 99 1.1. Conventions and Definitions 101 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 102 document. It's not shouting; when they are capitalized, they have 103 the special meaning defined in [RFC2119]. 105 2. Supporting Early Data in HTTP Servers 107 A server decides whether or not to offer a client the ability to send 108 early data on future connections when sending the TLS session ticket. 110 When a server enables early data, there are a number of techniques it 111 can use to mitigate the risks of replay: 113 1. The server can choose whether it will process early data before 114 the TLS handshake completes. By deferring processing, it can 115 ensure that only a successfully completed connection is used for 116 the request(s) therein. Assuming that a replayed ClientHello 117 will not result in additional connections being made by the 118 client, this provides the server with some assurance that the 119 early data was not replayed. 121 2. If the server receives multiple requests in early data, it can 122 determine whether to defer HTTP processing on a per-request 123 basis. This may require buffering the responses to preserve 124 ordering in HTTP/1.1. 126 3. The server can cause a client to retry a request and not use 127 early data by responding with the 4NN (Too Early) status code 128 (Section 4.2), in cases where the risk of replay is judged too 129 great. 131 4. Finally, TLS [TLS13] describes several mitigation strategies that 132 reduce the ability of an attacker to successfully replay early 133 data. Servers are strongly encouraged to implement these 134 techniques, but to also recognize that they are imperfect. 136 For a given request, the level of tolerance to replay risk is 137 specific to the resource it operates upon (and therefore only known 138 to the origin server). In general, if a request does not have state- 139 changing side effects on a resource, the consequences of replay are 140 not significant. 142 The request method's safety ([RFC7231], Section 4.2.1) is one way to 143 determine this. However, some resources do elect to associate side 144 effects with safe methods, so this cannot be universally relied upon. 146 It is RECOMMENDED that origin servers allow resources to explicitly 147 configure whether early data is appropriate in requests. Absent such 148 explicit information, they SHOULD mitigate against early data in 149 requests that have unsafe methods, using the techniques outlined 150 above. 152 Intermediary servers do not have sufficient information to make this 153 determination, so Section 4.2 describes a way for the origin to 154 signal to them that a particular request isn't appropriate for early 155 data. Intermediaries that accept early data MUST implement that 156 mechanism. 158 Note that a server cannot choose to selectively reject early data. 159 TLS only permits a server to accept all early data, or none of it. 160 Once a server has decided to accept early data, it MUST process all 161 requests in early data, even if the server rejects the request by 162 sending a 4NN (Too Early) response. 164 A server can limit the amount of early data with the 165 "max_early_data_size" field of the "early_data" TLS extension. This 166 can be used to avoid committing an arbitrary amount of memory for 167 deferred requests. A server SHOULD ensure that when it accepts early 168 data, it can defer processing of requests until after the TLS 169 handshake completes. 171 3. Using Early Data in HTTP Clients 173 A client that wishes to use early data commences sending HTTP 174 requests immediately after sending the TLS ClientHello. 176 By their nature, clients have control over whether a given request is 177 sent in early data - thereby giving the client control over risk of 178 replay. Absent other information, clients MAY send requests with 179 safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when 180 it is available, and SHOULD NOT send unsafe methods (or methods whose 181 safety is not known) in early data. 183 If the server rejects early data, a client MUST start sending again 184 as though the connection was new. For HTTP/2, this means re-sending 185 the connection preface. Any requests sent in early data MUST be sent 186 again, unless the client decides to abandon those requests. 188 This automatic retry exposes the request to a potential replay 189 attack. An attacker sends early data to one server instance that 190 accepts and processes the early data, but allows that connection to 191 proceed no further. The attacker then forwards the same messages 192 from the client to another server instance that will reject early 193 data. The client the retries the request, resulting in the request 194 being processed twice. Replays are also possible if there are 195 multiple server instances that will accept early data, or if the same 196 server accepts early data multiple times (though this would be in 197 violation of requirements in TLS). 199 Clients that use early data MUST retry requests upon receipt of a 4NN 200 (Too Early) status code; see Section 4.2. 202 An intermediary MUST NOT use early data when forwarding a request 203 unless early data was used on a previous hop, or it knows that the 204 request can be retried safely without consequences (typically, using 205 out-of-band configuration). Absent better information, that means 206 that an intermediary can only use early data if the request that 207 either arrived in early data or arrived with the "Early-Data" header 208 field set to "1". 210 4. Extensions for Early Data in HTTP 212 Because HTTP requests can span multiple "hops", it is necessary to 213 explicitly communicate whether a request has been sent in early data 214 on a previous connection. Likewise, some means of explicitly 215 triggering a retry when early data is not desirable is necessary. 216 Finally, it is necessary to know whether the client will actually 217 perform such a retry. 219 To meet these needs, two signalling mechanisms are defined: 221 o The "Early-Data" header field is included in requests that are 222 received in early data. 224 o The 4NN (Too Early) status code is defined for an origin server to 225 indicate that a request could not be processed due to the 226 consequences of a possible replay attack. 228 They are designed to enable better coordination of the use of early 229 data between the user agent and origin server, and also when a 230 gateway (also "reverse proxy", "Content Delivery Network", or 231 "surrogate") is present. 233 Gateways typically don't have specific information about whether a 234 given request can be processed safely when it is sent in early data. 235 In many cases, only the origin server has the necessary information 236 to decide whether the risk of replay is acceptable. These extensions 237 allow coordination between a gateway and its origin server. 239 4.1. The Early-Data Header Field 241 The "Early-Data" request header field indicates that the request has 242 been conveyed in early data, and additionally indicates that a client 243 understands the 4NN (Too Early) status code. 245 It has just one valid value: "1". Its syntax is defined by the 246 following ABNF [ABNF]: 248 Early-Data = "1" 250 For example: 252 GET /resource HTTP/1.0 253 Host: example.com 254 Early-Data: 1 256 An intermediary that forwards a request received in TLS early data 257 MUST send it with the "Early-Data" header field set to "1" (i.e., it 258 adds it if not present in the request). 260 An intermediary MUST NOT remove this header field if it is present in 261 a request. 263 The "Early-Data" header field is not intended for use by user agents 264 (that is, the original initiator of a request). Sending a request in 265 early data implies that the client understands this specification and 266 is willing to retry a request in response to a 4NN (Too Early) status 267 code. A user agent that sends a request in early data does not need 268 to include the "Early-Data" header field. 270 4.2. The 4NN (Too Early) Status Code 272 A 4NN (Too Early) status code indicates that the server is unwilling 273 to risk processing a request that might be (or has been) replayed. 275 Clients (user-agents and intermediaries) that sent the request in 276 early data MUST automatically retry the request when receiving a 4NN 277 (Too Early) response status code. Such retries MUST NOT be sent in 278 early data, and SHOULD NOT be sent if the TLS handshake on the 279 original connection does not successfully complete. 281 Intermediaries that receive the 4NN (Too Early) status code MUST NOT 282 automatically retry requests when the original request already 283 contained the "Early-Data" header field with a value of "1" or the 284 request arrived at the intermediary in early data; instead, they MUST 285 forward the 4NN (Too Early) response to the client. 287 The server cannot assume that a client is able to retry a request 288 unless the request is received in early data or the "Early-Data" 289 header field is set to "1". A server SHOULD NOT emit the 4NN status 290 code unless one of these conditions is met. 292 The 4NN (Too Early) status code is not cacheable by default. Its 293 payload is not the representation of any identified resource. 295 5. Security Considerations 297 Using early data exposes a client to the risk that their request is 298 replayed. A retried or replayed request can produce different side 299 effects on the server. That might be used for traffic analysis to 300 recover information about requests or the resources those requests 301 target. 303 A gateway that forwards requests that were received in early data 304 MUST only do so if it knows that the server that receives those 305 requests understands the "Early-Data" header field and will correctly 306 generate a 4NN (Too Early) status code. A gateway that isn't certain 307 about server support SHOULD either delay forwarding the request until 308 the TLS handshake completes, or send a 4NN (Too Early) status code in 309 response. 311 6. IANA Considerations 313 This document registers the "Early-Data" header field in the "Message 314 Headers" registry [HEADERS]. 316 Header field name: Early-Data 318 Applicable protocol: http 320 Status: standard 322 Author/Change controller: IETF 324 Specification document(s): This document 326 Related information: (empty) 328 This document registers the 4NN (Too Early) status code in the 329 "Hypertext Transfer Protocol (HTTP) Status Code" registry established 330 in [RFC7231]. 332 Value: 4NN 334 Description: Too Early 335 Reference: This document 337 7. References 339 7.1. Normative References 341 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 342 Specifications: ABNF", STD 68, RFC 5234, 343 DOI 10.17487/RFC5234, January 2008, 344 . 346 [HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration 347 Procedures for Message Header Fields", BCP 90, RFC 3864, 348 DOI 10.17487/RFC3864, September 2004, 349 . 351 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 352 Protocol (HTTP/1.1): Message Syntax and Routing", 353 RFC 7230, DOI 10.17487/RFC7230, June 2014, 354 . 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 362 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 363 DOI 10.17487/RFC7231, June 2014, 364 . 366 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 367 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 368 April 2017. 370 7.2. Informative References 372 [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over 373 QUIC", draft-ietf-quic-http-04 (work in progress), June 374 2017. 376 Authors' Addresses 378 Martin Thomson 379 Mozilla 381 Email: martin.thomson@gmail.com 382 Mark Nottingham 383 true 385 Email: mnot@mnot.net 387 Willy Tarreau 388 HAProxy Technologies 390 Email: willy@haproxy.org