Mozilla

mt@lowentropy.net

Cloudflare

caw@heapingbits.net

Security Oblivious HTTP Application Intermediation privacy proxy partitioning tunnel 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 .

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 () 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

• .  Introduction
• .  Overview
  • .  Applicability
  • .  Conventions and Definitions
• .  Key Configuration
  • .  Key Configuration Encoding
  • .  Key Configuration Media Type
• .  HPKE Encapsulation
  • .  Request Format
  • .  Response Format
  • .  Encapsulation of Requests
  • .  Encapsulation of Responses
  • .  Request and Response Media Types
  • .  Repurposing the Encapsulation Format
• .  HTTP Usage
  • .  Informational Responses
  • .  Errors
  • .  Signaling Key Configuration Problems
• .  Security Considerations
  • .  Client Responsibilities
  • .  Relay Responsibilities
    • .  Differential Treatment
    • .  Denial of Service
    • .  Traffic Analysis
  • .  Server Responsibilities
  • .  Key Management
  • .  Replay Attacks
    • .  Use of Date for Anti-replay
    • .  Correcting Clock Differences
  • .  Forward Secrecy
  • .  Post-Compromise Security
  • .  Client Clock Exposure
  • .  Media Type Security
  • . Separate Gateway and Target
• .  Privacy Considerations
• .  Operational and Deployment Considerations
  • .  Performance Overhead
  • .  Resource Mappings
  • .  Network Management
• .  IANA Considerations
  • .  application/ohttp-keys Media Type
  • .  message/ohttp-req Media Type
  • .  message/ohttp-res Media Type
  • .  Registration of "date" Problem Type
  • .  Registration of "ohttp-key" Problem Type
• . References
  • .  Normative References
  • .  Informative References
• .  Complete Example of a Request and Response
• Acknowledgments
• Authors' Addresses

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 using Hybrid Public Key Encryption (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 ), Clients are assured that requests are not uniquely attributed to them or linked to other requests.

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

Overview of Oblivious HTTP .------------------------------. +---------+ +----------+ | +----------+ +----------+ | | 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 ] | | | |<----------------+ | | | | | |

In order to forward a request for a Target Resource to the Oblivious Gateway Resource, the following steps occur, as shown in :

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

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 for more information. Many uses of HTTP benefit from being able to carry state between requests, such as with cookies , authentication (), or even alternative services . 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 or Tor , 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, describes operational constraints that are necessary to realize the goals of the protocol.

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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from 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 (), the term "HTTP client" is used; see .

Encapsulated Request:

An HTTP request that is encapsulated in an HPKE-encrypted message; see .

Encapsulated Response:

An HTTP response that is encapsulated in an HPKE-encrypted message; see .

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 . 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 encoding of a string s is indicated using the function encode_str(s). Formats are described using notation from . An extension to that notation expresses the number of bits in a field using a simple mathematical function.

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

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. shows a single key configuration.

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) ..., }

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 or the "HPKE KEM Identifiers" registry.

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 .

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 or the "HPKE KDF Identifiers" registry.

HPKE AEAD ID:

A 16-bit HPKE AEAD identifier as defined in or the "HPKE AEAD Identifiers" registry.

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

HPKE Encapsulation This document defines how a binary-encoded HTTP message is encapsulated using HPKE . Separate media types are defined to distinguish request and response messages:

• An Encapsulated Request format defined in is identified by the "message/ohttp-req" media type.
• An Encapsulated Response format defined in is identified by the "message/ohttp-res" media type.

Alternative encapsulations or message formats are indicated using the media type; see Sections and .

Request Format A message in "message/ohttp-req" format protects a binary HTTP request message; see .

Plaintext Request Structure Request { Binary HTTP Message (..), }

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 . describes the process for constructing and processing an Encapsulated Request.

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 (..), }

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 . The Encapsulated KEM Shared Secret is the output of the Encap() function for the KEM, which is Nenc bytes in length, as defined in .

Response Format A message in "message/ohttp-res" format protects a binary HTTP response message; see .

Plaintext Response Structure Response { Binary HTTP Message (..), }

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 . describes the process for constructing and processing an Encapsulated Response.

Encapsulated Response Encapsulated Response { Nonce (8 * max(Nn, Nk)), AEAD-Protected 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 or the "HPKE AEAD Identifiers" IANA registry. Nn and Nk refer to the size of the AEAD nonce and key, respectively, in bytes.

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 (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: discusses how alternative message formats might use a different info value.
3. Create a sending HPKE context by invoking SetupBaseS() () 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 () 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.
   1. If key_id does not identify a key matching the type of kem_id, the Oblivious Gateway Resource returns an error.
   2. 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() () with skR, enc, and info.
4. Decrypt ct by invoking the Open() method on rctxt (), 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.

Encapsulation of Responses Oblivious Gateway Resources generate an Encapsulated Response (enc_response) from a binary-encoded HTTP response (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 . 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: 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)

Request and Response Media Types Media types are used to identify Encapsulated Requests and Responses; see Sections and 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 ; see for guidance on reusing this encapsulation method. Alternatively, a new encapsulation method might be defined.

Repurposing the Encapsulation Format The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message . 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 . 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.

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 ), 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 . 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 ) 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 . 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 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 . 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 . An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see ). 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 . 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 ), 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 .

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

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 and of , 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.

