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

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

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

HPKE AEAD ID:

A 16-bit HPKE AEAD identifier as defined in Section 7.3 of [HPKE] or the "HPKE AEAD Identifiers" registry.¶

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.1. Request Format

A message in "message/ohttp-req" format protects a binary HTTP request message; see Figure 3.¶

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

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

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

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

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

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

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

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

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