Using The Date Header Field 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 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

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

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"}

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

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¶

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