idnits 2.17.1 draft-thomson-httpapi-date-requests-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 date (9 February 2022) is 807 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) -- Possible downref: Normative reference to a draft: ref. 'CACHING' == Outdated reference: A later version (-07) exists of draft-ietf-httpapi-rfc7807bis-01 == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-00 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-message-signatures-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Building Blocks for HTTP APIs M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track 9 February 2022 5 Expires: 13 August 2022 7 Using The Date Header Field In HTTP Requests 8 draft-thomson-httpapi-date-requests-00 10 Abstract 12 HTTP clients rarely make use of the Date header field when making 13 requests. This document describes considerations for using the Date 14 header field in requests. A method is described for correcting 15 erroneous in Date request header fields that might arise from 16 differences in client and server clocks. The risks of applying that 17 correction technique are discussed. 19 About This Document 21 This note is to be removed before publishing as an RFC. 23 The latest revision of this draft can be found at 24 https://martinthomson.github.io/http-request-date/draft-thomson- 25 httpapi-date-requests.html. Status information for this document may 26 be found at https://datatracker.ietf.org/doc/draft-thomson-httpapi- 27 date-requests/. 29 Discussion of this document takes place on the Building Blocks for 30 HTTP APIs Working Group mailing list (mailto:httpapi@ietf.org), which 31 is archived at https://mailarchive.ietf.org/arch/browse/httpapi/. 33 Source for this draft and an issue tracker can be found at 34 https://github.com/martinthomson/http-request-date. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 13 August 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 71 3. Date in HTTP Requests . . . . . . . . . . . . . . . . . . . . 3 72 4. Date Not Acceptable Problem Type . . . . . . . . . . . . . . 4 73 5. Clock Skew . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Date Correction . . . . . . . . . . . . . . . . . . . . . 5 75 5.2. Limitations of Date Correction . . . . . . . . . . . . . 6 76 5.3. Intermediaries and Date Corrections . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 8.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 Many HTTP requests are timeless. That is, the contents of the 88 request are not bound to a specific point in time. Thus, the use of 89 the HTTP Date header field in requests is rare; see Section 6.6.1 of 90 [HTTP]. 92 However, in some contexts, it is important that a request only be 93 valid over a small period of time. One such context is when requests 94 are signed [SIGN], where including a time in a request might prevent 95 a signed request from being reused at another time. Similarly, some 96 uses of OHTTP [OHTTP] might depend on the same sort of replay 97 protection. It is possible to make anti-replay protections at 98 servers more efficient if requests from either far in the past or 99 into the future can be rejected. 101 This document describes some considerations for using the Date 102 request header field in Section 3. A new type of problem report 103 [PROBLEM] is defined in Section 4 for use in rejecting requests with 104 a missing or incorrect Date request header field. 106 Section 5 explores the consequences of using Date header field in 107 requests when client and server clocks do not agree. A method for 108 recovering from differences in clocks is described in Section 5.1. 109 Section 5.2 describes the privacy considerations that apply to this 110 technique. 112 2. Conventions and Definitions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. Date in HTTP Requests 122 Most HTTP clients have no need to use the Date header field in 123 requests. This only changes if it is important that the request not 124 be considered valid at another time. As requests are - by default - 125 trivially copied, stored, and modified by any entity that can read 126 them, the addition of a Date header field is unlikely to be useful in 127 many cases. 129 Signed HTTP requests are one example of where requests might be 130 available to entities that are not permitted to alter their contents. 131 Adding a Date request header field - and signing it - ensures that 132 the request cannot be used at a very different time to what was 133 intended. 135 OHTTP [OHTTP] is another example of where capture and replay of a 136 request might be undesirable. Here, a partially trusted 137 intermediary, an oblivious proxy resource, receives encapsulated HTTP 138 requests. Though this entity cannot read or modify these messages, 139 it is able to delay or replay them. The inclusion of a Date header 140 field in these requests might be used to limit the time over which 141 delay or replay is possible. 143 In both cases, the inclusion of a Date request header field might be 144 part of an anti-replay strategy at a server. A simple anti-replay 145 scheme starts by choosing a window of time anchored at the current 146 time. Requests with timestamps that fall within this period are 147 remembered and rejected if they appear again; requests with 148 timestamps outside of this window are rejected. This scheme works 149 for any monotonic value (see for example Section 3.4.3 of [RFC4303]) 150 and allows for efficient rejection of duplicate requests with minimal 151 state. 153 4. Date Not Acceptable Problem Type 155 A server can send a 400-series status code in response to a request 156 where the Date request header field is either absent or indicates a 157 time that is not acceptable to the server. Including content of type 158 "application/problem+json" (or "application/problem+xml"), as defined 159 in [PROBLEM], in that response allows the server to provide more 160 information about the error. 162 This document defines a problem type of 163 "https://iana.org/assignments/http-problem-types#date" for indicating 164 that the Date request header field is missing or incorrect. Figure 1 165 shows an example response in HTTP/1.1 format. 167 HTTP/1.1 400 Bad Request 168 Date: Mon, 07 Feb 2022 00:28:05 GMT 169 Content-Type: application/problem+json 170 Content-Length: 128 172 {"type":"https://iana.org/assignments/http-problem-types#date", 173 "title": "date field in request outside of acceptable range"} 175 Figure 1: Example Response 177 A server MUST include a Date response header field in any responses 178 that use this problem detail type. 180 In processing a Date header field in a request, a server MUST allow 181 for delays in transmitting the request, retransmissions performed by 182 transport protocols, plus any processing that might occur in the 183 client and any intermediaries, and those parts of the server prior to 184 processing the field. Additionally, the Date header field is only 185 capable of expressing time with a resolution of one second. These 186 factors could mean that the value a server receives could be some 187 time in the past. 189 Differences between client and server clocks are likely to be a 190 source of most disagreements between the server time and the time 191 expressed in Date request header field. Section 5 will explore this 192 problem in more detail and offer some means of handling these 193 disagreements. 195 5. Clock Skew 197 Perfect synchronization of client and server clocks is an ideal state 198 that generally only exists in tightly controlled settings. In 199 practice, despite good availability of time services like NTP [NTP] 200 Internet-connected endpoints often disagree about the time (see for 201 example Section 7.1 of [CLOCKSKEW]). 203 The prevalence of clock skew could justify servers being more 204 tolerant of a larger range of values for the Date request header 205 field. This includes accepting times that are a short duration into 206 the future in addition to times in the past. 208 For a server that uses the Date request header field to limit the 209 state kept for anti-replay purposes, the amount of state might be all 210 that determines the range of values it accepts. 212 5.1. Date Correction 214 Even when a server is tolerant of small clock errors, a valid request 215 from a client can be rejected if the client clock is outside of the 216 range of times that a server will accept. A server might also reject 217 a request when the client makes a request without a Date header 218 field. 220 A client can recover from a failure that caused by a bad clock by 221 adjusting the time and re-attempting the request. 223 For a fresh response (see Section 4.2 of [CACHING]), the client can 224 re-attempt the request, copying the Date header field from the 225 response into its new request. If the response is stale, the client 226 can add the age of the response to determine the time to use in a re- 227 attempt; see Section 5.3 for more. 229 In addition to adjusting for response age, the client can adjust the 230 time it uses based on the elapsed time since it estimates when the 231 response was generated. Note however that if the client retries a 232 request immediately, any additional increment is likely to be less 233 than the one second resolution of the Date header field under most 234 network conditions. 236 5.2. Limitations of Date Correction 238 Clients MUST NOT accept the time provided by an arbitrary HTTP server 239 as the basis for system-wide time. Even if the client code in 240 question were able to set the time, altering the system clock in this 241 way exposes clients to attack. The source of system time information 242 needs to be trustworthy as the current time is a critical input to 243 security-relevant decisions, such as whether to accept a server 244 certificate [RFC6125]. 246 Use of date correction allows requests that use the correction to be 247 correlated. Limitations on use of date corrections is necessary to 248 ensure privacy. An immediate retry of an identical request with an 249 update Date header field is safe in that it only provides the server 250 with the ability to match the retry to the original request. 252 Anything other than an immediate retry requires careful consideration 253 of the privacy implications. Use of the same date correction for 254 other requests can be used to link those requests to the same client. 255 Using the same date correction is equivalent to connection reuse, 256 cookies, TLS session tickets, or other state a client might carry 257 between requests. Linking requests might be acceptable, but in 258 general only where other forms of linkage already exist. 260 Clients MUST NOT use the time correction from one server when making 261 requests of another server. Using the same date correction across 262 different servers might be used by servers to link client identities 263 and to exchange information via a channel provided by the client. 265 For clients that maintain per-server state, the specific date 266 correction that is used for each server MUST be cleared when removing 267 other state for that server to prevent re-identification. For 268 instance, a web browser that remembers a date correction would forget 269 that correction when removing cookies and other state. 271 5.3. Intermediaries and Date Corrections 273 Some intermediaries, in particular those acting as reverse proxies or 274 gateways, will rewrite the Date header field in responses. This 275 applies especially to responses served from cache, but this might 276 also apply to those that are forwarded directly from an origin 277 server. 279 For responses that are forwarded by an intermediary, changes to the 280 Date response header field will not change how the client corrects 281 its clock. Errors only occur if the clock at the intermediary 282 differs significantly from the clock at the origin server or if the 283 intermediary updates the Date response header field without also 284 adjusting or removing the Age header field on a stale response. 286 Servers that condition their responses on the Date header field 287 SHOULD either ensure that intermediaries do not cache responses (by 288 including a Cache-Control directive of no-store) or designate the 289 response as conditional on the value of the Date request header field 290 (by including the token "date" in a Vary header field). 292 6. Security Considerations 294 Including a Date header field in requests reveals information about 295 the client clock. This might be used to identify clients with 296 vulnerability to attacks that depend on incorrect clocks. 298 Section 5.2 contains a discussion of the security and privacy 299 concerns associated with date correction. 301 7. IANA Considerations 303 IANA are requested to create a new entry in the "HTTP Problem Type" 304 registry established by [PROBLEM]. 306 Type URI: https://iana.org/assignments/http-problem-types#date 308 Title: Date Not Acceptable 310 Recommended HTTP Status Code: 400 312 Reference: Section 4 of this document 314 8. References 316 8.1. Normative References 318 [CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 319 Caching", Work in Progress, Internet-Draft, draft-ietf- 320 httpbis-cache-19, 12 September 2021, 321 . 324 [PROBLEM] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details 325 for HTTP APIs", Work in Progress, Internet-Draft, draft- 326 ietf-httpapi-rfc7807bis-01, 13 October 2021, 327 . 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 337 May 2017, . 339 8.2. Informative References 341 [CLOCKSKEW] 342 Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., 343 Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, 344 "Where the Wild Warnings Are: Root Causes of Chrome HTTPS 345 Certificate Errors", Proceedings of the 2017 ACM SIGSAC 346 Conference on Computer and Communications Security, 347 DOI 10.1145/3133956.3134007, October 2017, 348 . 350 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 351 Semantics", Work in Progress, Internet-Draft, draft-ietf- 352 httpbis-semantics-19, 12 September 2021, 353 . 356 [NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 357 "Network Time Protocol Version 4: Protocol and Algorithms 358 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 359 . 361 [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 362 Progress, Internet-Draft, draft-ietf-ohai-ohttp-00, 25 363 November 2021, . 366 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 367 RFC 4303, DOI 10.17487/RFC4303, December 2005, 368 . 370 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 371 Verification of Domain-Based Application Service Identity 372 within Internet Public Key Infrastructure Using X.509 373 (PKIX) Certificates in the Context of Transport Layer 374 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 375 2011, . 377 [SIGN] Backman, A., Richer, J., and M. Sporny, "HTTP Message 378 Signatures", Work in Progress, Internet-Draft, draft-ietf- 379 httpbis-message-signatures-08, 28 January 2022, 380 . 383 Acknowledgments 385 This document is a result of discussions about how to provide anti- 386 replay protection for OHTTP in which Mark Nottingham, Eric Rescorla, 387 and Chris Wood were instrumental. 389 Author's Address 391 Martin Thomson 392 Mozilla 394 Email: mt@lowentropy.net