Signaling Key Configuration Problems The problem type 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. shows an example response in HTTP/1.1 format.

Example Rejection of Key Configuration 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"}

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.

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.

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 . A formal analysis of Oblivious HTTP is in .

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. 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 . 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 () 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 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 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 . 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 . 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.

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

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 . A relay that acts on this feedback could -- either inadvertently or by design -- lead to Client deanonymization.

Denial of Service As there are privacy benefits from having a large rate of requests forwarded by the same relay (see ), 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.

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 . If the encapsulation method described in this document is used to protect a different message type (see ), 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 or ).

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

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 .

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 and ), 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 (), the HTTP/3 H3_REQUEST_REJECTED error code (), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred. 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 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 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.

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.

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 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. shows an example response in HTTP/1.1 format.

Example Rejection of Request Date Field 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"}

Disagreements about time are unlikely if both Client and Oblivious Gateway Resource have a good source of time; see . However, clock differences are known to be commonplace; see Section 7.1 of . 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 . When retrying a request, the Client MUST create a fresh encryption of the modified request, using a new HPKE context.

Retrying with an Updated Date Field +---------+ +-------------------+ +----------+ | Client | | Relay and Gateway | | Target | | | | Resources | | Resource | +----+----+ +----+-----------+--+ +----+-----+ | | | | | | | | | Request | | | +============================>+------------->| | | | | | | | 400 Response | | | | + Date | |<============================+<-------------+ | | | | | Request | | | | + Updated Date | | | +============================>+------------->| | | | |

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.

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.

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.

Client Clock Exposure Including a Date field in requests reveals some information about the Client clock. This might be used to fingerprint Clients 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.

Media Type Security The key configuration media type defined in represents keying material. The content of this media type is not active (see ), but it governs how a Client might interact with an Oblivious Gateway Resource. The security implications of processing it are described in ; privacy implications are described in . The security implications of handling the message media types defined in 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 . HTTP clients can also use resource identity and response content to determine how content is processed. Consequently, the security considerations of also apply to the handling of the content of these media types.

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

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. 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 , but it also includes any information in either message that might affect how subsequent requests are formulated. For example, 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.

Operational and Deployment Considerations This section discusses various operational and deployment considerations.

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 found that deploying proxies close to servers was most effective in minimizing additional latency.

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 , from which multiple Oblivious Relay Resources could be constructed.

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

IANA Considerations IANA has registered the following media types in the "Media Types" registry at , following the procedures of : "application/ohttp-keys" (), "message/ohttp-req" (), and "message/ohttp-res" (). IANA has added the following types to the "HTTP Problem Types" registry at : "date" () and "ohttp-key" ().

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

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

message/ohttp-req Media Type The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in .

Type name:

message

Subtype name:

ohttp-req

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

See

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

message/ohttp-res Media Type The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in .

Type name:

message

Subtype name:

ohttp-res

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

See

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

Registration of "date" Problem Type IANA has added a new entry in the "HTTP Problem Types" registry established by .

Type URI:

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

Title:

Date Not Acceptable

Recommended HTTP Status Code:

400

Reference:

of RFC 9458

Registration of "ohttp-key" Problem Type IANA has added a new entry in the "HTTP Problem Types" registry established by .

Type URI:

https://iana.org/assignments/http-problem-types#ohttp-key

Title:

Oblivious HTTP key configuration not acceptable

Recommended HTTP Status Code:

400

Reference:

of RFC 9458

References Normative References This document defines a binary format for representing HTTP messages. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document defines a "problem detail" to carry machine-readable details of erors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References Google Inc., Mountain View, CA, USA Google Inc., Mountain View, CA, USA Google Inc., Mountain View, CA, USA Leibniz University Hannover, Hannover, Germany Purdue University, West Lafayette, IN, USA International Institute of Information Technology, Hyderabad, Hyderabad, India Google Inc., Mountain View, CA, USA Google Inc., Mountain View, CA, USA Google Inc., Mountain View, CA, USA Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security Brave Software The Tor Project Mozilla Cloudflare This document describes the consistency requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It presents definitions for consistency and then surveys mechanisms for providing consistency in varying threat models. In concludes with discussion of open problems in this area. Work in Progress This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. PoPETS Proceedings Volume 2021, Issue 4, pp. 575-592 commit 6824eee Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] W3C TAG Finding This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

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 . 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 . , , and made technical contributions. The authors also thank , , and for invaluable assistance.

Authors' Addresses Mozilla

mt@lowentropy.net

Cloudflare

caw@heapingbits.net