Oblivious HTTP
Extracted elements (33)
Oblivious HTTP uses a fixed one-to-one mapping between Oblivious Relay Resource and Oblivious Gateway Resource. This simplifies relay configuration and prevents the relay from being repurposed as a generic relay for arbitrary or unknown gateway resources. Multiple Relay Resources can be configured to support multiple gateways.
The HPKE info string uses the media type 'message/bhttp request' (plus a zero byte and the header) to bind request encryption to the specific protocol, ensuring HPKE keys cannot be reused across protocols. The 'message/bhttp response' label provides key diversity only within the HPKE context established by the request label.
The server-chosen response_nonce ensures that each Encapsulated Response uses unique AEAD keys and nonces even when requests are replayed, providing per-response freshness independent of client-side replay prevention mechanisms.
Oblivious HTTP is incompatible with stateful HTTP patterns such as cookies, HTTP authentication, and alternative services, because it removes transport-layer linkability between requests. It is only suitable for applications that do not carry state between requests.
Oblivious HTTP may be incompatible with network interception regimes that rely on trust anchors and TLS interception. Middlebox devices may not be updated to recognize the 'message/ohttp-req' and 'message/ohttp-res' media types, and the key management design is not trivially adapted to enable intermediary interception.
The encapsulation format can be repurposed for payload types other than binary HTTP by defining a new media type and using that type's string as the HPKE info and exporter context inputs instead of 'message/bhttp request'/'message/bhttp response'. For example, DNS messages could use 'application/dns-message request'.
A Client or Oblivious Relay Resource MUST NOT automatically retry a failed request unless it receives a positive signal (e.g., HTTP/2 REFUSED_STREAM, HTTP/3 H3_REQUEST_REJECTED, or GOAWAY with a low enough identifier) that the request was not processed.
A Client that receives an 'application/ohttp-keys' object with encoding errors MUST discard the entire incorrectly encoded key configuration collection; partial recovery could allow the collection to be used to segregate Clients.
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, preventing cross-protocol key reuse attacks. Protocol designers can achieve key diversity by choosing a different label.
Applications using Oblivious HTTP MUST provide accommodations to mitigate tracking using Client configurations, such as ensuring that key configurations are consistent between Clients to prevent unique per-client configurations from being used for tracking.
Clients MUST generate a new HPKE context for every request, using a good source of entropy for generating keys. Key reuse risks linking requests and could expose request and response contents to the relay.
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, because AEAD encapsulation cannot be removed until the entire message is received.
Clients MUST NOT use a Date value provided by the Oblivious Gateway Resource for any other purpose, including future requests to any resource, since doing so could be used to correlate requests.
Clients SHOULD include a Date header field in Encapsulated Requests to allow Oblivious Gateway Resources to use date-windowed anti-replay. This may be omitted if the Client has prior knowledge that the gateway does not use Date for anti-replay.
Errors detected by the Oblivious Gateway Resource after successfully removing encapsulation, and errors from the Target Resource, MUST be sent inside an Encapsulated Response. Only errors that occur before or during decapsulation may be sent unencrypted.
Oblivious Gateway Resources MUST NOT treat the anti-replay time window as secret information; an attacker can actively probe with different Date field values to determine the window over which the server accepts requests.
Requests from Client to Oblivious Relay Resource and from relay to Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.
The key configuration MUST be authenticated and have integrity protection so that it can be attributed to the Oblivious Gateway Resource; clients that rely on unauthenticated configurations risk encapsulating messages that other entities can intercept.
The Oblivious Relay Resource MUST NOT add information when forwarding requests that might be used to identify Clients, except for information that the Client is aware of. Generic implementations that augment requests with Via or Forwarded fields violate this requirement.
When retrying with an updated Date field after a clock-skew rejection, the Client MUST create a fresh encryption of the modified request using a new HPKE context, and MUST NOT retry a request with an adjusted date more than once.
Each distinct active Client configuration (relay URI, gateway key config, gateway URI) partitions the Client anonymity set. Using unique or small-group configurations could enable tracking of individual Clients. Preventing unique configurations and ensuring consistency across Clients is critical to privacy.
The content of requests or responses, if used in forming new requests, can be used to correlate those requests. Cookies, authentication credentials, and any information that affects subsequent request formulation (including resource identities) can all compromise privacy even when transport-layer linkability is removed.
Clients send Encapsulated Requests to the Oblivious Relay Resource via HTTP POST with content type 'message/ohttp-req'. The relay forwards the same content to the Oblivious Gateway Resource, which decapsulates and processes it, then returns the Encapsulated Response with content type 'message/ohttp-res'.
The 'application/ohttp-keys' format is a serialized collection of key configurations. Each encoded configuration is prefixed with a 2-byte network-byte-order length field; the length-prefixed encodings are concatenated into a list.
This document registers three IANA media types: 'application/ohttp-keys' (key configuration for Oblivious HTTP), 'message/ohttp-req' (encrypted binary HTTP request), and 'message/ohttp-res' (encrypted binary HTTP response). All are binary-encoded formats.
This document registers two entries in the IANA 'HTTP Problem Types' registry: 'https://iana.org/assignments/http-problem-types#date' (Date Not Acceptable, HTTP 400) used to signal an unacceptable Date field in an Encapsulated Request, and 'https://iana.org/assignments/http-problem-types#ohttp-key' (key configuration not acceptable, HTTP 400) for outdated or incorrect key configurations.
Encapsulated Requests can be replayed by the Oblivious Relay Resource, and TLS early data can enable network-level replay. The application is responsible for either rejecting replayed requests or ensuring they have no adverse effect. The enc value (HPKE encapsulated key) serves as a high-entropy per-request unique identifier suitable for replay detection.
Including a Date field in requests reveals information about the Client's clock, which may be used for fingerprinting or to identify Clients vulnerable to clock-based attacks. Clients can randomize the Date value to reduce linkability, at the cost of increased rejection risk.
Oblivious HTTP does not provide forward secrecy for requests or responses during the lifetime of the key configuration. A server key compromise gives an attacker access to plaintext of all past requests and responses encrypted under the affected keys. Regular key rotation limits exposure.
Traffic analysis can be used to correlate messages on either side of a relay even when HTTPS is used. The time at which Encapsulated Requests and Responses are sent can reveal information to a network observer or a malicious relay. Padding (via binary HTTP) and delays can reduce effectiveness.
A Key Configuration encodes: Key Identifier (8-bit), HPKE KEM ID (16-bit), HPKE Public Key (Npk * 8 bits, length determined by KEM), HPKE Symmetric Algorithms Length (16-bit), and one or more HPKE Symmetric Algorithms entries each comprising a KDF ID (16-bit) and AEAD ID (16-bit).
An Encapsulated Request comprises: Key Identifier (8 bits), HPKE KEM ID (16 bits), HPKE KDF ID (16 bits), HPKE AEAD ID (16 bits), Encapsulated KEM Shared Secret (8 * Nenc bits), and an HPKE-Protected Request of variable length.
An Encapsulated Response contains a Nonce field of length max(Nn, Nk) bytes (whichever of the AEAD nonce size and key size is larger) followed by an AEAD-Protected Response of variable length.