\
Building Blocks for HTTP APIs                                 M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                         9 February 2022
Expires: 13 August 2022


              Using The Date Header Field In HTTP Requests
                 draft-thomson-httpapi-date-requests-00

Abstract

   HTTP clients rarely make use of the Date header field when making
   requests.  This document describes considerations for using the Date
   header field in requests.  A method is described for correcting
   erroneous in Date request header fields that might arise from
   differences in client and server clocks.  The risks of applying that
   correction technique are discussed.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://martinthomson.github.io/http-request-date/draft-thomson-
   httpapi-date-requests.html.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-thomson-httpapi-
   date-requests/.

   Discussion of this document takes place on the Building Blocks for
   HTTP APIs Working Group mailing list (mailto:httpapi@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/httpapi/.

   Source for this draft and an issue tracker can be found at
   https://github.com/martinthomson/http-request-date.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.







Thomson                  Expires 13 August 2022                 [Page 1]


Internet-Draft                Date Requests                February 2022


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 13 August 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Date in HTTP Requests . . . . . . . . . . . . . . . . . . . .   3
   4.  Date Not Acceptable Problem Type  . . . . . . . . . . . . . .   4
   5.  Clock Skew  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Date Correction . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Limitations of Date Correction  . . . . . . . . . . . . .   6
     5.3.  Intermediaries and Date Corrections . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Many HTTP requests are timeless.  That is, the contents of the
   request are not bound to a specific point in time.  Thus, the use of
   the HTTP Date header field in requests is rare; see Section 6.6.1 of
   [HTTP].






Thomson                  Expires 13 August 2022                 [Page 2]


Internet-Draft                Date Requests                February 2022


   However, in some contexts, it is important that a request only be
   valid over a small period of time.  One such context is when requests
   are signed [SIGN], where including a time in a request might prevent
   a signed request from being reused at another time.  Similarly, some
   uses of OHTTP [OHTTP] might depend on the same sort of replay
   protection.  It is possible to make anti-replay protections at
   servers more efficient if requests from either far in the past or
   into the future can be rejected.

   This document describes some considerations for using the Date
   request header field in Section 3.  A new type of problem report
   [PROBLEM] is defined in Section 4 for use in rejecting requests with
   a missing or incorrect Date request header field.

   Section 5 explores the consequences of using Date header field in
   requests when client and server clocks do not agree.  A method for
   recovering from differences in clocks is described in Section 5.1.
   Section 5.2 describes the privacy considerations that apply to this
   technique.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Date in HTTP Requests

   Most HTTP clients have no need to use the Date header field in
   requests.  This only changes if it is important that the request not
   be considered valid at another time.  As requests are - by default -
   trivially copied, stored, and modified by any entity that can read
   them, the addition of a Date header field is unlikely to be useful in
   many cases.

   Signed HTTP requests are one example of where requests might be
   available to entities that are not permitted to alter their contents.
   Adding a Date request header field - and signing it - ensures that
   the request cannot be used at a very different time to what was
   intended.









Thomson                  Expires 13 August 2022                 [Page 3]


Internet-Draft                Date Requests                February 2022


   OHTTP [OHTTP] is another example of where capture and replay of a
   request might be undesirable.  Here, a partially trusted
   intermediary, an oblivious proxy resource, receives encapsulated HTTP
   requests.  Though this entity cannot read or modify these messages,
   it is able to delay or replay them.  The inclusion of a Date header
   field in these requests might be used to limit the time over which
   delay or replay is possible.

   In both cases, the inclusion of a Date request header field might be
   part of an anti-replay strategy at a server.  A simple anti-replay
   scheme starts by choosing a window of time anchored at the current
   time.  Requests with timestamps that fall within this period are
   remembered and rejected if they appear again; requests with
   timestamps outside of this window are rejected.  This scheme works
   for any monotonic value (see for example Section 3.4.3 of [RFC4303])
   and allows for efficient rejection of duplicate requests with minimal
   state.

4.  Date Not Acceptable Problem Type

   A server can send a 400-series status code in response to a request
   where the Date request header field is either absent or indicates a
   time that is not acceptable to the server.  Including content of type
   "application/problem+json" (or "application/problem+xml"), as defined
   in [PROBLEM], in that response allows the server to provide more
   information about the error.

   This document defines a problem type of
   "https://iana.org/assignments/http-problem-types#date" for indicating
   that the Date request header field is missing or incorrect.  Figure 1
   shows an example response in HTTP/1.1 format.

   HTTP/1.1 400 Bad Request
   Date: Mon, 07 Feb 2022 00:28:05 GMT
   Content-Type: application/problem+json
   Content-Length: 128

   {"type":"https://iana.org/assignments/http-problem-types#date",
   "title": "date field in request outside of acceptable range"}

                         Figure 1: Example Response

   A server MUST include a Date response header field in any responses
   that use this problem detail type.

   In processing a Date header field in a request, a server MUST allow
   for delays in transmitting the request, retransmissions performed by
   transport protocols, plus any processing that might occur in the



Thomson                  Expires 13 August 2022                 [Page 4]


Internet-Draft                Date Requests                February 2022


   client and any intermediaries, and those parts of the server prior to
   processing the field.  Additionally, the Date header field is only
   capable of expressing time with a resolution of one second.  These
   factors could mean that the value a server receives could be some
   time in the past.

   Differences between client and server clocks are likely to be a
   source of most disagreements between the server time and the time
   expressed in Date request header field.  Section 5 will explore this
   problem in more detail and offer some means of handling these
   disagreements.

5.  Clock Skew

   Perfect synchronization of client and server clocks is an ideal state
   that generally only exists in tightly controlled settings.  In
   practice, despite good availability of time services like NTP [NTP]
   Internet-connected endpoints often disagree about the time (see for
   example Section 7.1 of [CLOCKSKEW]).

   The prevalence of clock skew could justify servers being more
   tolerant of a larger range of values for the Date request header
   field.  This includes accepting times that are a short duration into
   the future in addition to times in the past.

   For a server that uses the Date request header field to limit the
   state kept for anti-replay purposes, the amount of state might be all
   that determines the range of values it accepts.

5.1.  Date Correction

   Even when a server is tolerant of small clock errors, a valid request
   from a client can be rejected if the client clock is outside of the
   range of times that a server will accept.  A server might also reject
   a request when the client makes a request without a Date header
   field.

   A client can recover from a failure that caused by a bad clock by
   adjusting the time and re-attempting the request.

   For a fresh response (see Section 4.2 of [CACHING]), the client can
   re-attempt the request, copying the Date header field from the
   response into its new request.  If the response is stale, the client
   can add the age of the response to determine the time to use in a re-
   attempt; see Section 5.3 for more.






Thomson                  Expires 13 August 2022                 [Page 5]


Internet-Draft                Date Requests                February 2022


   In addition to adjusting for response age, the client can adjust the
   time it uses based on the elapsed time since it estimates when the
   response was generated.  Note however that if the client retries a
   request immediately, any additional increment is likely to be less
   than the one second resolution of the Date header field under most
   network conditions.

5.2.  Limitations of Date Correction

   Clients MUST NOT accept the time provided by an arbitrary HTTP server
   as the basis for system-wide time.  Even if the client code in
   question were able to set the time, altering the system clock in this
   way exposes clients to attack.  The source of system time information
   needs to be trustworthy as the current time is a critical input to
   security-relevant decisions, such as whether to accept a server
   certificate [RFC6125].

   Use of date correction allows requests that use the correction to be
   correlated.  Limitations on use of date corrections is necessary to
   ensure privacy.  An immediate retry of an identical request with an
   update Date header field is safe in that it only provides the server
   with the ability to match the retry to the original request.

   Anything other than an immediate retry requires careful consideration
   of the privacy implications.  Use of the same date correction for
   other requests can be used to link those requests to the same client.
   Using the same date correction is equivalent to connection reuse,
   cookies, TLS session tickets, or other state a client might carry
   between requests.  Linking requests might be acceptable, but in
   general only where other forms of linkage already exist.

   Clients MUST NOT use the time correction from one server when making
   requests of another server.  Using the same date correction across
   different servers might be used by servers to link client identities
   and to exchange information via a channel provided by the client.

   For clients that maintain per-server state, the specific date
   correction that is used for each server MUST be cleared when removing
   other state for that server to prevent re-identification.  For
   instance, a web browser that remembers a date correction would forget
   that correction when removing cookies and other state.










Thomson                  Expires 13 August 2022                 [Page 6]


Internet-Draft                Date Requests                February 2022


5.3.  Intermediaries and Date Corrections

   Some intermediaries, in particular those acting as reverse proxies or
   gateways, will rewrite the Date header field in responses.  This
   applies especially to responses served from cache, but this might
   also apply to those that are forwarded directly from an origin
   server.

   For responses that are forwarded by an intermediary, changes to the
   Date response header field will not change how the client corrects
   its clock.  Errors only occur if the clock at the intermediary
   differs significantly from the clock at the origin server or if the
   intermediary updates the Date response header field without also
   adjusting or removing the Age header field on a stale response.

   Servers that condition their responses on the Date header field
   SHOULD either ensure that intermediaries do not cache responses (by
   including a Cache-Control directive of no-store) or designate the
   response as conditional on the value of the Date request header field
   (by including the token "date" in a Vary header field).

6.  Security Considerations

   Including a Date header field in requests reveals information about
   the client clock.  This might be used to identify clients with
   vulnerability to attacks that depend on incorrect clocks.

   Section 5.2 contains a discussion of the security and privacy
   concerns associated with date correction.

7.  IANA Considerations

   IANA are requested to create a new entry in the "HTTP Problem Type"
   registry established by [PROBLEM].

   Type URI:  https://iana.org/assignments/http-problem-types#date

   Title:  Date Not Acceptable

   Recommended HTTP Status Code:  400

   Reference:  Section 4 of this document

8.  References

8.1.  Normative References





Thomson                  Expires 13 August 2022                 [Page 7]


Internet-Draft                Date Requests                February 2022


   [CACHING]  Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
              Caching", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-cache-19, 12 September 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              cache-19>.

   [PROBLEM]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
              for HTTP APIs", Work in Progress, Internet-Draft, draft-
              ietf-httpapi-rfc7807bis-01, 13 October 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
              rfc7807bis-01>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [CLOCKSKEW]
              Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
              Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
              "Where the Wild Warnings Are: Root Causes of Chrome HTTPS
              Certificate Errors", Proceedings of the 2017 ACM SIGSAC
              Conference on Computer and Communications Security,
              DOI 10.1145/3133956.3134007, October 2017,
              <https://doi.org/10.1145/3133956.3134007>.

   [HTTP]     Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
              Semantics", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-semantics-19, 12 September 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              semantics-19>.

   [NTP]      Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5905>.

   [OHTTP]    Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
              Progress, Internet-Draft, draft-ietf-ohai-ohttp-00, 25
              November 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ohai-ohttp-00>.




Thomson                  Expires 13 August 2022                 [Page 8]


Internet-Draft                Date Requests                February 2022


   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4303>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/rfc/rfc6125>.

   [SIGN]     Backman, A., Richer, J., and M. Sporny, "HTTP Message
              Signatures", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-message-signatures-08, 28 January 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              message-signatures-08>.

Acknowledgments

   This document is a result of discussions about how to provide anti-
   replay protection for OHTTP in which Mark Nottingham, Eric Rescorla,
   and Chris Wood were instrumental.

Author's Address

   Martin Thomson
   Mozilla

   Email: mt@lowentropy.net






















Thomson                  Expires 13 August 2022                 [Page 9]