Using Dates and Times In HTTP Requests

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/.¶

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 19 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

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].¶

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. These apply to any use of timestamps in requests. A new type of problem report [PROBLEM] is defined in Section 4 for use in rejecting requests with a missing or incorrect timestamps in requests.¶

Section 5 explores the consequences of using timestamps 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. Dates or Timestamps 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.¶

OHTTP [OHTTP] is an 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.¶

Signed HTTP requests [SIGN] and JSON Web Tokens [JWT] are other examples of where requests - or parts of requests - might be protected to prevent certain attacks by intermediaries. Signatures are often used to enhance protections for requests for privileged action on resources. Adding a Date header field or some other field (created for [SIGN] or iat for [JWT]) and signing that information can ensure that the request cannot be captured and used at a very different time to what was intended.¶

The inclusion of a timestamp might only be used to limit the period over which information might be used. It might be acceptable for the same request to be made multiple times over a fixed period.¶

In other cases, the inclusion of a date or timestamp might be part of an anti-replay strategy at a server. A simple anti-replay scheme detects replayed or duplicate requests by remembering accepted requests (or some part of a request that is unique such as a nonce, signature, or other unique value). Over longer periods of time, this approach could require an unbounded amount of state, so a simple technique limits the stored data to a small window of time. Requests are required to include a timestamp. A new request is rejected either if it contains a timestamp that is outside the window or if it matches a previously accepted request. The window tracks the current time, so when requests with timestamps leave the window they can be forgotten. 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 or other timestamp that is either absent or 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 a timestamp 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"}

A server MUST include a Date response header field in any responses that use this problem detail type. This allows the client to learn what the server believes to be a correct time, which might allow for correction; see Section 5.1.¶

In processing a Date header field or timestamp 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 client and any intermediaries and any server processing prior to generating the response. 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 timestamps in requests to limit the state kept for anti-replay purposes, the amount of state might be all that determines the range of values it accepts.¶

6. Security Considerations

Including a timestamp in requests reveals information about the client clock. This might be used to fingerprint clients [UWT] or to identify clients with vulnerability to attacks that depend on incorrect clocks.¶

Clients can randomize the value that they provide the server to obscure the true value of their clock and prevent linking of requests over time. However, this increases the risk that a server will reject a request due to it being unacceptable.¶

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¶

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