doc: Add RFC documents

1 files changed, 2017 insertions, 0 deletions

diff --git a/doc/rfc/rfc9458.txt b/doc/rfc/rfc9458.txt
new file mode 100644
index 0000000..17f3292
--- /dev/null
+++ b/doc/rfc/rfc9458.txt
@@ -0,0 +1,2017 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Thomson
+Request for Comments: 9458                                       Mozilla
+Category: Standards Track                                     C. A. Wood
+ISSN: 2070-1721                                               Cloudflare
+                                                            January 2024
+
+
+                             Oblivious HTTP
+
+Abstract
+
+   This document describes Oblivious HTTP, a protocol for forwarding
+   encrypted HTTP messages.  Oblivious HTTP allows a client to make
+   multiple requests to an origin server without that server being able
+   to link those requests to the client or to identify the requests as
+   having come from the same client, while placing only limited trust in
+   the nodes used to forward the messages.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9458.
+
+Copyright Notice
+
+   Copyright (c) 2024 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.  Overview
+     2.1.  Applicability
+     2.2.  Conventions and Definitions
+   3.  Key Configuration
+     3.1.  Key Configuration Encoding
+     3.2.  Key Configuration Media Type
+   4.  HPKE Encapsulation
+     4.1.  Request Format
+     4.2.  Response Format
+     4.3.  Encapsulation of Requests
+     4.4.  Encapsulation of Responses
+     4.5.  Request and Response Media Types
+     4.6.  Repurposing the Encapsulation Format
+   5.  HTTP Usage
+     5.1.  Informational Responses
+     5.2.  Errors
+     5.3.  Signaling Key Configuration Problems
+   6.  Security Considerations
+     6.1.  Client Responsibilities
+     6.2.  Relay Responsibilities
+       6.2.1.  Differential Treatment
+       6.2.2.  Denial of Service
+       6.2.3.  Traffic Analysis
+     6.3.  Server Responsibilities
+     6.4.  Key Management
+     6.5.  Replay Attacks
+       6.5.1.  Use of Date for Anti-replay
+       6.5.2.  Correcting Clock Differences
+     6.6.  Forward Secrecy
+     6.7.  Post-Compromise Security
+     6.8.  Client Clock Exposure
+     6.9.  Media Type Security
+     6.10. Separate Gateway and Target
+   7.  Privacy Considerations
+   8.  Operational and Deployment Considerations
+     8.1.  Performance Overhead
+     8.2.  Resource Mappings
+     8.3.  Network Management
+   9.  IANA Considerations
+     9.1.  application/ohttp-keys Media Type
+     9.2.  message/ohttp-req Media Type
+     9.3.  message/ohttp-res Media Type
+     9.4.  Registration of "date" Problem Type
+     9.5.  Registration of "ohttp-key" Problem Type
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Complete Example of a Request and Response
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   HTTP requests reveal information about client identities to servers.
+   While the actual content of the request message is under the control
+   of the client, other information that is more difficult to control
+   can still be used to identify the client.
+
+   Even where an IP address is not directly associated with an
+   individual, the requests made from it can be correlated over time to
+   assemble a profile of client behavior.  In particular, connection
+   reuse improves performance but provides servers with the ability to
+   link requests that share a connection.
+
+   In particular, the source IP address of the underlying connection
+   reveals identifying information that the client has only limited
+   control over.  While client-configured HTTP proxies can provide a
+   degree of protection against IP address tracking, they present an
+   unfortunate trade-off: if they are used without TLS, the contents of
+   communication are revealed to the proxy; if they are used with TLS, a
+   new connection needs to be used for each request to ensure that the
+   origin server cannot use the connection as a way to correlate
+   requests, incurring significant performance overheads.
+
+   To overcome these limitations, this document defines Oblivious HTTP,
+   a protocol for encrypting and sending HTTP messages from a client to
+   a gateway.  This uses a trusted relay service in a manner that
+   mitigates the use of metadata such as IP address and connection
+   information for client identification, with reasonable performance
+   characteristics.  This document describes:
+
+   1.  an algorithm for encapsulating binary HTTP messages [BINARY]
+       using Hybrid Public Key Encryption (HPKE) [HPKE] to protect their
+       contents,
+
+   2.  a method for forwarding Encapsulated Requests between Clients and
+       an Oblivious Gateway Resource through a trusted Oblivious Relay
+       Resource using HTTP, and
+
+   3.  requirements for how the Oblivious Gateway Resource handles
+       Encapsulated Requests and produces Encapsulated Responses for the
+       Client.
+
+   The combination of encapsulation and relaying ensures that Oblivious
+   Gateway Resource never sees the Client's IP address and that the
+   Oblivious Relay Resource never sees plaintext HTTP message content.
+
+   Oblivious HTTP allows connection reuse between the Client and
+   Oblivious Relay Resource, as well as between that relay and the
+   Oblivious Gateway Resource, so this scheme represents a performance
+   improvement over using just one request in each connection.  With
+   limited trust placed in the Oblivious Relay Resource (see Section 6),
+   Clients are assured that requests are not uniquely attributed to them
+   or linked to other requests.
+
+2.  Overview
+
+   An Oblivious HTTP Client must initially know the following:
+
+   *  The identity of an Oblivious Gateway Resource.  This might include
+      some information about what Target Resources the Oblivious Gateway
+      Resource supports.
+
+   *  The details of an HPKE public key for the Oblivious Gateway
+      Resource, including an identifier for that key and the HPKE
+      algorithms that are used with that key.
+
+   *  The identity of an Oblivious Relay Resource that will accept relay
+      requests carrying an Encapsulated Request as its content and
+      forward the content in these requests to a particular Oblivious
+      Gateway Resource.  Oblivious HTTP uses a one-to-one mapping
+      between Oblivious Relay and Gateway Resources; see Section 8.2 for
+      more details.
+
+   This information allows the Client to send HTTP requests to the
+   Oblivious Gateway Resource for forwarding to a Target Resource.  The
+   Oblivious Gateway Resource does not learn the Client's IP address or
+   any other identifying information that might be revealed from the
+   Client at the transport layer, nor does the Oblivious Gateway
+   Resource learn which of the requests it receives are from the same
+   Client.
+
+                                       .------------------------------.
+   +---------+       +----------+     |  +----------+    +----------+  |
+   | Client  |       | Relay    |     |  | Gateway  |    | Target   |  |
+   |         |       | Resource |     |  | Resource |    | Resource |  |
+   +----+----+       +----+-----+     |  +-----+----+    +----+-----+  |
+        |                 |            `-------|--------------|-------'
+        | Relay           |                    |              |
+        | Request         |                    |              |
+        | [+ Encapsulated |                    |              |
+        |    Request ]    |                    |              |
+        +---------------->| Gateway            |              |
+        |                 | Request            |              |
+        |                 | [+ Encapsulated    |              |
+        |                 |    Request ]       |              |
+        |                 +------------------->| Request      |
+        |                 |                    +------------->|
+        |                 |                    |              |
+        |                 |                    |     Response |
+        |                 |            Gateway |<-------------+
+        |                 |           Response |              |
+        |                 |    [+ Encapsulated |              |
+        |                 |         Response ] |              |
+        |           Relay |<-------------------+              |
+        |        Response |                    |              |
+        | [+ Encapsulated |                    |              |
+        |      Response ] |                    |              |
+        |<----------------+                    |              |
+        |                 |                    |              |
+
+                    Figure 1: Overview of Oblivious HTTP
+
+   In order to forward a request for a Target Resource to the Oblivious
+   Gateway Resource, the following steps occur, as shown in Figure 1:
+
+   1.  The Client constructs an HTTP request for a Target Resource.
+
+   2.  The Client encodes the HTTP request in a binary HTTP message and
+       then encapsulates that message using HPKE and the process from
+       Section 4.3.
+
+   3.  The Client sends a POST request to the Oblivious Relay Resource
+       with the Encapsulated Request as the content of that message.
+
+   4.  The Oblivious Relay Resource forwards this request to the
+       Oblivious Gateway Resource.
+
+   5.  The Oblivious Gateway Resource receives this request and removes
+       the HPKE protection to obtain an HTTP request.
+
+   The Oblivious Gateway Resource then handles the HTTP request.  This
+   typically involves making an HTTP request using the content of the
+   Encapsulated Request.  Once the Oblivious Gateway Resource has an
+   HTTP response for this request, the following steps occur to return
+   this response to the Client:
+
+   1.  The Oblivious Gateway Resource encapsulates the HTTP response
+       following the process in Section 4.4 and sends this in response
+       to the request from the Oblivious Relay Resource.
+
+   2.  The Oblivious Relay Resource forwards this response to the
+       Client.
+
+   3.  The Client removes the encapsulation to obtain the response to
+       the original request.
+
+   This interaction provides authentication and confidentiality
+   protection between the Client and the Oblivious Gateway, but
+   importantly not between the Client and the Target Resource.  While
+   the Target Resource is a distinct HTTP resource from the Oblivious
+   Gateway Resource, they are both logically under the control of the
+   Oblivious Gateway, since the Oblivious Gateway Resource can
+   unilaterally dictate the responses returned from the Target Resource
+   to the Client.  This arrangement is shown in Figure 1.
+
+2.1.  Applicability
+
+   Oblivious HTTP has limited applicability.  Importantly, it requires
+   explicit support from a willing Oblivious Relay Resource and
+   Oblivious Gateway Resource, thereby limiting the use of Oblivious
+   HTTP for generic applications; see Section 6.3 for more information.
+
+   Many uses of HTTP benefit from being able to carry state between
+   requests, such as with cookies [COOKIES], authentication (Section 11
+   of [HTTP]), or even alternative services [RFC7838].  Oblivious HTTP
+   removes linkage at the transport layer, which is only useful for an
+   application that does not carry state between requests.
+
+   Oblivious HTTP is primarily useful where the privacy risks associated
+   with possible stateful treatment of requests are sufficiently large
+   that the cost of deploying this protocol can be justified.  Oblivious
+   HTTP is simpler and less costly than more robust systems, like Prio
+   [PRIO] or Tor [DMS2004], which can provide stronger guarantees at
+   higher operational costs.
+
+   Oblivious HTTP is more costly than a direct connection to a server.
+   Some costs, like those involved with connection setup, can be
+   amortized, but there are several ways in which Oblivious HTTP is more
+   expensive than a direct request:
+
+   *  Each request requires at least two regular HTTP requests, which
+      could increase latency.
+
+   *  Each request is expanded in size with additional HTTP fields,
+      encryption-related metadata, and Authenticated Encryption with
+      Associated Data (AEAD) expansion.
+
+   *  Deriving cryptographic keys and applying them for request and
+      response protection takes non-negligible computational resources.
+
+   Examples of where preventing the linking of requests might justify
+   these costs include:
+
+   DNS queries:  DNS queries made to a recursive resolver reveal
+      information about the requester, particularly if linked to other
+      queries.
+
+   Telemetry submission:  Applications that submit reports about their
+      usage to their developers might use Oblivious HTTP for some types
+      of moderately sensitive data.
+
+   These are examples of requests where there is information in a
+   request that -- if it were connected to the identity of the user --
+   might allow a server to learn something about that user even if the
+   identity of the user were pseudonymous.  Other examples include
+   submitting anonymous surveys, making search queries, or requesting
+   location-specific content (such as retrieving tiles of a map
+   display).
+
+   In addition to these limitations, Section 6 describes operational
+   constraints that are necessary to realize the goals of the protocol.
+
+2.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.
+
+   This document uses terminology from [HTTP] and defines several terms
+   as follows:
+
+   Client:
+      A Client originates Oblivious HTTP requests.  A Client is also an
+      HTTP client in two ways: for the Target Resource and for the
+      Oblivious Relay Resource.  However, when referring to the HTTP
+      definition of client (Section 3.3 of [HTTP]), the term "HTTP
+      client" is used; see Section 5.
+
+   Encapsulated Request:
+      An HTTP request that is encapsulated in an HPKE-encrypted message;
+      see Section 4.3.
+
+   Encapsulated Response:
+      An HTTP response that is encapsulated in an HPKE-encrypted
+      message; see Section 4.4.
+
+   Oblivious Relay Resource:
+      An intermediary that forwards Encapsulated Requests and Responses
+      between Clients and a single Oblivious Gateway Resource.  In
+      context, this can be referred to simply as a "relay".
+
+   Oblivious Gateway Resource:
+      A resource that can receive an Encapsulated Request, extract the
+      contents of that request, forward it to a Target Resource, receive
+      a response, encapsulate that response, and then return the
+      resulting Encapsulated Response.  In context, this can be referred
+      to simply as a "gateway".
+
+   Target Resource:
+      The resource that is the target of an Encapsulated Request.  This
+      resource logically handles only regular HTTP requests and
+      responses, so it might be ignorant of the use of Oblivious HTTP to
+      reach it.
+
+   This document includes pseudocode that uses the functions and
+   conventions defined in [HPKE].
+
+   Encoding an integer to a sequence of bytes in network byte order is
+   described using the function encode(n, v), where n is the number of
+   bytes and v is the integer value.  ASCII [ASCII] encoding of a string
+   s is indicated using the function encode_str(s).
+
+   Formats are described using notation from Section 1.3 of [QUIC].  An
+   extension to that notation expresses the number of bits in a field
+   using a simple mathematical function.
+
+3.  Key Configuration
+
+   A Client needs to acquire information about the key configuration of
+   the Oblivious Gateway Resource in order to send Encapsulated
+   Requests.  In order to ensure that Clients do not encapsulate
+   messages that other entities can intercept, the key configuration
+   MUST be authenticated and have integrity protection.
+
+   This document does not define how that acquisition occurs.  However,
+   in order to help facilitate interoperability, it does specify a
+   format for the keys.  This ensures that different Client
+   implementations can be configured in the same way and also enables
+   advertising key configurations in a consistent format.  This format
+   might be used, for example, with HTTPS, as part of a system for
+   configuring or discovering key configurations.  However, note that
+   such a system needs to consider the potential for key configuration
+   to be used to compromise Client privacy; see Section 7.
+
+   A Client might have multiple key configurations to select from when
+   encapsulating a request.  Clients are responsible for selecting a
+   preferred key configuration from those it supports.  Clients need to
+   consider both the Key Encapsulation Method (KEM) and the combinations
+   of the Key Derivation Function (KDF) and AEAD in this decision.
+
+3.1.  Key Configuration Encoding
+
+   A single key configuration consists of a key identifier, a public
+   key, an identifier for the KEM that the public key uses, and a set of
+   HPKE symmetric algorithms.  Each symmetric algorithm consists of an
+   identifier for a KDF and an identifier for an AEAD.
+
+   Figure 2 shows a single key configuration.
+
+   HPKE Symmetric Algorithms {
+     HPKE KDF ID (16),
+     HPKE AEAD ID (16),
+   }
+
+   Key Config {
+     Key Identifier (8),
+     HPKE KEM ID (16),
+     HPKE Public Key (Npk * 8),
+     HPKE Symmetric Algorithms Length (16) = 4..65532,
+     HPKE Symmetric Algorithms (32) ...,
+   }
+
+                    Figure 2: A Single Key Configuration
+
+   That is, a key configuration consists of the following fields:
+
+   Key Identifier:
+      An 8-bit value that identifies the key used by the Oblivious
+      Gateway Resource.
+
+   HPKE KEM ID:
+      A 16-bit value that identifies the KEM used for the identified key
+      as defined in Section 7.1 of [HPKE] or the "HPKE KEM Identifiers"
+      registry <https://www.iana.org/assignments/hpke>.
+
+   HPKE Public Key:
+      The public key used by the gateway.  The length of the public key
+      is Npk, which is determined by the choice of HPKE KEM as defined
+      in Section 4 of [HPKE].
+
+   HPKE Symmetric Algorithms Length:
+      A 16-bit integer in network byte order that encodes the length, in
+      bytes, of the HPKE Symmetric Algorithms field that follows.
+
+   HPKE Symmetric Algorithms:
+      One or more pairs of identifiers for the different combinations of
+      HPKE KDF and AEAD that the Oblivious Gateway Resource supports:
+
+      HPKE KDF ID:
+         A 16-bit HPKE KDF identifier as defined in Section 7.2 of
+         [HPKE] or the "HPKE KDF Identifiers" registry
+         <https://www.iana.org/assignments/hpke>.
+
+      HPKE AEAD ID:
+         A 16-bit HPKE AEAD identifier as defined in Section 7.3 of
+         [HPKE] or the "HPKE AEAD Identifiers" registry
+         <https://www.iana.org/assignments/hpke>.
+
+3.2.  Key Configuration Media Type
+
+   The "application/ohttp-keys" format is a media type that identifies a
+   serialized collection of key configurations.  The content of this
+   media type comprises one or more key configuration encodings (see
+   Section 3.1).  Each encoded configuration is prefixed with a 2-byte
+   integer in network byte order that indicates the length of the key
+   configuration in bytes.  The length-prefixed encodings are
+   concatenated to form a list.  See Section 9.1 for a definition of the
+   media type.
+
+   Evolution of the key configuration format is supported through the
+   definition of new formats that are identified by new media types.
+
+   A Client that receives an "application/ohttp-keys" object with
+   encoding errors might be able to recover one or more key
+   configurations.  Differences in how key configurations are recovered
+   might be exploited to segregate Clients, so Clients MUST discard
+   incorrectly encoded key configuration collections.
+
+4.  HPKE Encapsulation
+
+   This document defines how a binary-encoded HTTP message [BINARY] is
+   encapsulated using HPKE [HPKE].  Separate media types are defined to
+   distinguish request and response messages:
+
+   *  An Encapsulated Request format defined in Section 4.1 is
+      identified by the "message/ohttp-req" media type (Section 9.2).
+
+   *  An Encapsulated Response format defined in Section 4.2 is
+      identified by the "message/ohttp-res" media type (Section 9.3).
+
+   Alternative encapsulations or message formats are indicated using the
+   media type; see Sections 4.5 and 4.6.
+
+4.1.  Request Format
+
+   A message in "message/ohttp-req" format protects a binary HTTP
+   request message; see Figure 3.
+
+   Request {
+     Binary HTTP Message (..),
+   }
+
+                   Figure 3: Plaintext Request Structure
+
+   This plaintext Request structure is encapsulated into a message in
+   "message/ohttp-req" form by generating an Encapsulated Request.  An
+   Encapsulated Request comprises a key identifier; HPKE parameters for
+   the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or
+   enc); and an HPKE-protected binary HTTP request message.
+
+   An Encapsulated Request is shown in Figure 4.  Section 4.3 describes
+   the process for constructing and processing an Encapsulated Request.
+
+   Encapsulated Request {
+     Key Identifier (8),
+     HPKE KEM ID (16),
+     HPKE KDF ID (16),
+     HPKE AEAD ID (16),
+     Encapsulated KEM Shared Secret (8 * Nenc),
+     HPKE-Protected Request (..),
+   }
+
+                       Figure 4: Encapsulated Request
+
+   That is, an Encapsulated Request comprises a Key Identifier, an HPKE
+   KEM ID, an HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared
+   Secret, and an HPKE-Protected Request.  The Key Identifier, HPKE KEM
+   ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in Section 3.1.
+   The Encapsulated KEM Shared Secret is the output of the Encap()
+   function for the KEM, which is Nenc bytes in length, as defined in
+   Section 4 of [HPKE].
+
+4.2.  Response Format
+
+   A message in "message/ohttp-res" format protects a binary HTTP
+   response message; see Figure 5.
+
+   Response {
+     Binary HTTP Message (..),
+   }
+
+                   Figure 5: Plaintext Response Structure
+
+   This plaintext Response structure is encapsulated into a message in
+   "message/ohttp-res" form by generating an Encapsulated Response.  An
+   Encapsulated Response comprises a nonce and the AEAD-protected binary
+   HTTP response message.
+
+   An Encapsulated Response is shown in Figure 6.  Section 4.4 describes
+   the process for constructing and processing an Encapsulated Response.
+
+   Encapsulated Response {
+     Nonce (8 * max(Nn, Nk)),
+     AEAD-Protected Response (..),
+   }
+
+                      Figure 6: Encapsulated Response
+
+   That is, an Encapsulated Response contains a Nonce and an AEAD-
+   Protected Response.  The Nonce field is either Nn or Nk bytes long,
+   whichever is larger.  The Nn and Nk values correspond to parameters
+   of the AEAD used in HPKE, which is defined in Section 7.3 of [HPKE]
+   or the "HPKE AEAD Identifiers" IANA registry
+   <https://www.iana.org/assignments/hpke>.  Nn and Nk refer to the size
+   of the AEAD nonce and key, respectively, in bytes.
+
+4.3.  Encapsulation of Requests
+
+   Clients encapsulate a request, identified as request, using values
+   from a key configuration:
+
+   *  the key identifier from the configuration (key_id) with the
+      corresponding KEM identified by kem_id,
+
+   *  the public key from the configuration (pkR), and
+
+   *  a combination of KDF (identified by kdf_id) and AEAD (identified
+      by aead_id) that the Client selects from those in the key
+      configuration.
+
+   The Client then constructs an Encapsulated Request, enc_request, from
+   a binary-encoded HTTP request [BINARY] (request) as follows:
+
+   1.  Construct a message header (hdr) by concatenating the values of
+       key_id, kem_id, kdf_id, and aead_id as one 8-bit integer and
+       three 16-bit integers, respectively, each in network byte order.
+
+   2.  Build a sequence of bytes (info) by concatenating the ASCII-
+       encoded string "message/bhttp request", a zero byte, and the
+       header.  Note: Section 4.6 discusses how alternative message
+       formats might use a different info value.
+
+   3.  Create a sending HPKE context by invoking SetupBaseS()
+       (Section 5.1.1 of [HPKE]) with the public key of the receiver pkR
+       and info.  This yields the context sctxt and an encapsulation key
+       enc.
+
+   4.  Encrypt request by invoking the Seal() method on sctxt
+       (Section 5.2 of [HPKE]) with empty associated data aad, yielding
+       ciphertext ct.
+
+   5.  Concatenate the values of hdr, enc, and ct.  This yields an
+       Encapsulated Request (enc_request).
+
+   Note that enc is of fixed length, so there is no ambiguity in parsing
+   this structure.
+
+   In pseudocode, this procedure is as follows:
+
+   hdr = concat(encode(1, key_id),
+                encode(2, kem_id),
+                encode(2, kdf_id),
+                encode(2, aead_id))
+   info = concat(encode_str("message/bhttp request"),
+                 encode(1, 0),
+                 hdr)
+   enc, sctxt = SetupBaseS(pkR, info)
+   ct = sctxt.Seal("", request)
+   enc_request = concat(hdr, enc, ct)
+
+   An Oblivious Gateway Resource decrypts an Encapsulated Request by
+   reversing this process.  To decapsulate an Encapsulated Request,
+   enc_request:
+
+   1.  Parse enc_request into key_id, kem_id, kdf_id, aead_id, enc, and
+       ct (indicated using the function parse() in pseudocode).  The
+       Oblivious Gateway Resource is then able to find the HPKE private
+       key, skR, corresponding to key_id.
+
+       a.  If key_id does not identify a key matching the type of
+           kem_id, the Oblivious Gateway Resource returns an error.
+
+       b.  If kdf_id and aead_id identify a combination of KDF and AEAD
+           that the Oblivious Gateway Resource is unwilling to use with
+           skR, the Oblivious Gateway Resource returns an error.
+
+   2.  Build a sequence of bytes (info) by concatenating the ASCII-
+       encoded string "message/bhttp request"; a zero byte; key_id as an
+       8-bit integer; plus kem_id, kdf_id, and aead_id as three 16-bit
+       integers.
+
+   3.  Create a receiving HPKE context, rctxt, by invoking SetupBaseR()
+       (Section 5.1.1 of [HPKE]) with skR, enc, and info.
+
+   4.  Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
+       [HPKE]), with an empty associated data aad, yielding request or
+       an error on failure.  If decryption fails, the Oblivious Gateway
+       Resource returns an error.
+
+   In pseudocode, this procedure is as follows:
+
+   key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
+   info = concat(encode_str("message/bhttp request"),
+                 encode(1, 0),
+                 encode(1, key_id),
+                 encode(2, kem_id),
+                 encode(2, kdf_id),
+                 encode(2, aead_id))
+   rctxt = SetupBaseR(enc, skR, info)
+   request, error = rctxt.Open("", ct)
+
+   The Oblivious Gateway Resource retains the HPKE context, rctxt, so
+   that it can encapsulate a response.
+
+4.4.  Encapsulation of Responses
+
+   Oblivious Gateway Resources generate an Encapsulated Response
+   (enc_response) from a binary-encoded HTTP response [BINARY]
+   (response).  The Oblivious Gateway Resource uses the HPKE receiver
+   context (rctxt) as the HPKE context (context) as follows:
+
+   1.  Export a secret (secret) from context, using the string "message/
+       bhttp response" as the exporter_context parameter to
+       context.Export; see Section 5.3 of [HPKE].  The length of this
+       secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD
+       key and nonce that are associated with context.  Note:
+       Section 4.6 discusses how alternative message formats might use a
+       different context value.
+
+   2.  Generate a random value of length max(Nn, Nk) bytes, called
+       response_nonce.
+
+   3.  Extract a pseudorandom key (prk) using the Extract function
+       provided by the KDF algorithm associated with context.  The ikm
+       input to this function is secret; the salt input is the
+       concatenation of enc (from enc_request) and response_nonce.
+
+   4.  Use the Expand function provided by the same KDF to create an
+       AEAD key, key, of length Nk -- the length of the keys used by the
+       AEAD associated with context.  Generating aead_key uses a label
+       of "key".
+
+   5.  Use the same Expand function to create a nonce, nonce, of length
+       Nn -- the length of the nonce used by the AEAD.  Generating
+       aead_nonce uses a label of "nonce".
+
+   6.  Encrypt response, passing the AEAD function Seal the values of
+       aead_key, aead_nonce, an empty aad, and a pt input of response.
+       This yields ct.
+
+   7.  Concatenate response_nonce and ct, yielding an Encapsulated
+       Response, enc_response.  Note that response_nonce is of fixed
+       length, so there is no ambiguity in parsing either response_nonce
+       or ct.
+
+   In pseudocode, this procedure is as follows:
+
+   secret = context.Export("message/bhttp response", max(Nn, Nk))
+   response_nonce = random(max(Nn, Nk))
+   salt = concat(enc, response_nonce)
+   prk = Extract(salt, secret)
+   aead_key = Expand(prk, "key", Nk)
+   aead_nonce = Expand(prk, "nonce", Nn)
+   ct = Seal(aead_key, aead_nonce, "", response)
+   enc_response = concat(response_nonce, ct)
+
+   Clients decrypt an Encapsulated Response by reversing this process.
+   That is, Clients first parse enc_response into response_nonce and ct.
+   Then, they follow the same process to derive values for aead_key and
+   aead_nonce, using their sending HPKE context, sctxt, as the HPKE
+   context, context.
+
+   The Client uses these values to decrypt ct using the AEAD function
+   Open.  Decrypting might produce an error, as follows:
+
+   response, error = Open(aead_key, aead_nonce, "", ct)
+
+4.5.  Request and Response Media Types
+
+   Media types are used to identify Encapsulated Requests and Responses;
+   see Sections 9.2 and 9.3 for definitions of these media types.
+
+   Evolution of the format of Encapsulated Requests and Responses is
+   supported through the definition of new formats that are identified
+   by new media types.  New media types might be defined to use a
+   similar encapsulation with a different HTTP message format than in
+   [BINARY]; see Section 4.6 for guidance on reusing this encapsulation
+   method.  Alternatively, a new encapsulation method might be defined.
+
+4.6.  Repurposing the Encapsulation Format
+
+   The encrypted payload of an Oblivious HTTP request and response is a
+   binary HTTP message [BINARY].  The Client and Oblivious Gateway
+   Resource agree on this encrypted payload type by specifying the media
+   type "message/bhttp" in the HPKE info string and HPKE export context
+   string for request and response encryption, respectively.
+
+   Future specifications may repurpose the encapsulation mechanism
+   described in this document.  This requires that the specification
+   define a new media type.  The encapsulation process for that content
+   type can follow the same process, using new constant strings for the
+   HPKE info and exporter context inputs.
+
+   For example, a future specification might encapsulate DNS messages,
+   which use the "application/dns-message" media type [RFC8484].  In
+   creating a new, encrypted media types, specifications might define
+   the use of string "application/dns-message request" (plus a zero byte
+   and the header for the full value) for request encryption and the
+   string "application/dns-message response" for response encryption.
+
+5.  HTTP Usage
+
+   A Client interacts with the Oblivious Relay Resource by constructing
+   an Encapsulated Request.  This Encapsulated Request is included as
+   the content of a POST request to the Oblivious Relay Resource.  This
+   request only needs those fields necessary to carry the Encapsulated
+   Request: a method of POST, a target URI of the Oblivious Relay
+   Resource, a header field containing the content type (see
+   Section 9.2), and the Encapsulated Request as the request content.
+   In the request to the Oblivious Relay Resource, Clients MAY include
+   additional fields.  However, additional fields MUST be independent of
+   the Encapsulated Request and MUST be fields that the Oblivious Relay
+   Resource will remove before forwarding the Encapsulated Request
+   towards the target, such as the Connection or Proxy-Authorization
+   header fields [HTTP].
+
+   The Client role in this protocol acts as an HTTP client both with
+   respect to the Oblivious Relay Resource and the Target Resource.  The
+   request, which the Client makes to the Target Resource, diverges from
+   typical HTTP assumptions about the use of a connection (see
+   Section 3.3 of [HTTP]) in that the request and response are encrypted
+   rather than sent over a connection.  The Oblivious Relay Resource and
+   the Oblivious Gateway Resource also act as HTTP clients toward the
+   Oblivious Gateway Resource and Target Resource, respectively.
+
+   In order to achieve the privacy and security goals of the protocol, a
+   Client also needs to observe the guidance in Section 6.1.
+
+   The Oblivious Relay Resource interacts with the Oblivious Gateway
+   Resource as an HTTP client by constructing a request using the same
+   restrictions as the Client request, except that the target URI is the
+   Oblivious Gateway Resource.  The content of this request is copied
+   from the Client.  An Oblivious Relay Resource MAY reject requests
+   that are obviously invalid, such as a request with no content.  The
+   Oblivious Relay Resource MUST NOT add information to the request
+   without the Client being aware of the type of information that might
+   be added; see Section 6.2 for more information on relay
+   responsibilities.
+
+   When a response is received from the Oblivious Gateway Resource, the
+   Oblivious Relay Resource forwards the response according to the rules
+   of an HTTP proxy; see Section 7.6 of [HTTP].  In case of timeout or
+   error, the Oblivious Relay Resource can generate a response with an
+   appropriate status code.
+
+   In order to achieve the privacy and security goals of the protocol,
+   an Oblivious Relay Resource also needs to observe the guidance in
+   Section 6.2.
+
+   An Oblivious Gateway Resource acts as a gateway for requests to the
+   Target Resource (see Section 7.6 of [HTTP]).  The one exception is
+   that any information it might forward in a response MUST be
+   encapsulated, unless it is responding to errors that do not relate to
+   processing the contents of the Encapsulated Request; see Section 5.2.
+
+   An Oblivious Gateway Resource, if it receives any response from the
+   Target Resource, sends a single 200 response containing the
+   Encapsulated Response.  Like the request from the Client, this
+   response MUST only contain those fields necessary to carry the
+   Encapsulated Response: a 200 status code, a header field indicating
+   the content type, and the Encapsulated Response as the response
+   content.  As with requests, additional fields MAY be used to convey
+   information that does not reveal information about the Encapsulated
+   Response.
+
+   An Oblivious Gateway Resource that does not receive a response can
+   itself generate a response with an appropriate error status code
+   (such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which
+   is then encapsulated in the same way as a successful response.
+
+   In order to achieve the privacy and security goals of the protocol,
+   an Oblivious Gateway Resource also needs to observe the guidance in
+   Section 6.3.
+
+5.1.  Informational Responses
+
+   This encapsulation does not permit progressive processing of
+   responses.  Though the binary HTTP response format does support the
+   inclusion of informational (1xx) status codes, the AEAD encapsulation
+   cannot be removed until the entire message is received.
+
+   In particular, the Expect header field with 100-continue (see
+   Section 10.1.1 of [HTTP]) cannot be used.  Clients MUST NOT construct
+   a request that includes a 100-continue expectation; the Oblivious
+   Gateway Resource MUST generate an error if a 100-continue expectation
+   is received.
+
+5.2.  Errors
+
+   A server that receives an invalid message for any reason MUST
+   generate an HTTP response with a 4xx status code.
+
+   Errors detected by the Oblivious Relay Resource and errors detected
+   by the Oblivious Gateway Resource before removing protection
+   (including being unable to remove encapsulation for any reason)
+   result in the status code being sent without protection in response
+   to the POST request made to that resource.
+
+   Errors detected by the Oblivious Gateway Resource after successfully
+   removing encapsulation and errors detected by the Target Resource
+   MUST be sent in an Encapsulated Response.  This might be because the
+   Encapsulated Request is malformed or the Target Resource does not
+   produce a response.  In either case, the Oblivious Gateway Resource
+   can generate a response with an appropriate error status code (such
+   as 400 (Bad Request) or 504 (Gateway Timeout); see Sections 15.5.1
+   and 15.6.5 of [HTTP], respectively).  This response is encapsulated
+   in the same way as a successful response.
+
+   Errors in the encapsulation of requests mean that responses cannot be
+   encapsulated.  This includes cases where the key configuration is
+   incorrect or outdated.  The Oblivious Gateway Resource can generate
+   and send a response with a 4xx status code to the Oblivious Relay
+   Resource.  This response MAY be forwarded to the Client or treated by
+   the Oblivious Relay Resource as a failure.  If a Client receives a
+   response that is not an Encapsulated Response, this could indicate
+   that the Client configuration used to construct the request is
+   incorrect or out of date.
+
+5.3.  Signaling Key Configuration Problems
+
+   The problem type [PROBLEM] of "https://iana.org/assignments/http-
+   problem-types#ohttp-key" is defined in this section.  An Oblivious
+   Gateway Resource MAY use this problem type in a response to indicate
+   that an Encapsulated Request used an outdated or incorrect key
+   configuration.
+
+   Figure 7 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: 106
+
+   {"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
+   "title": "key identifier unknown"}
+
+              Figure 7: Example Rejection of Key Configuration
+
+   As this response cannot be encrypted, it might not reach the Client.
+   A Client cannot rely on the Oblivious Gateway Resource using this
+   problem type.  A Client might also be configured to disregard
+   responses that are not encapsulated on the basis that they might be
+   subject to observation or modification by an Oblivious Relay
+   Resource.  A Client might manage the risk of an outdated key
+   configuration using a heuristic approach whereby it periodically
+   refreshes its key configuration if it receives a response with an
+   error status code that has not been encapsulated.
+
+6.  Security Considerations
+
+   In this design, a Client wishes to make a request to an Oblivious
+   Gateway Resource that is forwarded to a Target Resource.  The Client
+   wishes to make this request without linking that request with either
+   of the following:
+
+   *  The identity at the network and transport layer of the Client
+      (that is, the Client IP address and TCP or UDP port number the
+      Client uses to create a connection).
+
+   *  Any other request the Client might have made in the past or might
+      make in the future.
+
+   In order to ensure this, the Client selects a relay (that serves the
+   Oblivious Relay Resource) that it trusts will protect this
+   information by forwarding the Encapsulated Request and Response
+   without passing it to the server (that serves the Oblivious Gateway
+   Resource).
+
+   In this section, a deployment where there are three entities is
+   considered:
+
+   *  A Client makes requests and receives responses.
+
+   *  A relay operates the Oblivious Relay Resource.
+
+   *  A server operates both the Oblivious Gateway Resource and the
+      Target Resource.
+
+   Section 6.10 discusses the security implications for a case where
+   different servers operate the Oblivious Gateway Resource and Target
+   Resource.
+
+   Requests from the Client to Oblivious Relay Resource and from
+   Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS
+   in order to provide unlinkability in the presence of a network
+   observer.
+
+   To achieve the stated privacy goals, the Oblivious Relay Resource
+   cannot be operated by the same entity as the Oblivious Gateway
+   Resource.  However, colocation of the Oblivious Gateway Resource and
+   Target Resource simplifies the interactions between those resources
+   without affecting Client privacy.
+
+   As a consequence of this configuration, Oblivious HTTP prevents
+   linkability described above.  Informally, this means:
+
+   1.  Requests and responses are known only to Clients and Oblivious
+       Gateway Resources.  In particular, the Oblivious Relay Resource
+       knows the origin and destination of an Encapsulated Request and
+       Response, yet it does not know the decrypted contents.  Likewise,
+       Oblivious Gateway Resources learn only the Oblivious Relay
+       Resource and the decrypted request.  No entity other than the
+       Client can see the plaintext request and response and can
+       attribute them to the Client.
+
+   2.  Oblivious Gateway Resources, and therefore Target Resources,
+       cannot link requests from the same Client in the absence of
+       unique per-Client keys.
+
+   Traffic analysis that might affect these properties is outside the
+   scope of this document; see Section 6.2.3.
+
+   A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].
+
+6.1.  Client Responsibilities
+
+   Because Clients do not authenticate the Target Resource when using
+   Oblivious HTTP, Clients MUST have some mechanism to authorize an
+   Oblivious Gateway Resource for use with a Target Resource.  One
+   possible means of authorization is an allowlist.  This ensures that
+   Oblivious Gateway Resources are not misused to forward traffic to
+   arbitrary Target Resources.  Section 6.3 describes similar
+   responsibilities that apply to Oblivious Gateway Resources.
+
+   Clients MUST ensure that the key configuration they select for
+   generating Encapsulated Requests is integrity protected and
+   authenticated so that it can be attributed to the Oblivious Gateway
+   Resource; see Section 3.
+
+   Since Clients connect directly to the Oblivious Relay Resource
+   instead of the Target Resource, application configurations wherein
+   Clients make policy decisions about target connections, e.g., to
+   apply certificate pinning, are incompatible with Oblivious HTTP.  In
+   such cases, alternative technologies such as HTTP CONNECT
+   (Section 9.3.6 of [HTTP]) can be used.  Applications could implement
+   related policies on key configurations and relay connections, though
+   these might not provide the same properties as policies enforced
+   directly on target connections.  Instead, when this difference is
+   relevant, applications can connect directly to the target at the cost
+   of either privacy or performance.
+
+   Clients cannot carry connection-level state between requests as they
+   only establish direct connections to the relay responsible for the
+   Oblivious Relay Resource.  However, the content of requests might be
+   used by a server to correlate requests.  Cookies [COOKIES] are the
+   most obvious feature that might be used to correlate requests, but
+   any identity information and authentication credentials might have
+   the same effect.  Clients also need to treat information learned from
+   responses with similar care when constructing subsequent requests,
+   which includes the identity of resources.
+
+   Clients MUST generate a new HPKE context for every request, using a
+   good source of entropy [RANDOM] for generating keys.  Key reuse not
+   only risks requests being linked but also could expose request and
+   response contents to the relay.
+
+   The request the Client sends to the Oblivious Relay Resource only
+   requires minimal information; see Section 5.  The request that
+   carries the Encapsulated Request and that is sent to the Oblivious
+   Relay Resource MUST NOT include identifying information unless the
+   Client can trust that this information is removed by the relay.  A
+   Client MAY include information only for the Oblivious Relay Resource
+   in header fields identified by the Connection header field if it
+   trusts the relay to remove these, as required by Section 7.6.1 of
+   [HTTP].  The Client needs to trust that the relay does not replicate
+   the source addressing information in the request it forwards.
+
+   Clients rely on the Oblivious Relay Resource to forward Encapsulated
+   Requests and Responses.  However, the relay can only refuse to
+   forward messages; it cannot inspect or modify the contents of
+   Encapsulated Requests or Responses.
+
+6.2.  Relay Responsibilities
+
+   The relay that serves the Oblivious Relay Resource has a very simple
+   function to perform.  For each request it receives, it makes a
+   request of the Oblivious Gateway Resource that includes the same
+   content.  When it receives a response, it sends a response to the
+   Client that includes the content of the response from the Oblivious
+   Gateway Resource.
+
+   When forwarding a request, the relay MUST follow the forwarding rules
+   in Section 7.6 of [HTTP].  A generic HTTP intermediary implementation
+   is suitable for the purposes of serving an Oblivious Relay Resource,
+   but additional care is needed to ensure that Client privacy is
+   maintained.
+
+   Firstly, a generic implementation will forward unknown fields.  For
+   Oblivious HTTP, an Oblivious Relay Resource SHOULD NOT forward
+   unknown fields.  Though Clients are not expected to include fields
+   that might contain identifying information, removing unknown fields
+   removes this privacy risk.
+
+   Secondly, generic implementations are often configured to augment
+   requests with information about the Client, such as the Via field or
+   the Forwarded field [FORWARDED].  A relay MUST NOT add information
+   when forwarding requests that might be used to identify Clients,
+   except for information that a Client is aware of; see Section 6.2.1.
+
+   Finally, a relay can also generate responses, though it is assumed to
+   not be able to examine the content of a request (other than to
+   observe the choice of key identifier, KDF, and AEAD); therefore, it
+   is also assumed that it cannot generate an Encapsulated Response.
+
+6.2.1.  Differential Treatment
+
+   A relay MAY add information to requests if the Client is aware of the
+   nature of the information that could be added.  Any addition MUST NOT
+   include information that uniquely and permanently identifies the
+   Client, including any pseudonymous identifier.  Information added by
+   the relay -- beyond what is already revealed through Encapsulated
+   Requests from Clients -- can reduce the size of the anonymity set of
+   Clients at a gateway.
+
+   A Client does not need to be aware of the exact value added for each
+   request but needs to know the range of possible values the relay
+   might use.  How a Client might learn about added information is not
+   defined in this document.
+
+   Moreover, relays MAY apply differential treatment to Clients that
+   engage in abusive behavior, e.g., by sending too many requests in
+   comparison to other Clients, or as a response to rate limits signaled
+   from the gateway.  Any such differential treatment can reveal
+   information to the gateway that would not be revealed otherwise and
+   therefore reduce the size of the anonymity set of Clients using a
+   gateway.  For example, if a relay chooses to rate limit or block an
+   abusive Client, this means that any Client requests that are not
+   treated this way are known to be non-abusive by the gateway.  Clients
+   need to consider the likelihood of such differential treatment and
+   the privacy risks when using a relay.
+
+   Some patterns of abuse cannot be detected without access to the
+   request that is made to the target.  This means that only the gateway
+   or the target is in a position to identify abuse.  A gateway MAY send
+   signals toward the relay to provide feedback about specific requests.
+   For example, a gateway could respond differently to requests it
+   cannot decapsulate, as mentioned in Section 5.2.  A relay that acts
+   on this feedback could -- either inadvertently or by design -- lead
+   to Client deanonymization.
+
+6.2.2.  Denial of Service
+
+   As there are privacy benefits from having a large rate of requests
+   forwarded by the same relay (see Section 6.2.3), servers that operate
+   the Oblivious Gateway Resource might need an arrangement with
+   Oblivious Relay Resources.  This arrangement might be necessary to
+   prevent having the large volume of requests being classified as an
+   attack by the server.
+
+   If a server accepts a larger volume of requests from a relay, it
+   needs to trust that the relay does not allow abusive levels of
+   request volumes from Clients.  That is, if a server allows requests
+   from the relay to be exempt from rate limits, the server might want
+   to ensure that the relay applies a rate-limiting policy that is
+   acceptable to the server.
+
+   Servers that enter into an agreement with a relay that enables a
+   higher request rate might choose to authenticate the relay to enable
+   the higher rate.
+
+6.2.3.  Traffic Analysis
+
+   Using HTTPS protects information about which resources are the
+   subject of request and prevents a network observer from being able to
+   trivially correlate messages on either side of a relay.  However,
+   using HTTPS does not prevent traffic analysis by such network
+   observers.
+
+   The time at which Encapsulated Request or Response messages are sent
+   can reveal information to a network observer.  Though messages
+   exchanged between the Oblivious Relay Resource and the Oblivious
+   Gateway Resource might be sent in a single connection, traffic
+   analysis could be used to match messages that are forwarded by the
+   relay.
+
+   A relay could, as part of its function, delay requests before
+   forwarding them.  Delays might increase the anonymity set into which
+   each request is attributed.  Any delay also increases the time that a
+   Client waits for a response, so delays SHOULD only be added with the
+   consent -- or at least awareness -- of Clients.
+
+   A relay that forwards large volumes of exchanges can provide better
+   privacy by providing larger sets of messages that need to be matched.
+
+   Traffic analysis is not restricted to network observers.  A malicious
+   Oblivious Relay Resource could use traffic analysis to learn
+   information about otherwise encrypted requests and responses relayed
+   between Clients and gateways.  An Oblivious Relay Resource terminates
+   TLS connections from Clients, so they see message boundaries.  This
+   privileged position allows for richer feature extraction from
+   encrypted data, which might improve traffic analysis.
+
+   Clients and Oblivious Gateway Resources can use padding to reduce the
+   effectiveness of traffic analysis.  Padding is a capability provided
+   by binary HTTP messages; see Section 3.8 of [BINARY].  If the
+   encapsulation method described in this document is used to protect a
+   different message type (see Section 4.6), that message format might
+   need to include padding support.  Oblivious Relay Resources can also
+   use padding for the same reason but need to operate at the HTTP layer
+   since they cannot manipulate binary HTTP messages; for example, see
+   Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]).
+
+6.3.  Server Responsibilities
+
+   The Oblivious Gateway Resource can be operated by a different entity
+   than the Target Resource.  However, this means that the Client needs
+   to trust the Oblivious Gateway Resource not to modify requests or
+   responses.  This analysis concerns itself with a deployment scenario
+   where a single server provides both the Oblivious Gateway Resource
+   and Target Resource.
+
+   A server that operates both Oblivious Gateway and Target Resources is
+   responsible for removing request encryption, generating a response to
+   the Encapsulated Request, and encrypting the response.
+
+   Servers should account for traffic analysis based on response size or
+   generation time.  Techniques such as padding or timing delays can
+   help protect against such attacks; see Section 6.2.3.
+
+   If separate entities provide the Oblivious Gateway Resource and
+   Target Resource, these entities might need an arrangement similar to
+   that between server and relay for managing denial of service; see
+   Section 6.2.2.  Moreover, the Oblivious Gateway Resource SHOULD have
+   some mechanism to ensure that the Oblivious Gateway Resource is not
+   misused as a relay for HTTP messages to an arbitrary Target Resource,
+   such as an allowlist.
+
+   Non-secure requests -- such as those with the "http" scheme as
+   opposed to the "https" scheme -- SHOULD NOT be used if the Oblivious
+   Gateway and Target Resources are not on the same origin.  If messages
+   are forwarded between these resources without the protections
+   afforded by HTTPS, they could be inspected or modified by a network
+   attacker.  Note that a request could be forwarded without protection
+   if the two resources share an origin.
+
+6.4.  Key Management
+
+   An Oblivious Gateway Resource needs to have a plan for replacing
+   keys.  This might include regular replacement of keys, which can be
+   assigned new key identifiers.  If an Oblivious Gateway Resource
+   receives a request that contains a key identifier that it does not
+   understand or that corresponds to a key that has been replaced, the
+   server can respond with an HTTP 422 (Unprocessable Content) status
+   code.
+
+   A server can also use a 422 status code if the server has a key that
+   corresponds to the key identifier, but the Encapsulated Request
+   cannot be successfully decrypted using the key.
+
+   A server MUST ensure that the HPKE keys it uses are not valid for any
+   other protocol that uses HPKE with the "message/bhttp request" label.
+   Designers of protocols that reuse this encryption format, especially
+   new versions of this protocol, can ensure key diversity by choosing a
+   different label in their use of HPKE.  The "message/bhttp response"
+   label was chosen for symmetry only as it provides key diversity only
+   within the HPKE context created using the "message/bhttp request"
+   label; see Section 4.6.
+
+6.5.  Replay Attacks
+
+   A server is responsible for either rejecting replayed requests or
+   ensuring that the effect of replays does not adversely affect Clients
+   or resources.
+
+   Encapsulated Requests can be copied and replayed by the Oblivious
+   Relay Resource.  The threat model for Oblivious HTTP allows the
+   possibility that an Oblivious Relay Resource might replay requests.
+   Furthermore, if a Client sends an Encapsulated Request in TLS early
+   data (see Section 8 of [TLS] and [RFC8470]), a network-based
+   adversary might be able to cause the request to be replayed.  In both
+   cases, the effect of a replay attack and the mitigations that might
+   be employed are similar to TLS early data.
+
+   It is the responsibility of the application that uses Oblivious HTTP
+   to either reject replayed requests or ensure that replayed requests
+   have no adverse effect on their operation.  This section describes
+   some approaches that are universally applicable and suggestions for
+   more targeted techniques.
+
+   A Client or Oblivious Relay Resource MUST NOT automatically attempt
+   to retry a failed request unless it receives a positive signal
+   indicating that the request was not processed or forwarded.  The
+   HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [HTTP/2]), the
+   HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [HTTP/3]), or a
+   GOAWAY frame with a low enough identifier (in either protocol
+   version) are all sufficient signals that no processing occurred.
+   HTTP/1.1 [HTTP/1.1] provides no equivalent signal.  Connection
+   failures or interruptions are not sufficient signals that no
+   processing occurred.
+
+   The anti-replay mechanisms described in Section 8 of [TLS] are
+   generally applicable to Oblivious HTTP requests.  The encapsulated
+   keying material (or enc) can be used in place of a nonce to uniquely
+   identify a request.  This value is a high-entropy value that is
+   freshly generated for every request, so two valid requests will have
+   different values with overwhelming probability.
+
+   The mechanism used in TLS for managing differences in Client and
+   server clocks cannot be used as it depends on being able to observe
+   previous interactions.  Oblivious HTTP explicitly prevents such
+   linkability.
+
+   The considerations in [RFC8470] as they relate to managing the risk
+   of replay also apply, though there is no option to delay the
+   processing of a request.
+
+   Limiting requests to those with safe methods might not be
+   satisfactory for some applications, particularly those that involve
+   the submission of data to a server.  The use of idempotent methods
+   might be of some use in managing replay risk, though it is important
+   to recognize that different idempotent requests can be combined to be
+   not idempotent.
+
+   Even without replay prevention, the server-chosen response_nonce
+   field ensures that responses have unique AEAD keys and nonces even
+   when requests are replayed.
+
+6.5.1.  Use of Date for Anti-replay
+
+   Clients SHOULD include a Date header field in Encapsulated Requests,
+   unless the Client has prior knowledge that indicates that the
+   Oblivious Gateway Resource does not use Date for anti-replay
+   purposes.
+
+   Though HTTP requests often do not include a Date header field, the
+   value of this field might be used by a server to limit the amount of
+   requests it needs to track if it needs to prevent replay attacks.
+
+   An Oblivious Gateway Resource can maintain state for requests for a
+   small window of time over which it wishes to accept requests.  The
+   Oblivious Gateway Resource can store all requests it processes within
+   this window.  Storing just the enc field of a request, which should
+   be unique to each request, is sufficient.  The Oblivious Gateway
+   Resource can reject any request that is the same as one that was
+   previously answered within that time window or if the Date header
+   field from the decrypted request is outside of the current time
+   window.
+
+   Oblivious Gateway Resources might need to allow for the time it takes
+   requests to arrive from the Client, with a time window that is large
+   enough to allow for differences in clocks.  Insufficient tolerance of
+   time differences could result in valid requests being unnecessarily
+   rejected.  Beyond allowing for multiple round-trip times -- to
+   account for retransmission -- network delays are unlikely to be
+   significant in determining the size of the window, unless all
+   potential Clients are known to have excellent timekeeping.  A
+   specific window size might need to be determined experimentally.
+
+   Oblivious Gateway Resources MUST NOT treat the time window as secret
+   information.  An attacker can actively probe with different values
+   for the Date field to determine the time window over which the server
+   will accept responses.
+
+6.5.2.  Correcting Clock Differences
+
+   An Oblivious Gateway Resource can reject requests that contain a Date
+   value that is outside of its active window with a 400 series status
+   code.  The problem type [PROBLEM] of "https://iana.org/assignments/
+   http-problem-types#date" is defined to allow the server to signal
+   that the Date value in the request was unacceptable.
+
+   Figure 8 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 8: Example Rejection of Request Date Field
+
+   Disagreements about time are unlikely if both Client and Oblivious
+   Gateway Resource have a good source of time; see [NTP].  However,
+   clock differences are known to be commonplace; see Section 7.1 of
+   [CLOCKSKEW].
+
+   Including a Date header field in the response allows the Client to
+   correct clock errors by retrying the same request using the value of
+   the Date field provided by the Oblivious Gateway Resource.  The value
+   of the Date field can be copied if the response is fresh, with an
+   adjustment based on the Age field otherwise; see Section 4.2 of
+   [HTTP-CACHING].  When retrying a request, the Client MUST create a
+   fresh encryption of the modified request, using a new HPKE context.
+
+   +---------+       +-------------------+      +----------+
+   | Client  |       | Relay and Gateway |      | Target   |
+   |         |       |     Resources     |      | Resource |
+   +----+----+       +----+-----------+--+      +----+-----+
+        |                 |           |              |
+        |                 |           |              |
+        |  Request        |           |              |
+        +============================>+------------->|
+        |                 |           |              |
+        |                 |           | 400 Response |
+        |                 |           |       + Date |
+        |<============================+<-------------+
+        |                 |           |              |
+        |  Request        |           |              |
+        |  + Updated Date |           |              |
+        +============================>+------------->|
+        |                 |           |              |
+
+               Figure 9: Retrying with an Updated Date Field
+
+   Retrying immediately allows the Oblivious Gateway Resource to measure
+   the round-trip time to the Client.  The observed delay might reveal
+   something about the location of the Client.  Clients could delay
+   retries to add some uncertainty to any observed delay.
+
+   Intermediaries can sometimes rewrite the Date field when forwarding
+   responses.  This might cause problems if the Oblivious Gateway
+   Resource and intermediary clocks differ by enough to cause the retry
+   to be rejected.  Therefore, Clients MUST NOT retry a request with an
+   adjusted date more than once.
+
+   Oblivious Gateway Resources 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).
+
+   Clients MUST NOT use the date provided by the Oblivious Gateway
+   Resource for any other purpose, including future requests to any
+   resource.  Any request that uses information provided by the
+   Oblivious Gateway Resource might be correlated using that
+   information.
+
+6.6.  Forward Secrecy
+
+   This document does not provide forward secrecy for either requests or
+   responses during the lifetime of the key configuration.  A measure of
+   forward secrecy can be provided by generating a new key configuration
+   then deleting the old keys after a suitable period.
+
+6.7.  Post-Compromise Security
+
+   This design does not provide post-compromise security for responses.
+
+   A Client only needs to retain keying material that might be used to
+   compromise the confidentiality and integrity of a response until that
+   response is consumed, so there is negligible risk associated with a
+   Client compromise.
+
+   A server retains a secret key that might be used to remove protection
+   from messages over much longer periods.  A server compromise that
+   provided access to the Oblivious Gateway Resource secret key could
+   allow an attacker to recover the plaintext of all requests sent
+   toward affected keys and all of the responses that were generated.
+
+   Even if server keys are compromised, an adversary cannot access
+   messages exchanged by the Client with the Oblivious Relay Resource as
+   messages are protected by TLS.  Use of a compromised key also
+   requires that the Oblivious Relay Resource cooperate with the
+   attacker or that the attacker is able to compromise these TLS
+   connections.
+
+   The total number of messages affected by server key compromise can be
+   limited by regular rotation of server keys.
+
+6.8.  Client Clock Exposure
+
+   Including a Date field in requests reveals some information about the
+   Client clock.  This might be used to fingerprint Clients [UWT] or to
+   identify Clients that are vulnerable to attacks that depend on
+   incorrect clocks.
+
+   Clients can randomize the value that they provide for Date to obscure
+   the true value of their clock and reduce the chance of linking
+   requests over time.  However, this increases the risk that their
+   request is rejected as outside the acceptable window.
+
+6.9.  Media Type Security
+
+   The key configuration media type defined in Section 3.2 represents
+   keying material.  The content of this media type is not active (see
+   Section 4.6 of [RFC6838]), but it governs how a Client might interact
+   with an Oblivious Gateway Resource.  The security implications of
+   processing it are described in Section 6.1; privacy implications are
+   described in Section 7.
+
+   The security implications of handling the message media types defined
+   in Section 4.5 is covered in other parts of this section in more
+   detail.  However, these message media types are also encrypted
+   encapsulations of HTTP requests and responses.
+
+   HTTP messages contain content, which can use any media type.  In
+   particular, requests are processed by an Oblivious Target Resource,
+   which -- as an HTTP resource -- defines how content is processed; see
+   Section 3.1 of [HTTP].  HTTP clients can also use resource identity
+   and response content to determine how content is processed.
+   Consequently, the security considerations of Section 17 of [HTTP]
+   also apply to the handling of the content of these media types.
+
+6.10.  Separate Gateway and Target
+
+   This document generally assumes that the same entity operates the
+   Oblivious Gateway Resource and the Target Resource.  However, as the
+   Oblivious Gateway Resource performs generic HTTP processing, the use
+   of forwarding cannot be completely precluded.
+
+   The scheme specified in the Encapsulated Request determines the
+   security requirements for any protocol that is used between the
+   Oblivious Gateway and Target Resources.  Using HTTPS is RECOMMENDED;
+   see Section 6.3.
+
+   A Target Resource that is operated on a different server from the
+   Oblivious Gateway Resource is an ordinary HTTP resource.  A Target
+   Resource can privilege requests that are forwarded by a given
+   Oblivious Gateway Resource if it trusts the operator of the Oblivious
+   Gateway Resource to only forward requests that meet the expectations
+   of the Target Resource.  Otherwise, the Target Resource treats
+   requests from an Oblivious Gateway Resource no differently than any
+   other HTTP client.
+
+   For instance, an Oblivious Gateway Resource might -- possibly with
+   the help of Oblivious Relay Resources -- be trusted not to forward an
+   excessive volume of requests.  This might allow the Target Resource
+   to accept a greater volume of requests from that Oblivious Gateway
+   Resource relative to other HTTP clients.
+
+   An Oblivious Gateway Resource could implement policies that improve
+   the ability of the Target Resource to implement policy exemptions,
+   such as only forwarding requests toward specific Target Resources
+   according to an allowlist; see Section 6.3.
+
+7.  Privacy Considerations
+
+   One goal of this design is that independent Client requests are only
+   linkable by their content.  However, the choice of Client
+   configuration might be used to correlate requests.  A Client
+   configuration includes the Oblivious Relay Resource URI, the
+   Oblivious Gateway key configuration, and the Oblivious Gateway
+   Resource URI.  A configuration is active if Clients can successfully
+   use it for interacting with a target.
+
+   Oblivious Relay and Gateway Resources can identify when requests use
+   the same configuration by matching the key identifier from the key
+   configuration or the Oblivious Gateway Resource URI.  The Oblivious
+   Gateway Resource might use the source address of requests to
+   correlate requests that use an Oblivious Relay Resource run by the
+   same operator.  If the Oblivious Gateway Resource is willing to use
+   trial decryption, requests can be further separated into smaller
+   groupings based on active configurations that clients use.
+
+   Each active Client configuration partitions the Client anonymity set.
+   In practice, it is infeasible to reduce the number of active
+   configurations to one.  Enabling diversity in choice of Oblivious
+   Relay Resource naturally increases the number of active
+   configurations.  More than one configuration might need to be active
+   to allow for key rotation and server maintenance.
+
+   Client privacy depends on having each configuration used by many
+   other Clients.  It is critical to prevent the use of unique Client
+   configurations, which might be used to track individual Clients, but
+   it is also important to avoid creating small groupings of Clients
+   that might weaken privacy protections.
+
+   A specific method for a Client to acquire configurations is not
+   included in this specification.  Applications using this design MUST
+   provide accommodations to mitigate tracking using Client
+   configurations.  [CONSISTENCY] provides options for ensuring that
+   Client configurations are consistent between Clients.
+
+   The content of requests or responses, if used in forming new
+   requests, can be used to correlate requests.  This includes obvious
+   methods of linking requests, like cookies [COOKIES], but it also
+   includes any information in either message that might affect how
+   subsequent requests are formulated.  For example, [FIELDING]
+   describes how interactions that are individually stateless can be
+   used to build a stateful system when a Client acts on the content of
+   a response.
+
+8.  Operational and Deployment Considerations
+
+   This section discusses various operational and deployment
+   considerations.
+
+8.1.  Performance Overhead
+
+   Using Oblivious HTTP adds both cryptographic overhead and latency to
+   requests relative to a simple HTTP request-response exchange.
+   Deploying relay services that are on path between Clients and servers
+   avoids adding significant additional delay due to network topology.
+   A study of a similar system [ODOH-PETS] found that deploying proxies
+   close to servers was most effective in minimizing additional latency.
+
+8.2.  Resource Mappings
+
+   This protocol assumes a fixed, one-to-one mapping between the
+   Oblivious Relay Resource and the Oblivious Gateway Resource.  This
+   means that any Encapsulated Request sent to the Oblivious Relay
+   Resource will always be forwarded to the Oblivious Gateway Resource.
+   This constraint was imposed to simplify relay configuration and
+   mitigate against the Oblivious Relay Resource being used as a generic
+   relay for unknown Oblivious Gateway Resources.  The relay will only
+   forward for Oblivious Gateway Resources that it has explicitly
+   configured and allowed.
+
+   It is possible for a server to be configured with multiple Oblivious
+   Relay Resources, each for a different Oblivious Gateway Resource as
+   needed.  If the goal is to support a large number of Oblivious
+   Gateway Resources, Clients might be provided with a URI template
+   [TEMPLATE], from which multiple Oblivious Relay Resources could be
+   constructed.
+
+8.3.  Network Management
+
+   Oblivious HTTP might be incompatible with network interception
+   regimes, such as those that rely on configuring Clients with trust
+   anchors and intercepting TLS connections.  While TLS might be
+   intercepted successfully, interception middlebox devices might not
+   receive updates that would allow Oblivious HTTP to be correctly
+   identified using the media types defined in Sections 9.2 and 9.3.
+
+   Oblivious HTTP has a simple key management design that is not
+   trivially altered to enable interception by intermediaries.  Clients
+   that are configured to enable interception might choose to disable
+   Oblivious HTTP in order to ensure that content is accessible to
+   middleboxes.
+
+9.  IANA Considerations
+
+   IANA has registered the following media types in the "Media Types"
+   registry at <https://iana.org/assignments/media-types>, following the
+   procedures of [RFC6838]: "application/ohttp-keys" (Section 9.1),
+   "message/ohttp-req" (Section 9.2), and "message/ohttp-res"
+   (Section 9.3).
+
+   IANA has added the following types to the "HTTP Problem Types"
+   registry at <https://iana.org/assignments/http-problem-types>: "date"
+   (Section 9.4) and "ohttp-key" (Section 9.5).
+
+9.1.  application/ohttp-keys Media Type
+
+   The "application/ohttp-keys" media type identifies a key
+   configuration used by Oblivious HTTP.
+
+   Type name:  application
+   Subtype name:  ohttp-keys
+   Required parameters:  N/A
+   Optional parameters:  N/A
+   Encoding considerations:  "binary"
+   Security considerations:  See Section 6.9
+   Interoperability considerations:  N/A
+   Published specification:  RFC 9458
+   Applications that use this media type:  This type identifies a key
+      configuration as used by Oblivious HTTP and applications that use
+      Oblivious HTTP.
+   Fragment identifier considerations:  N/A
+   Additional information:
+      Magic number(s):  N/A
+      Deprecated alias names for this type:  N/A
+      File extension(s):  N/A
+      Macintosh file type code(s):  N/A
+   Person and email address to contact for further information:
+      See Authors' Addresses section
+   Intended usage:  COMMON
+   Restrictions on usage:  N/A
+   Author:  See Authors' Addresses section
+   Change controller:  IETF
+
+9.2.  message/ohttp-req Media Type
+
+   The "message/ohttp-req" identifies an encrypted binary HTTP request.
+   This is a binary format that is defined in Section 4.3.
+
+   Type name:  message
+   Subtype name:  ohttp-req
+   Required parameters:  N/A
+   Optional parameters:  N/A
+   Encoding considerations:  "binary"
+   Security considerations:  See Section 6.9
+   Interoperability considerations:  N/A
+   Published specification:  RFC 9458
+   Applications that use this media type:  Oblivious HTTP and
+      applications that use Oblivious HTTP use this media type to
+      identify encapsulated binary HTTP requests.
+   Fragment identifier considerations:  N/A
+   Additional information:
+      Magic number(s):  N/A
+      Deprecated alias names for this type:  N/A
+      File extension(s):  N/A
+      Macintosh file type code(s):  N/A
+   Person and email address to contact for further information:
+      See Authors' Addresses section
+   Intended usage:  COMMON
+   Restrictions on usage:  N/A
+   Author:  See Authors' Addresses section
+   Change controller:  IETF
+
+9.3.  message/ohttp-res Media Type
+
+   The "message/ohttp-res" identifies an encrypted binary HTTP response.
+   This is a binary format that is defined in Section 4.4.
+
+   Type name:  message
+   Subtype name:  ohttp-res
+   Required parameters:  N/A
+   Optional parameters:  N/A
+   Encoding considerations:  "binary"
+   Security considerations:  See Section 6.9
+   Interoperability considerations:  N/A
+   Published specification:  RFC 9458
+   Applications that use this media type:  Oblivious HTTP and
+      applications that use Oblivious HTTP use this media type to
+      identify encapsulated binary HTTP responses.
+   Fragment identifier considerations:  N/A
+   Additional information:
+      Magic number(s):  N/A
+      Deprecated alias names for this type:  N/A
+      File extension(s):  N/A
+      Macintosh file type code(s):  N/A
+   Person and email address to contact for further information:
+      See Authors' Addresses section
+   Intended usage:  COMMON
+   Restrictions on usage:  N/A
+   Author:  See Authors' Addresses section
+   Change controller:  IETF
+
+9.4.  Registration of "date" Problem Type
+
+   IANA has added a new entry in the "HTTP Problem Types" 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 6.5.2 of RFC 9458
+
+9.5.  Registration of "ohttp-key" Problem Type
+
+   IANA has added a new entry in the "HTTP Problem Types" registry
+   established by [PROBLEM].
+
+   Type URI:  https://iana.org/assignments/http-problem-types#ohttp-key
+   Title:  Oblivious HTTP key configuration not acceptable
+   Recommended HTTP Status Code:  400
+   Reference:  Section 5.3 of RFC 9458
+
+10.  References
+
+10.1.  Normative References
+
+   [ASCII]    Cerf, V., "ASCII format for network interchange", STD 80,
+              RFC 20, DOI 10.17487/RFC0020, October 1969,
+              <https://www.rfc-editor.org/info/rfc20>.
+
+   [BINARY]   Thomson, M. and C. A. Wood, "Binary Representation of HTTP
+              Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
+              <https://www.rfc-editor.org/info/rfc9292>.
+
+   [HPKE]     Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
+              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
+              February 2022, <https://www.rfc-editor.org/info/rfc9180>.
+
+   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+   [HTTP-CACHING]
+              Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Caching", STD 98, RFC 9111,
+              DOI 10.17487/RFC9111, June 2022,
+              <https://www.rfc-editor.org/info/rfc9111>.
+
+   [PROBLEM]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
+              for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
+              <https://www.rfc-editor.org/info/rfc9457>.
+
+   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+              Multiplexed and Secure Transport", RFC 9000,
+              DOI 10.17487/RFC9000, May 2021,
+              <https://www.rfc-editor.org/info/rfc9000>.
+
+   [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/info/rfc2119>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <https://www.rfc-editor.org/info/rfc6838>.
+
+   [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/info/rfc8174>.
+
+   [RFC8470]  Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
+              Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
+              2018, <https://www.rfc-editor.org/info/rfc8470>.
+
+   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+10.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>.
+
+   [CONSISTENCY]
+              Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
+              "Key Consistency and Discovery", Work in Progress,
+              Internet-Draft, draft-ietf-privacypass-key-consistency-01,
+              10 July 2023, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-privacypass-key-consistency-01>.
+
+   [COOKIES]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
+              DOI 10.17487/RFC6265, April 2011,
+              <https://www.rfc-editor.org/info/rfc6265>.
+
+   [DMS2004]  Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
+              Second-Generation Onion Router", May 2004,
+              <https://svn.torproject.org/svn/projects/design-paper/tor-
+              design.html>.
+
+   [FIELDING] Fielding, R. T., "Architectural Styles and the Design of
+              Network-based Software Architectures", January 2000,
+              <https://www.ics.uci.edu/~fielding/pubs/dissertation/
+              fielding_dissertation.pdf>.
+
+   [FORWARDED]
+              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
+              RFC 7239, DOI 10.17487/RFC7239, June 2014,
+              <https://www.rfc-editor.org/info/rfc7239>.
+
+   [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
+              June 2022, <https://www.rfc-editor.org/info/rfc9112>.
+
+   [HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
+              DOI 10.17487/RFC9113, June 2022,
+              <https://www.rfc-editor.org/info/rfc9113>.
+
+   [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
+              June 2022, <https://www.rfc-editor.org/info/rfc9114>.
+
+   [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/info/rfc5905>.
+
+   [ODOH]     Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
+              Wood, "Oblivious DNS over HTTPS", RFC 9230,
+              DOI 10.17487/RFC9230, June 2022,
+              <https://www.rfc-editor.org/info/rfc9230>.
+
+   [ODOH-PETS]
+              Singanamalla, S., Chunhapanya, S., Hoyland, J., Vavruša,
+              M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan,
+              N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A
+              Practical Privacy Enhancement to DNS", PoPETS Proceedings
+              Volume 2021, Issue 4, pp. 575-592, DOI 10.2478/popets-
+              2021-0085, January 2021,
+              <https://www.petsymposium.org/2021/files/papers/issue4/
+              popets-2021-0085.pdf>.
+
+   [OHTTP-ANALYSIS]
+              Hoyland, J., "Tamarin Model of Oblivious HTTP", commit
+              6824eee, October 2022,
+              <https://github.com/cloudflare/ohttp-analysis>.
+
+   [PRIO]     Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
+              and Scalable Computation of Aggregate Statistics", March
+              2017, <https://crypto.stanford.edu/prio/paper.pdf>.
+
+   [RANDOM]   Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
+              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
+              April 2016, <https://www.rfc-editor.org/info/rfc7838>.
+
+   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
+              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
+              <https://www.rfc-editor.org/info/rfc8484>.
+
+   [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
+              and D. Orchard, "URI Template", RFC 6570,
+              DOI 10.17487/RFC6570, March 2012,
+              <https://www.rfc-editor.org/info/rfc6570>.
+
+   [UWT]      Nottingham, M., "Unsanctioned Web Tracking", W3C TAG
+              Finding, July 2015,
+              <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.
+
+   [X25519]   Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+              for Security", RFC 7748, DOI 10.17487/RFC7748, January
+              2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+Appendix A.  Complete Example of a Request and Response
+
+   A single request and response exchange is shown here.  Binary values
+   (key configuration, secret keys, the content of messages, and
+   intermediate values) are shown in hexadecimal.  The request and
+   response here are minimal; the purpose of this example is to show the
+   cryptographic operations.  In this example, the Client is configured
+   with the Oblivious Relay Resource URI of
+   https://proxy.example.org/request.example.net/proxy, and the proxy is
+   configured to map requests to this URI to the Oblivious Gateway
+   Resource URI https://example.com/oblivious/request.  The Target
+   Resource URI, i.e., the resource the Client ultimately wishes to
+   query, is https://example.com.
+
+   To begin the process, the Oblivious Gateway Resource generates a key
+   pair.  In this example, the server chooses DHKEM(X25519, HKDF-SHA256)
+   and generates an X25519 key pair [X25519].  The X25519 secret key is:
+
+   3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
+
+   The Oblivious Gateway Resource constructs a key configuration that
+   includes the corresponding public key as follows:
+
+   01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
+   79815500080001000100010003
+
+   This key configuration is somehow obtained by the Client.  Then, when
+   a Client wishes to send an HTTP GET request to the target
+   https://example.com, it constructs the following binary HTTP message:
+
+   00034745540568747470730b6578616d706c652e636f6d012f
+
+   The Client then reads the Oblivious Gateway Resource key
+   configuration and selects a mutually supported KDF and AEAD.  In this
+   example, the Client selects HKDF-SHA256 and AES-128-GCM.  The Client
+   then generates an HPKE sending context that uses the server public
+   key.  This context is constructed from the following ephemeral secret
+   key:
+
+   bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
+
+   The corresponding public key is:
+
+   4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
+
+   The context is created with an info parameter of:
+
+   6d6573736167652f626874747020726571756573740001002000010001
+
+   Applying the Seal operation from the HPKE context produces an
+   encrypted message, allowing the Client to construct the following
+   Encapsulated Request:
+
+   010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
+   9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
+   5e7d86b83dd440b2c0185204b4d63525
+
+   The Client then sends this to the Oblivious Relay Resource in a POST
+   request, which might look like the following HTTP/1.1 request:
+
+   POST /request.example.net/proxy HTTP/1.1
+   Host: proxy.example.org
+   Content-Type: message/ohttp-req
+   Content-Length: 78
+
+   <content is the Encapsulated Request above>
+
+   The Oblivious Relay Resource receives this request and forwards it to
+   the Oblivious Gateway Resource, which might look like:
+
+   POST /oblivious/request HTTP/1.1
+   Host: example.com
+   Content-Type: message/ohttp-req
+   Content-Length: 78
+
+   <content is the Encapsulated Request above>
+
+   The Oblivious Gateway Resource receives this request, selects the key
+   it generated previously using the key identifier from the message,
+   and decrypts the message.  As this request is directed to the same
+   server, the Oblivious Gateway Resource does not need to initiate an
+   HTTP request to the Target Resource.  The request can be served
+   directly by the Target Resource, which generates a minimal response
+   (consisting of just a 200 status code) as follows:
+
+   0140c8
+
+   The response is constructed by exporting a secret from the HPKE
+   context:
+
+   62d87a6ba569ee81014c2641f52bea36
+
+   The key derivation for the Encapsulated Response uses both the
+   encapsulated KEM key from the request and a randomly selected nonce.
+   This produces a salt of:
+
+   4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
+   c789e7151fcba46158ca84b04464910d
+
+   The salt and secret are both passed to the Extract function of the
+   selected KDF (HKDF-SHA256) to produce a pseudorandom key of:
+
+   979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
+
+   The pseudorandom key is used with the Expand function of the KDF and
+   an info field of "key" to produce a 16-byte key for the selected AEAD
+   (AES-128-GCM):
+
+   5d0172a080e428b16d298c4ea0db620d
+
+   With the same KDF and pseudorandom key, an info field of "nonce" is
+   used to generate a 12-byte nonce:
+
+   f6bf1aeb88d6df87007fa263
+
+   The AEAD Seal() function is then used to encrypt the response, which
+   is added to the randomized nonce value to produce the Encapsulated
+   Response:
+
+   c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
+   857fbd
+
+   The Oblivious Gateway Resource constructs a response with the same
+   content:
+
+   HTTP/1.1 200 OK
+   Date: Wed, 27 Jan 2021 04:45:07 GMT
+   Cache-Control: private, no-store
+   Content-Type: message/ohttp-res
+   Content-Length: 38
+
+   <content is the Encapsulated Response>
+
+   The same response might then be generated by the Oblivious Relay
+   Resource, which might change as little as the Date header.  The
+   Client is then able to use the HPKE context it created and the nonce
+   from the Encapsulated Response to construct the AEAD key and nonce
+   and decrypt the response.
+
+Acknowledgments
+
+   This design is based on a design for Oblivious DNS (queries) over
+   HTTPS (DoH), described in [ODOH].  David Benjamin, Mark Nottingham,
+   and Eric Rescorla made technical contributions.  The authors also
+   thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable
+   assistance.
+
+Authors' Addresses
+
+   Martin Thomson
+   Mozilla
+   Email: mt@lowentropy.net
+
+
+   Christopher A. Wood
+   Cloudflare
+   Email: caw@heapingbits.net