Oblivious HTTP Application Intermediation M. Thomson
Internet-Draft Mozilla
Intended status: Standards Track C.A. Wood
Expires: 19 August 2022 Cloudflare
15 February 2022
Oblivious HTTP
draft-ietf-ohai-ohttp-01
Abstract
This document describes a system for the forwarding of encrypted HTTP
messages. This allows a client to make multiple requests of a server
without the server being able to link those requests to the client or
to identify the requests as having come from the same client.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://ietf-wg-
ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/.
Discussion of this document takes place on the Oblivious HTTP
Application Intermediation Working Group mailing list
(mailto:ohai@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ohai/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-ohai/oblivious-http.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Thomson & Wood Expires 19 August 2022 [Page 1]
Internet-Draft Oblivious HTTP February 2022
This Internet-Draft will expire on 19 August 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8
4.2. Key Configuration Media Type . . . . . . . . . . . . . . 9
5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 10
5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 11
5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12
6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Informational Responses . . . . . . . . . . . . . . . . . 15
6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15
7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18
8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19
8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20
8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20
8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21
8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
8.4.1. Use of Date for Anti-Replay . . . . . . . . . . . . . 23
8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. Operational and Deployment Considerations . . . . . . . . . . 24
10.1. Performance Overhead . . . . . . . . . . . . . . . . . . 25
10.2. Resource Mappings . . . . . . . . . . . . . . . . . . . 25
10.3. Network Management . . . . . . . . . . . . . . . . . . . 25
Thomson & Wood Expires 19 August 2022 [Page 2]
Internet-Draft Oblivious HTTP February 2022
11. Repurposing the Encapsulation Format . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Complete Example of a Request and Response . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The act of making a request using HTTP reveals information about the
client identity to a server. Though the content of requests might
reveal information, that is information under the control of the
client. In comparison, the source address on the connection reveals
information that a client has only limited control over.
Even where an IP address is not directly attributed to an individual,
the use of an address over time can be used to correlate requests.
Servers are able to use this information to assemble profiles of
client behavior, from which they can make inferences about the people
involved. The use of persistent connections to make multiple
requests improves performance, but provides servers with additional
certainty about the identity of clients in a similar fashion.
Use of an HTTP proxy can provide a degree of protection against
servers correlating requests. Systems like virtual private networks
or the Tor network [Dingledine2004], provide other options for
clients.
Though the overhead imposed by these methods varies, the cost for
each request is significant. Preventing request linkability requires
that each request use a completely new TLS connection to the server.
At a minimum, this requires an additional round trip to the server in
addition to that required by the request. In addition to having high
latency, there are significant secondary costs, both in terms of the
number of additional bytes exchanged and the CPU cost of
cryptographic computations.
This document describes a method of encapsulation for binary HTTP
messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]).
This protects the content of both requests and responses and enables
a deployment architecture that can separate the identity of a
requester from the request.
Though this scheme requires that servers and proxies explicitly
support it, this design represents a performance improvement over
options that perform just one request in each connection. With
Thomson & Wood Expires 19 August 2022 [Page 3]
Internet-Draft Oblivious HTTP February 2022
limited trust placed in the proxy (see Section 8), clients are
assured that requests are not uniquely attributed to them or linked
to other requests.
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.
Encapsulated Request: An HTTP request that is encapsulated in an
HPKE-encrypted message; see Section 5.1.
Encapsulated Response: An HTTP response that is encapsulated in an
HPKE-encrypted message; see Section 5.2.
Oblivious Proxy Resource: An intermediary that forwards requests and
responses between clients and a single oblivious request resource.
Oblivious Request Resource: A resource that can receive an
encapsulated request, extract the contents of that request,
forward it to an oblivious target resource, receive a response,
encapsulate that response, then return that response.
Oblivious Target Resource: The resource that is the target of an
encapsulated request. This resource logically handles only
regular HTTP requests and responses and so might be ignorant of
the use of oblivious HTTP to reach it.
This draft 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. The function len() returns the
length of a sequence of bytes.
Formats are described using notation from Section 1.3 of [QUIC].
3. Overview
A client learns the following:
* The identity of an oblivious request resource. This might include
some information about oblivious target resources that the
oblivious request resource supports.
Thomson & Wood Expires 19 August 2022 [Page 4]
Internet-Draft Oblivious HTTP February 2022
* The details of an HPKE public key that the oblivious request
resource accepts, including an identifier for that key and the
HPKE algorithms that are used with that key.
* The identity of an oblivious proxy resource that will forward
encapsulated requests and responses to a single oblivious request
resource. See Section 10.2 for more information about the mapping
between oblivious proxy and oblivious request resources.
This information allows the client to make a request of an oblivious
target resource without that resource having only a limited ability
to correlate that request with the client IP or other requests that
the client might make to that server.
+---------+ +----------+ +----------+ +----------+
| Client | | Proxy | | Request | | Target |
| | | Resource | | Resource | | Resource |
+----+----+ +----+-----+ +----+-----+ +----+-----+
| | | |
| Encapsulated | | |
| Request | | |
+---------------->| Encapsulated | |
| | Request | |
| +----------------->| Request |
| | +-------------->|
| | | |
| | | Response |
| | Encapsulated |<--------------+
| | Response | |
| Encapsulated |<-----------------+ |
| Response | | |
|<----------------+ | |
| | | |
Figure 1: Overview of Oblivious HTTP
In order to make a request to an oblivious target resource, the
following steps occur, as shown in Figure 1:
1. The client constructs an HTTP request for an oblivious target
resource.
2. The client encodes the HTTP request in a binary HTTP message and
then encapsulates that message using HPKE and the process from
Section 5.1.
3. The client sends a POST request to the oblivious proxy resource
with the encapsulated request as the content of that message.
Thomson & Wood Expires 19 August 2022 [Page 5]
Internet-Draft Oblivious HTTP February 2022
4. The oblivious proxy resource forwards this request to the
oblivious request resource.
5. The oblivious request resource receives this request and removes
the HPKE protection to obtain an HTTP request.
6. The oblivious request resource makes an HTTP request that
includes the target URI, method, fields, and content of the
request it acquires.
7. The oblivious target resource answers this HTTP request with an
HTTP response.
8. The oblivious request resource encapsulates the HTTP response
following the process in Section 5.2 and sends this in response
to the request from the oblivious proxy resource.
9. The oblivious proxy resource forwards this response to the
client.
10. The client removes the encapsulation to obtain the response to
the original request.
3.1. Applicability
Oblivious HTTP has limited applicability. Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
([RFC6265]), authentication (Section 11 of [HTTP]), or even
alternative services ([RFC7838]). Oblivious HTTP seeks to prevent
this sort of linkage, which requires that applications not carry
state between requests.
Oblivious HTTP is primarily useful where privacy risks associated
with possible stateful treatment of requests are sufficiently
negative 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 ([Dingledine2004]), 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 oblivious request requires at least two regular HTTP
requests, which adds latency.
Thomson & Wood Expires 19 August 2022 [Page 6]
Internet-Draft Oblivious HTTP February 2022
* Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and 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 is pseudonymous. Other examples include the
submission of anonymous surveys, making search queries, or requesting
location-specific content (such as retrieving tiles of a map
display).
4. Key Configuration
A client needs to acquire information about the key configuration of
the oblivious request 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 describes the "application/ohttp-keys" media type; see
Section 4.2. This media type might be used, for example with HTTPS,
as part of a system for configuring or discovering key
configurations. Note however that such a system needs to consider
the potential for key configuration to be used to compromise client
privacy; see Section 9.
Specifying a format for expressing the information a client needs to
construct an encapsulated request ensures that different client
implementations can be configured in the same way. This also enables
advertising key configurations in a consistent format.
Thomson & Wood Expires 19 August 2022 [Page 7]
Internet-Draft Oblivious HTTP February 2022
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 key derivation function (KDF) and authenticated encryption with
associated data (AEAD) in this decision.
Evolution of the key configuration format is supported through the
definition of new formats that are identified by new media types.
4.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
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, KeyConfig, that is
expressed using the TLS syntax; see Section 3 of [TLS].
opaque HpkePublicKey[Npk];
uint16 HpkeKemId;
uint16 HpkeKdfId;
uint16 HpkeAeadId;
struct {
HpkeKdfId kdf_id;
HpkeAeadId aead_id;
} HpkeSymmetricAlgorithms;
struct {
uint8 key_id;
HpkeKemId kem_id;
HpkePublicKey public_key;
HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>;
} KeyConfig;
Figure 2: A Single Key Configuration
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF,
and AEAD respectively. The definitions for these identifiers and the
semantics of the algorithms they identify can be found in [HPKE].
The Npk parameter corresponding to the HpkeKdfId can be found in
[HPKE].
Thomson & Wood Expires 19 August 2022 [Page 8]
Internet-Draft Oblivious HTTP February 2022
4.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 4.1) that are concatenated.
Type name: application
Subtype name: ohttp-keys
Required parameters: N/A
Optional parameters: None
Encoding considerations: only "8bit" or "binary" is permitted
Security considerations: see Section 8
Interoperability considerations: N/A
Published specification: this specification
Applications that use this media type: N/A
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 Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IESG
Thomson & Wood Expires 19 August 2022 [Page 9]
Internet-Draft Oblivious HTTP February 2022
5. HPKE Encapsulation
HTTP message encapsulation uses HPKE for request and response
encryption.
An encapsulated HTTP request contains a binary-encoded HTTP message
[BINARY] and no other fields; see Figure 3.
Request {
Binary HTTP Message (..),
}
Figure 3: Plaintext Request Content
An Encapsulated Request is comprised of a length-prefixed key
identifier and a HPKE-protected request message. HPKE protection
includes an encapsulated KEM shared secret (or enc), plus the AEAD-
protected request message. An Encapsulated Request is shown in
Figure 4. Section 5.1 describes the process for constructing and
processing an Encapsulated Request.
Encapsulated Request {
Key Identifier (8),
KEM Identifier (16),
KDF Identifier (16),
AEAD Identifier (16),
Encapsulated KEM Shared Secret (8*Nenc),
AEAD-Protected Request (..),
}
Figure 4: Encapsulated Request
The Nenc parameter corresponding to the HpkeKdfId can be found in
Section 7.1 of [HPKE].
An encapsulated HTTP response includes a binary-encoded HTTP message
[BINARY] and no other content; see Figure 5.
Response {
Binary HTTP Message (..),
}
Figure 5: Plaintext Response Content
Responses are bound to responses and so consist only of AEAD-
protected content. Section 5.2 describes the process for
constructing and processing an Encapsulated Response.
Thomson & Wood Expires 19 August 2022 [Page 10]
Internet-Draft Oblivious HTTP February 2022
Encapsulated Response {
Nonce (Nk),
AEAD-Protected Response (..),
}
Figure 6: Encapsulated Response
The Nenc and Nk parameters corresponding to the HpkeKdfId can be
found in [HPKE]. Nenc refers to the size of the encapsulated KEM
shared secret, in bytes; Nk refers to the size of the AEAD key for
the HPKE ciphersuite, in bits.
5.1. Encapsulation of Requests
Clients encapsulate a request request using values from a key
configuration:
* the key identifier from the configuration, keyID, with the
corresponding KEM identified by kemID,
* the public key from the configuration, pkR, and
* a selected combination of KDF, identified by kdfID, and AEAD,
identified by aeadID.
The client then constructs an encapsulated request, enc_request, from
a binary encoded HTTP request, request, as follows:
1. Compute an HPKE context using pkR and a label of "message/bhttp
request", yielding context and encapsulation key enc.
2. Construct associated data, aad, by concatenating the values of
keyID, kemID, kdfID, and aeadID, as one 8-bit integer and three
16-bit integers, respectively, each in network byte order.
3. Encrypt (seal) request with aad as associated data using context,
yielding ciphertext ct.
4. Concatenate the values of aad, enc, and ct, yielding 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:
Thomson & Wood Expires 19 August 2022 [Page 11]
Internet-Draft Oblivious HTTP February 2022
enc, context = SetupBaseS(pkR, "message/bhttp request")
aad = concat(encode(1, keyID),
encode(2, kemID),
encode(2, kdfID),
encode(2, aeadID))
ct = context.Seal(aad, request)
enc_request = concat(aad, enc, ct)
Servers decrypt an Encapsulated Request by reversing this process.
Given an Encapsulated Request enc_request, a server:
1. Parses enc_request into keyID, kemID, kdfID, aeadID, enc, and ct
(indicated using the function parse() in pseudocode). The server
is then able to find the HPKE private key, skR, corresponding to
keyID.
a. If keyID does not identify a key matching the type of kemID,
the server returns an error.
b. If kdfID and aeadID identify a combination of KDF and AEAD
that the server is unwilling to use with skR, the server returns
an error.
2. Compute an HPKE context using skR, a label of "message/bhttp
request", and the encapsulated key enc, yielding context.
3. Construct additional associated data, aad, from keyID, kemID,
kdfID, and aeadID or as the first seven bytes of enc_request.
4. Decrypt ct using aad as associated data, yielding request or an
error on failure. If decryption fails, the server returns an
error.
In pseudocode, this procedure is as follows:
keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request)
aad = concat(encode(1, keyID),
encode(2, kemID),
encode(2, kdfID),
encode(2, aeadID))
context = SetupBaseR(enc, skR, "message/bhttp request")
request, error = context.Open(aad, ct)
5.2. Encapsulation of Responses
Given an HPKE context context, a request message request, and a
response response, servers generate an Encapsulated Response
enc_response as follows:
Thomson & Wood Expires 19 August 2022 [Page 12]
Internet-Draft Oblivious HTTP February 2022
1. Export a secret secret from context, using the string "message/
bhttp response" as context. The length of this secret is max(Nn,
Nk), where Nn and Nk are the length of AEAD key and nonce
associated with context.
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 extract an
AEAD key key, of length Nk - the length of the keys used by the
AEAD associated with context. Generating key uses a label of
"key".
5. Use the same Expand function to extract a nonce nonce of length
Nn - the length of the nonce used by the AEAD. Generating nonce
uses a label of "nonce".
6. Encrypt response, passing the AEAD function Seal the values of
key, nonce, empty aad, and a pt input of request, which 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", 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 Request by reversing this process.
That is, they first parse enc_response into response_nonce and ct.
They then follow the same process to derive values for aead_key and
aead_nonce.
Thomson & Wood Expires 19 August 2022 [Page 13]
Internet-Draft Oblivious HTTP February 2022
The client uses these values to decrypt ct using the Open function
provided by the AEAD. Decrypting might produce an error, as follows:
reponse, error = Open(aead_key, aead_nonce, "", ct)
6. HTTP Usage
A client interacts with the oblivious proxy resource by constructing
an encapsulated request. This encapsulated request is included as
the content of a POST request to the oblivious proxy resource. This
request MUST only contain those fields necessary to carry the
encapsulated request: a method of POST, a target URI of the oblivious
proxy resource, a header field containing the content type (see
(Section 7), and the encapsulated request as the request content.
Clients MAY include fields that do not reveal information about the
content of the request, such as Alt-Used [ALT-SVC], or information
that it trusts the oblivious proxy resource to remove, such as fields
that are listed in the Connection header field.
The oblivious proxy resource interacts with the oblivious request
resource by constructing a request using the same restrictions as the
client request, except that the target URI is the oblivious request
resource. The content of this request is copied from the client.
The oblivious proxy resource MUST NOT add information about the
client to this request.
When a response is received from the oblivious request resource, the
oblivious proxy resource forwards the response according to the rules
of an HTTP proxy; see Section 7.6 of [HTTP].
An oblivious request resource, if it receives any response from the
oblivious 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 request resource acts as a gateway for requests to the
oblivious target resource (see Section 7.6 of [HTTP]). The one
exception is that any information it might forward in a response MUST
be encapsulated, unless it is responding to errors it detects before
removing encapsulation of the request; see Section 6.2.
Thomson & Wood Expires 19 August 2022 [Page 14]
Internet-Draft Oblivious HTTP February 2022
6.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
request resource MUST generate an error if a 100-continue expectation
is received.
6.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 proxy resource and errors detected
by the oblivious request 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 request resource after successfully
removing encapsulation and errors detected by the oblivious target
resource MUST be sent in an encapsulated response.
7. Media Types
Media types are used to identify encapsulated requests and responses.
Evolution of the format of encapsulated requests and responses is
supported through the definition of new formats that are identified
by new media types.
7.1. message/ohttp-req Media Type
The "message/ohttp-req" identifies an encapsulated binary HTTP
request. This is a binary format that is defined in Section 5.1.
Type name: message
Subtype name: ohttp-req
Required parameters: N/A
Optional parameters: None
Thomson & Wood Expires 19 August 2022 [Page 15]
Internet-Draft Oblivious HTTP February 2022
Encoding considerations: only "8bit" or "binary" is permitted
Security considerations: see Section 8
Interoperability considerations: N/A
Published specification: this specification
Applications that use this media type: N/A
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 Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IESG
7.2. message/ohttp-res Media Type
The "message/ohttp-res" identifies an encapsulated binary HTTP
response. This is a binary format that is defined in Section 5.2.
Type name: message
Subtype name: ohttp-res
Required parameters: N/A
Optional parameters: None
Encoding considerations: only "8bit" or "binary" is permitted
Security considerations: see Section 8
Thomson & Wood Expires 19 August 2022 [Page 16]
Internet-Draft Oblivious HTTP February 2022
Interoperability considerations: N/A
Published specification: this specification
Applications that use this media type: N/A
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 Aut
hors' Addresses section
Intended usage: COMMON
Restrictions on usage: N/A
Author: see Authors' Addresses section
Change controller: IESG
8. Security Considerations
In this design, a client wishes to make a request of a server that is
authoritative for the oblivious target resource. The client wishes
to make this request without linking that request with either:
1. 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).
2. 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 proxy (that serves the
oblivious proxy resource) that it trusts will protect this
information by forwarding the encapsulated request and response
without passing the server (that serves the oblivious request
resource).
In this section, a deployment where there are three entities is
considered:
Thomson & Wood Expires 19 August 2022 [Page 17]
Internet-Draft Oblivious HTTP February 2022
* A client makes requests and receives responses
* A proxy operates the oblivious proxy resource
* A server operates both the oblivious request resource and the
oblivious target resource
To achieve the stated privacy goals, the oblivious proxy resource
cannot be operated by the same entity as the oblivious request
resource. However, colocation of the oblivious request resource and
oblivious 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 targets in
possession of the corresponding response encapsulation key and
HPKE keying material. In particular, the oblivious proxy knows
the origin and destination of an encapsulated request and
response, yet does not know the decapsulated contents. Likewise,
targets know only the oblivious request origin, i.e., the proxy,
and the decapsulated request. Only the client knows both the
plaintext request and response.
2. Targets cannot link requests from the same client in the absence
of unique per-client keys.
Traffic analysis that might affect these properties are outside the
scope of this document; see Section 8.2.2.
A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].
8.1. Client Responsibilities
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 request
resource; see Section 4.
Since clients connect directly to the proxy instead of the target,
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 proxy connections, though these might not provide
the same properties as policies enforced directly on target
Thomson & Wood Expires 19 August 2022 [Page 18]
Internet-Draft Oblivious HTTP February 2022
connections. When this difference is relevant, applications can
instead connect directly to the target at the cost of either privacy
or performance.
Clients MUST NOT include identifying information in the request that
is encapsulated. Identifying information includes cookies [COOKIES],
authentication credentials or tokens, and any information that might
reveal client-specific information such as account credentials.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the proxy responsible for the
oblivious proxy resource. However, clients need to ensure that they
construct requests without any information gained from previous
requests. Otherwise, the server might be able to use that
information to link requests. Cookies [COOKIES] are the most obvious
feature that MUST NOT be used by clients. However, clients need to
include all information learned from requests, which could include
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, reuse could expose request and
response contents to the proxy.
The request the client sends to the oblivious proxy resource only
requires minimal information; see Section 6. The request that
carries the encapsulated request and is sent to the oblivious proxy
resource MUST NOT include identifying information unless the client
ensures that this information is removed by the proxy. A client MAY
include information only for the oblivious proxy resource in header
fields identified by the Connection header field if it trusts the
proxy to remove these as required by Section 7.6.1 of [HTTP]. The
client needs to trust that the proxy does not replicate the source
addressing information in the request it forwards.
Clients rely on the oblivious proxy resource to forward encapsulated
requests and responses. However, the proxy can only refuse to
forward messages, it cannot inspect or modify the contents of
encapsulated requests or responses.
8.2. Proxy Responsibilities
The proxy that serves the oblivious proxy resource has a very simple
function to perform. For each request it receives, it makes a
request of the oblivious request 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
request resource. When generating a request, the proxy MUST follow
Thomson & Wood Expires 19 August 2022 [Page 19]
Internet-Draft Oblivious HTTP February 2022
the forwarding rules in Section 7.6 of [HTTP].
A proxy can also generate responses, though it assumed to not be able
to examine the content of a request (other than to observe the choice
of key identifier, KDF, and AEAD), so it is also assumed that it
cannot generate an encapsulated response.
A proxy MUST NOT add information about the client identity when
forwarding requests. This includes the Via field, the Forwarded
field [FORWARDED], and any similar information. A client does not
depend on the proxy using an authenticated and encrypted connection
to the oblivious request resource, only that information about the
client not be attached to forwarded requests.
8.2.1. Denial of Service
As there are privacy benefits from having a large rate of requests
forwarded by the same proxy (see Section 8.2.2), servers that operate
the oblivious request resource might need an arrangement with
proxies. 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 proxy, it
needs to trust that the proxy does not allow abusive levels of
request volumes from clients. That is, if a server allows requests
from the proxy to be exempt from rate limits, the server might want
to ensure that the proxy applies a rate limiting policy that is
acceptable to the server.
Servers that enter into an agreement with a proxy that enables a
higher request rate might choose to authenticate the proxy to enable
the higher rate.
8.2.2. Linkability Through Traffic Analysis
As the time at which encapsulated request or response messages are
sent can reveal information to a network observer. Though messages
exchanged between the oblivious proxy resource and the oblivious
request resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
proxy.
A proxy could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not be what some clients want.
Thomson & Wood Expires 19 August 2022 [Page 20]
Internet-Draft Oblivious HTTP February 2022
A proxy can use padding to reduce the effectiveness of traffic
analysis. Padding is a capability provided by binary HTTP messages;
see Section 3.8 of [BINARY].
A proxy that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched.
8.3. Server Responsibilities
A server that operates both oblivious request and oblivious target
resources is responsible for removing request encapsulation,
generating a response the encapsulated request, and encapsulating 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 8.2.2.
If separate entities provide the oblivious request resource and
oblivious target resource, these entities might need an arrangement
similar to that between server and proxy for managing denial of
service; see Section 8.2.1. It is also necessary to provide
confidentiality protection for the unprotected requests and
responses, plus protections for traffic analysis; see Section 8.2.2.
An oblivious request 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 request 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 encapsulation 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 11.
Thomson & Wood Expires 19 August 2022 [Page 21]
Internet-Draft Oblivious HTTP February 2022
A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect clients
or resources; see Section 8.4.
8.4. Replay Attacks
Encapsulated requests can be copied and replayed by the oblivious
proxy resource. The design of oblivious HTTP does not assume that
the oblivious proxy resource will not replay requests. In addition,
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.
A client or oblivious proxy 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 [RFC7540]), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]),
or a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred.
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.
Thomson & Wood Expires 19 August 2022 [Page 22]
Internet-Draft Oblivious HTTP February 2022
Even without replay prevention, the server-chosen response_nonce
field ensures that responses have unique AEAD keys and nonces even
when requests are replayed.
8.4.1. Use of Date for Anti-Replay
Clients SHOULD include a Date header field in encapsulated requests.
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 when preventing replays.
A server can maintain state for requests for a small window of time
over which it wishes to accept requests. The server then rejects
requests if the request is the same as one that was previously
answered within that time window. Servers can reject requests
outside of this window and signal that clients might retry with a
different Date header field; see Section 4 of [REQUEST-DATE].
Servers can identify duplicate requests using the encapsulation (enc)
value.
Servers SHOULD 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 the clock of clients and servers. How large a time
window is needed could depend on the population of clients that the
server needs to serve.
Servers MUST NOT treat the time window as secret information. An
attacker can actively probe the server with specially crafted request
timestamps to determine the time window over which the server will
accept responses.
[REQUEST-DATE] contains further considerations for the use of the
Date request header field. This includes the way in which clients
might correct for clock skew and the privacy considerations arising
from that usage. Servers that reject requests on the basis of the
Date request header field SHOULD implement the feedback mechanism in
Section 4 of [REQUEST-DATE] to support clock correction by clients.
8.5. 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
compromise the confidentiality and integrity of a response until that
response is consumed, so there is negligible risk associated with a
client compromise.
Thomson & Wood Expires 19 August 2022 [Page 23]
Internet-Draft Oblivious HTTP February 2022
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 request 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 proxy resource as
messages are protected by TLS. Use of a compromised key also
requires that the oblivious proxy resource cooperate with the
attacker or that the attacker is able to compromise these TLS
connections.
The total number of affected messages affected by server key
compromise can be limited by regular rotation of server keys.
9. Privacy Considerations
One goal of this design is that independent client requests are only
linkable by the chosen key configuration. The oblivious proxy and
request resources can link requests using the same key configuration
by matching KeyConfig.key_id, or, if the oblivious target resource is
willing to use trial decryption, a limited set of key configurations
that share an identifier. An oblivious proxy can link requests using
the public key corresponding to KeyConfig.key_id.
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients. A specific method for a client to acquire
key configurations is not included in this specification. Clients
need to consider these tracking vectors when choosing a discovery
method. Applications using this design should provide accommodations
to mitigate tracking using key configurations. [CONSISTENCY]
provides an analysis of the options for ensuring the key
configurations are consistent between different clients.
10. Operational and Deployment Considerations
This section discusses various operational and deployment
considerations.
Thomson & Wood Expires 19 August 2022 [Page 24]
Internet-Draft Oblivious HTTP February 2022
10.1. Performance Overhead
Using Oblivious HTTP adds both cryptographic and latency to requests
relative to a simple HTTP request-response exchange. Deploying proxy
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] found that deploying proxies close to servers
was most effective in minimizing additional latency.
10.2. Resource Mappings
This protocol assumes a fixed, one-to-one mapping between the
Oblivious Proxy Resource and the Oblivious Request Resource. This
means that any encapsulated request sent to the Oblivious Proxy
Resource will always be forwarded to the Oblivious Request Resource.
This constraint was imposed to simplify proxy configuration and
mitigate against the Oblivious Proxy Resource being used as a generic
proxy for unknown Oblivious Request Resources. The proxy will only
forward for Oblivious Request Resources that it has explicitly
configured and allowed.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.
10.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 middleboxes devices might not
receive updates that would allow Oblivious HTTP to be correctly
identified using the media types defined in Section 7.
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.
11. Repurposing the Encapsulation Format
The encapsulated payload of an OHTTP request and response is a binary
HTTP message [BINARY]. Client and target agree on this encapsulated
payload type by specifying the media type "message/bhttp" in the HPKE
encapsulation info string and HPKE export context string for request
and response encapsulation, respectively.
Thomson & Wood Expires 19 August 2022 [Page 25]
Internet-Draft Oblivious HTTP February 2022
Future specifications may repurpose the encapsulation mechanism
described in Section 5, provided that the content type of the
encapsulated payload is appropriately reflected in the HPKE info and
context strings. For example, if a future specification were to use
the encapsulation mechanism in this specification for DNS messages,
identified by the "application/dns-message" media type, then the HPKE
info string SHOULD be "application/dns-message request" for request
encapsulation, and the HPKE export context string should be
"application/dns-message response" for response encapsulation.
12. IANA Considerations
Please update the "Media Types" registry at
https://www.iana.org/assignments/media-types
(https://www.iana.org/assignments/media-types) with the registration
information in Section 7 for the media types "message/ohttp-req",
"message/ohttp-res", and "application/ohttp-keys".
13. References
13.1. Normative References
[BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", Work in Progress, Internet-Draft, draft-ietf-
httpbis-binary-message-01, 3 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
binary-message-01>.
[HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
"Hybrid Public Key Encryption", Work in Progress,
Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hpke-12>.
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-19>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
Thomson & Wood Expires 19 August 2022 [Page 26]
Internet-Draft Oblivious HTTP February 2022
quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
[REQUEST-DATE]
Thomson, M., "Using The Date Header Field In HTTP
Requests", Work in Progress, Internet-Draft, draft-
thomson-httpapi-date-requests-00, 8 February 2022,
<https://datatracker.ietf.org/doc/html/draft-thomson-
httpapi-date-requests-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
13.2. Informative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-wood-key-consistency-01, 19 August
2021, <https://datatracker.ietf.org/doc/html/draft-wood-
key-consistency-01>.
Thomson & Wood Expires 19 August 2022 [Page 27]
Internet-Draft Oblivious HTTP February 2022
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
[Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", August 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>.
[FORWARDED]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/rfc/rfc7239>.
[ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T.,
Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A.
Wood, "Oblivious DNS over HTTPS (ODoH): A Practical
Privacy Enhancement to DNS", 7 January 2021,
<https://www.petsymposium.org/2021/files/papers/issue4/
popets-2021-0085.pdf>.
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
Wood, "Oblivious DNS Over HTTPS", Work in Progress,
Internet-Draft, draft-pauly-dprive-oblivious-doh-10, 31
January 2022, <https://datatracker.ietf.org/doc/html/
draft-pauly-dprive-oblivious-doh-10>.
[OHTTP-ANALYSIS]
Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August
2021, <https://github.com/cloudflare/ohttp-analysis>.
[PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
and Scalable Computation of Aggregate Statistics", 14
March 2017, <https://crypto.stanford.edu/prio/paper.pdf>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
Thomson & Wood Expires 19 August 2022 [Page 28]
Internet-Draft Oblivious HTTP February 2022
[X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>.
Appendix A. Complete Example of a Request and Response
A single request and response exchange is shown here. Binary values
(key configuration, secret keys, the content of messages, and
intermediate values) are shown in hexadecimal. The request and
response here are absolutely minimal; the purpose of this example is
to show the cryptographic operations.
The oblivious request resource generates a key pair. In this example
the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519
key pair [X25519]. The X25519 secret key is:
b8f3cea0da634e6b8271f5b8f931d266decdd04c8e09b80cb9878ea90086ed4a
The oblivious request resource constructs a key configuration that
includes the corresponding public key as follows:
01002076eae6d5a6c1549a3343d31c0b9b9582470c72ca11607d47f005f8c16b
e3304a00080001000100010003
This key configuration is somehow obtained by the client. Then when
a client wishes to send an HTTP request of a GET request to
https://example.com, it constructs the following binary HTTP message:
00034745540568747470730b6578616d706c652e636f6d012f
The client then reads the oblivious request 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 context that uses the server public key. This
context is constructed from the following ephemeral public key:
25845c6ed6802abfd09628b5c677842b10dd53a3aad5775aa3c20cbae1c0cb65
The corresponding private key is:
88894d1fb4e76e215d9d9c87c44d9e0a6053c1c84c836a4106ea547344504658
Applying the Seal operation from the HPKE context produces an
encrypted message, allowing the client to construct the following
encapsulated request:
Thomson & Wood Expires 19 August 2022 [Page 29]
Internet-Draft Oblivious HTTP February 2022
010020000100012485c2eee03135aac82e572d51639b2e141102c431d544e346
0a0784a908b41b676943ae0b3ed8eff581ee8be5f47303a314de092e2e27e3f0
2a03b9357de1d414cadacabaa1621cf9
The client then sends this to the oblivious proxy 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 proxy resource receives this request and forwards it to
the oblivious request 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 oblivous request 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 request resource does not need to initiate an
HTTP request to the oblivious target resource. The request can be
served directly by the oblivious target resource, which generates a
minimal response (consisting of just a 200 status code) as follows:
0140c8
The response is constructed by extracting a secret from the HPKE
context:
50030a0eacaa9c020e60390c573c4f80
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:
2485c2eee03135aac82e572d51639b2e141102c431d544e3460a0784a908b41b
e29f9834fd61ffa27f494dfea94d9ed5
The salt and secret are both passed to the Extract function of the
selected KDF (HKDF-SHA256) to produce a pseudorandom key of:
Thomson & Wood Expires 19 August 2022 [Page 30]
Internet-Draft Oblivious HTTP February 2022
4fd8939221446411c785dc9dc51a196df43646a7791919248d0c7624c9410e5b
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):
a0cd40e2e68cd500bfd14275b290f337
With the same KDF and pseudorandom key, an info field of "nonce" is
used to generate a 12-byte nonce:
86883bbe97a380ec2fa656f7
The AEAD Seal function is then used to encrypt the response, which is
added to the randomized nonce value to produce the encapsulated
response:
e29f9834fd61ffa27f494dfea94d9ed543d89abe34977e7d6d5e1d8051e7b3ba
4ff234
The oblivious request resource then constructs a response:
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 proxy
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 DoH, described in
[ODOH]. David Benjamin and Eric Rescorla made technical
contributions.
Authors' Addresses
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Thomson & Wood Expires 19 August 2022 [Page 31]
Internet-Draft Oblivious HTTP February 2022
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net
Thomson & Wood Expires 19 August 2022 [Page 32]