rfc9458v1.txt   rfc9458.txt 
skipping to change at line 114 skipping to change at line 114
HTTP requests reveal information about client identities to servers. HTTP requests reveal information about client identities to servers.
While the actual content of the request message is under the control While the actual content of the request message is under the control
of the client, other information that is more difficult to control of the client, other information that is more difficult to control
can still be used to identify the client. can still be used to identify the client.
Even where an IP address is not directly associated with an Even where an IP address is not directly associated with an
individual, the requests made from it can be correlated over time to individual, the requests made from it can be correlated over time to
assemble a profile of client behavior. In particular, connection assemble a profile of client behavior. In particular, connection
reuse improves performance but provides servers with the ability to reuse improves performance but provides servers with the ability to
correlate requests that share a connection. link requests that share a connection.
In particular, the source IP address of the underlying connection In particular, the source IP address of the underlying connection
reveals identifying information that the client has only limited reveals identifying information that the client has only limited
control over. While client-configured HTTP proxies can provide a control over. While client-configured HTTP proxies can provide a
degree of protection against IP address tracking, they present an degree of protection against IP address tracking, they present an
unfortunate trade-off: if they are used without TLS, the contents of unfortunate trade-off: if they are used without TLS, the contents of
communication are revealed to the proxy; if they are used with TLS, a communication are revealed to the proxy; if they are used with TLS, a
new connection needs to be used for each request to ensure that the new connection needs to be used for each request to ensure that the
origin server cannot use the connection as a way to correlate origin server cannot use the connection as a way to correlate
requests, incurring significant performance overheads. requests, incurring significant performance overheads.
skipping to change at line 137 skipping to change at line 137
a protocol for encrypting and sending HTTP messages from a client to a protocol for encrypting and sending HTTP messages from a client to
a gateway. This uses a trusted relay service in a manner that a gateway. This uses a trusted relay service in a manner that
mitigates the use of metadata such as IP address and connection mitigates the use of metadata such as IP address and connection
information for client identification, with reasonable performance information for client identification, with reasonable performance
characteristics. This document describes: characteristics. This document describes:
1. an algorithm for encapsulating binary HTTP messages [BINARY] 1. an algorithm for encapsulating binary HTTP messages [BINARY]
using Hybrid Public Key Encryption (HPKE) [HPKE] to protect their using Hybrid Public Key Encryption (HPKE) [HPKE] to protect their
contents, contents,
2. a method for forwarding these encapsulated messages between 2. a method for forwarding Encapsulated Requests between Clients and
clients and an Oblivious Gateway Resource through a trusted an Oblivious Gateway Resource through a trusted Oblivious Relay
Oblivious Relay Resource using HTTP, and Resource using HTTP, and
3. requirements for how the Oblivious Gateway Resource handles 3. requirements for how the Oblivious Gateway Resource handles
encapsulated HTTP messages and produces Encapsulated Responses Encapsulated Requests and produces Encapsulated Responses for the
for the client. Client.
The combination of encapsulation and relaying ensures that Oblivious The combination of encapsulation and relaying ensures that Oblivious
Gateway Resource never sees the client's IP address and that the Gateway Resource never sees the Client's IP address and that the
Oblivious Relay Resource never sees plaintext HTTP message content. Oblivious Relay Resource never sees plaintext HTTP message content.
Oblivious HTTP allows connection reuse between the client and Oblivious HTTP allows connection reuse between the Client and
Oblivious Relay Resource, as well as between that relay and the Oblivious Relay Resource, as well as between that relay and the
Oblivious Gateway Resource, so this scheme represents a performance Oblivious Gateway Resource, so this scheme represents a performance
improvement over using just one request in each connection. With improvement over using just one request in each connection. With
limited trust placed in the Oblivious Relay Resource (see Section 6), limited trust placed in the Oblivious Relay Resource (see Section 6),
Clients are assured that requests are not uniquely attributed to them Clients are assured that requests are not uniquely attributed to them
or linked to other requests. or linked to other requests.
2. Overview 2. Overview
An Oblivious HTTP Client must initially know the following: An Oblivious HTTP Client must initially know the following:
skipping to change at line 178 skipping to change at line 178
* The identity of an Oblivious Relay Resource that will accept relay * The identity of an Oblivious Relay Resource that will accept relay
requests carrying an Encapsulated Request as its content and requests carrying an Encapsulated Request as its content and
forward the content in these requests to a particular Oblivious forward the content in these requests to a particular Oblivious
Gateway Resource. Oblivious HTTP uses a one-to-one mapping Gateway Resource. Oblivious HTTP uses a one-to-one mapping
between Oblivious Relay and Gateway Resources; see Section 8.2 for between Oblivious Relay and Gateway Resources; see Section 8.2 for
more details. more details.
This information allows the Client to send HTTP requests to the This information allows the Client to send HTTP requests to the
Oblivious Gateway Resource for forwarding to a Target Resource. The Oblivious Gateway Resource for forwarding to a Target Resource. The
Oblivious Gateway Resource does not learn the client's IP address or Oblivious Gateway Resource does not learn the Client's IP address or
any other identifying information that might be revealed from the any other identifying information that might be revealed from the
client at the transport layer, nor does the Oblivious Gateway Client at the transport layer, nor does the Oblivious Gateway
Resource learn which of the requests it receives are from the same Resource learn which of the requests it receives are from the same
Client. Client.
.------------------------------. .------------------------------.
+---------+ +----------+ | +----------+ +----------+ | +---------+ +----------+ | +----------+ +----------+ |
| Client | | Relay | | | Gateway | | Target | | | Client | | Relay | | | Gateway | | Target | |
| | | Resource | | | Resource | | Resource | | | | | Resource | | | Resource | | Resource | |
+----+----+ +----+-----+ | +-----+----+ +----+-----+ | +----+----+ +----+-----+ | +-----+----+ +----+-----+ |
| | `-------|--------------|-------' | | `-------|--------------|-------'
| Relay | | | | Relay | | |
skipping to change at line 237 skipping to change at line 237
4. The Oblivious Relay Resource forwards this request to the 4. The Oblivious Relay Resource forwards this request to the
Oblivious Gateway Resource. Oblivious Gateway Resource.
5. The Oblivious Gateway Resource receives this request and removes 5. The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request. the HPKE protection to obtain an HTTP request.
The Oblivious Gateway Resource then handles the HTTP request. This The Oblivious Gateway Resource then handles the HTTP request. This
typically involves making an HTTP request using the content of the typically involves making an HTTP request using the content of the
Encapsulated Request. Once the Oblivious Gateway Resource has an Encapsulated Request. Once the Oblivious Gateway Resource has an
HTTP response for this request, the following steps occur to return HTTP response for this request, the following steps occur to return
this response to the client: this response to the Client:
1. The Oblivious Gateway Resource encapsulates the HTTP response 1. The Oblivious Gateway Resource encapsulates the HTTP response
following the process in Section 4.4 and sends this in response following the process in Section 4.4 and sends this in response
to the request from the Oblivious Relay Resource. to the request from the Oblivious Relay Resource.
2. The Oblivious Relay Resource forwards this response to the 2. The Oblivious Relay Resource forwards this response to the
Client. Client.
3. The Client removes the encapsulation to obtain the response to 3. The Client removes the encapsulation to obtain the response to
the original request. the original request.
skipping to change at line 296 skipping to change at line 296
* Each request is expanded in size with additional HTTP fields, * Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and Authenticated Encryption with encryption-related metadata, and Authenticated Encryption with
Associated Data (AEAD) expansion. Associated Data (AEAD) expansion.
* Deriving cryptographic keys and applying them for request and * Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources. response protection takes non-negligible computational resources.
Examples of where preventing the linking of requests might justify Examples of where preventing the linking of requests might justify
these costs include: these costs include:
DNS queries: DNS queries: DNS queries made to a recursive resolver reveal
DNS queries made to a recursive resolver reveal information about information about the requester, particularly if linked to other
the requester, particularly if linked to other queries. queries.
Telemetry submission: Telemetry submission: Applications that submit reports about their
Applications that submit reports about their usage to their usage to their developers might use Oblivious HTTP for some types
developers might use Oblivious HTTP for some types of moderately of moderately sensitive data.
sensitive data.
These are examples of requests where there is information in a These are examples of requests where there is information in a
request that -- if it were connected to the identity of the user -- 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 might allow a server to learn something about that user even if the
identity of the user were pseudonymous. Other examples include identity of the user were pseudonymous. Other examples include
submitting anonymous surveys, making search queries, or requesting submitting anonymous surveys, making search queries, or requesting
location-specific content (such as retrieving tiles of a map location-specific content (such as retrieving tiles of a map
display). display).
In addition to these limitations, Section 6 describes operational In addition to these limitations, Section 6 describes operational
skipping to change at line 429 skipping to change at line 428
That is, a key configuration consists of the following fields: That is, a key configuration consists of the following fields:
Key Identifier: Key Identifier:
An 8-bit value that identifies the key used by the Oblivious An 8-bit value that identifies the key used by the Oblivious
Gateway Resource. Gateway Resource.
HPKE KEM ID: HPKE KEM ID:
A 16-bit value that identifies the KEM used for the identified key 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" as defined in Section 7.1 of [HPKE] or the "HPKE KEM Identifiers"
IANA registry <https://www.iana.org/assignments/hpke>. IANA registry (https://www.iana.org/assignments/hpke).
HPKE Public Key: HPKE Public Key:
The public key used by the gateway. The length of the 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 is Npk, which is determined by the choice of HPKE KEM as defined
in Section 4 of [HPKE]. in Section 4 of [HPKE].
HPKE Symmetric Algorithms Length: HPKE Symmetric Algorithms Length:
A 16-bit integer in network byte order that encodes the length, in A 16-bit integer in network byte order that encodes the length, in
bytes, of the HPKE Symmetric Algorithms field that follows. bytes, of the HPKE Symmetric Algorithms field that follows.
HPKE Symmetric Algorithms: HPKE Symmetric Algorithms:
One or more pairs of identifiers for the different combinations of One or more pairs of identifiers for the different combinations of
HPKE KDF and AEAD that the Oblivious Gateway Resource supports: HPKE KDF and AEAD that the Oblivious Gateway Resource supports:
HPKE KDF ID: HPKE KDF ID:
A 16-bit HPKE KDF identifier as defined in Section 7.2 of A 16-bit HPKE KDF identifier as defined in Section 7.2 of
[HPKE] or the "HPKE KDF Identifiers" IANA registry [HPKE] or the "HPKE KDF Identifiers" IANA registry
<https://www.iana.org/assignments/hpke>. (https://www.iana.org/assignments/hpke).
HPKE AEAD ID: HPKE AEAD ID:
A 16-bit HPKE AEAD identifier as defined in Section 7.3 of A 16-bit HPKE AEAD identifier as defined in Section 7.3 of
[HPKE] or the "HPKE AEAD Identifiers" IANA registry [HPKE] or the "HPKE AEAD Identifiers" IANA registry
<https://www.iana.org/assignments/hpke>. (https://www.iana.org/assignments/hpke).
3.2. Key Configuration Media Type 3.2. Key Configuration Media Type
The "application/ohttp-keys" format is a media type that identifies a The "application/ohttp-keys" format is a media type that identifies a
serialized collection of key configurations. The content of this serialized collection of key configurations. The content of this
media type comprises one or more key configuration encodings (see media type comprises one or more key configuration encodings (see
Section 3.1). Each encoded configuration is prefixed with a 2-byte Section 3.1). Each encoded configuration is prefixed with a 2-byte
integer in network byte order that indicates the length of the key integer in network byte order that indicates the length of the key
configuration in bytes. The length-prefixed encodings are configuration in bytes. The length-prefixed encodings are
concatenated to form a list. See Section 9.1 for a definition of the concatenated to form a list. See Section 9.1 for a definition of the
skipping to change at line 498 skipping to change at line 497
4.1. Request Format 4.1. Request Format
A message in "message/ohttp-req" format protects a binary HTTP A message in "message/ohttp-req" format protects a binary HTTP
request message; see Figure 3. request message; see Figure 3.
Request { Request {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
Figure 3: Plaintext Request Content Figure 3: Plaintext Request Structure
This plaintext Request is encapsulated into a message in "message/ This plaintext Request structure is encapsulated into a message in
ohttp-req" form by generating an Encapsulated Request. An "message/ohttp-req" form by generating an Encapsulated Request. An
Encapsulated Request comprises a key identifier; HPKE parameters for Encapsulated Request comprises a key identifier; HPKE parameters for
the chosen KEM, KDF, and AEAD; the Encapsulated KEM Shared Secret (or the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or
enc); and an HPKE-protected binary HTTP request message. enc); and an HPKE-protected binary HTTP request message.
An Encapsulated Request is shown in Figure 4. Section 4.3 describes An Encapsulated Request is shown in Figure 4. Section 4.3 describes
the process for constructing and processing an Encapsulated Request. the process for constructing and processing an Encapsulated Request.
Encapsulated Request { Encapsulated Request {
Key Identifier (8), Key Identifier (8),
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE KDF ID (16), HPKE KDF ID (16),
HPKE AEAD ID (16), HPKE AEAD ID (16),
skipping to change at line 537 skipping to change at line 536
4.2. Response Format 4.2. Response Format
A message in "message/ohttp-res" format protects a binary HTTP A message in "message/ohttp-res" format protects a binary HTTP
response message; see Figure 5. response message; see Figure 5.
Response { Response {
Binary HTTP Message (..), Binary HTTP Message (..),
} }
Figure 5: Plaintext Response Content Figure 5: Plaintext Response Structure
This plaintext Response is encapsulated into a message in "message/ This plaintext Response structure is encapsulated into a message in
ohttp-res" form by generating an Encapsulated Response. An "message/ohttp-res" form by generating an Encapsulated Response. An
Encapsulated Response comprises a nonce and the AEAD-protected binary Encapsulated Response comprises a nonce and the AEAD-protected binary
HTTP response message. HTTP response message.
An Encapsulated Response is shown in Figure 6. Section 4.4 describes An Encapsulated Response is shown in Figure 6. Section 4.4 describes
the process for constructing and processing an Encapsulated Response. the process for constructing and processing an Encapsulated Response.
Encapsulated Response { Encapsulated Response {
Nonce (8 * max(Nn, Nk)), Nonce (8 * max(Nn, Nk)),
AEAD-Protected Response (..), AEAD-Protected Response (..),
} }
Figure 6: Encapsulated Response Figure 6: Encapsulated Response
That is, an Encapsulated Response contains a Nonce and an AEAD- That is, an Encapsulated Response contains a Nonce and an AEAD-
Protected Response. The Nonce field is either Nn or Nk bytes long, Protected Response. The Nonce field is either Nn or Nk bytes long,
whichever is larger. The Nn and Nk values correspond to parameters 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] of the AEAD used in HPKE, which is defined in Section 7.3 of [HPKE]
or the "HPKE AEAD Identifiers" IANA registry or the "HPKE AEAD Identifiers" IANA registry
<https://www.iana.org/assignments/hpke>. Nn and Nk refer to the size (https://www.iana.org/assignments/hpke). Nn and Nk refer to the size
of the AEAD nonce and key, respectively, in bytes. of the AEAD nonce and key, respectively, in bytes.
4.3. Encapsulation of Requests 4.3. Encapsulation of Requests
Clients encapsulate a request, request, using values from a key Clients encapsulate a request, identified as request, using values
configuration: from a key configuration:
* the key identifier from the configuration, key_id, with the * the key identifier from the configuration (key_id) with the
corresponding KEM identified by kem_id; corresponding KEM identified by kem_id,
* the public key from the configuration, pkR; and * the public key from the configuration (pkR), and
* a combination of KDF, identified by kdf_id, and AEAD, identified * a combination of KDF (identified by kdf_id) and AEAD (identified
by aead_id, that the Client selects from those in the key by aead_id) that the Client selects from those in the key
configuration. configuration.
The Client then constructs an Encapsulated Request, enc_request, from The Client then constructs an Encapsulated Request, enc_request, from
a binary-encoded HTTP request [BINARY], request, as follows: a binary-encoded HTTP request [BINARY] (request) as follows:
1. Construct a message header, hdr, by concatenating the values of 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 key_id, kem_id, kdf_id, and aead_id as one 8-bit integer and
three 16-bit integers, respectively, with each in network byte three 16-bit integers, respectively, with each in network byte
order. order.
2. Build info by concatenating the ASCII-encoded string "message/ 2. Build a sequence of bytes (info) by concatenating the ASCII-
bhttp request", a zero byte, and the header. Note: Section 4.6 encoded string "message/bhttp request", a zero byte, and the
discusses how alternative message formats might use a different header. Note: Section 4.6 discusses how alternative message
info value. formats might use a different info value.
3. Create a sending HPKE context by invoking SetupBaseS() 3. Create a sending HPKE context by invoking SetupBaseS()
(Section 5.1.1 of [HPKE]) with the public key of the receiver pkR (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 and info. This yields the context sctxt and an encapsulation key
enc. enc.
4. Encrypt request by invoking the Seal() method on sctxt 4. Encrypt request by invoking the Seal() method on sctxt
(Section 5.2 of [HPKE]) with empty associated data aad, yielding (Section 5.2 of [HPKE]) with empty associated data aad, yielding
ciphertext ct. ciphertext ct.
5. Concatenate the values of hdr, enc, and ct, yielding an Encrypted 5. Concatenate the values of hdr, enc, and ct. This yields an
Request enc_request. Encapsulated Request (enc_request).
Note that enc is of fixed length, so there is no ambiguity in parsing Note that enc is of fixed length, so there is no ambiguity in parsing
this structure. this structure.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
hdr = concat(encode(1, key_id), hdr = concat(encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
skipping to change at line 621 skipping to change at line 620
encode(1, 0), encode(1, 0),
hdr) hdr)
enc, sctxt = SetupBaseS(pkR, info) enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request) ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct) enc_request = concat(hdr, enc, ct)
An Oblivious Gateway Resource decrypts an Encapsulated Request by An Oblivious Gateway Resource decrypts an Encapsulated Request by
reversing this process. To decapsulate an Encapsulated Request, reversing this process. To decapsulate an Encapsulated Request,
enc_request: enc_request:
1. Parses enc_request into key_id, kem_id, kdf_id, aead_id, enc, and 1. Parse enc_request into key_id, kem_id, kdf_id, aead_id, enc, and
ct (indicated using the function parse() in pseudocode). The ct (indicated using the function parse() in pseudocode). The
Oblivious Gateway Resource is then able to find the HPKE private Oblivious Gateway Resource is then able to find the HPKE private
key, skR, corresponding to key_id. key, skR, corresponding to key_id.
a. If key_id does not identify a key matching the type of a. If key_id does not identify a key matching the type of
kem_id, the Oblivious Gateway Resource returns an error. kem_id, the Oblivious Gateway Resource returns an error.
b. If kdf_id and aead_id identify a combination of KDF and AEAD b. If kdf_id and aead_id identify a combination of KDF and AEAD
that the Oblivious Gateway Resource is unwilling to use with that the Oblivious Gateway Resource is unwilling to use with
skR, the Oblivious Gateway Resource returns an error. skR, the Oblivious Gateway Resource returns an error.
2. Builds info by concatenating the ASCII-encoded string "message/ 2. Build a sequence of bytes (info) by concatenating the ASCII-
bhttp request", a zero byte, key_id as an 8-bit integer, plus encoded string "message/bhttp request"; a zero byte; key_id as an
kem_id, kdf_id, and aead_id as three 16-bit integers. 8-bit integer; plus kem_id, kdf_id, and aead_id as three 16-bit
integers.
3. Creates a receiving HPKE context, rctxt, by invoking SetupBaseR() 3. Create a receiving HPKE context, rctxt, by invoking SetupBaseR()
(Section 5.1.1 of [HPKE]) with skR, enc, and info. (Section 5.1.1 of [HPKE]) with skR, enc, and info.
4. Decrypts ct by invoking the Open() method on rctxt (Section 5.2 4. Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
of [HPKE]), with an empty associated data aad, yielding request [HPKE]), with an empty associated data aad, yielding request or
or an error on failure. If decryption fails, the Oblivious an error on failure. If decryption fails, the Oblivious Gateway
Gateway Resource returns an error. Resource returns an error.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request) key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
encode(1, 0), encode(1, 0),
encode(1, key_id), encode(1, key_id),
encode(2, kem_id), encode(2, kem_id),
encode(2, kdf_id), encode(2, kdf_id),
encode(2, aead_id)) encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info) rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct) request, error = rctxt.Open("", ct)
The Oblivious Gateway Resource retains the HPKE context, rctxt, so The Oblivious Gateway Resource retains the HPKE context, rctxt, so
that it can encapsulate a response. that it can encapsulate a response.
4.4. Encapsulation of Responses 4.4. Encapsulation of Responses
Oblivious Gateway Resources generate an Encapsulated Response, Oblivious Gateway Resources generate an Encapsulated Response
enc_response, from a binary-encoded HTTP response [BINARY], response. (enc_response) from a binary-encoded HTTP response [BINARY]
The Oblivious Gateway Resource uses the HPKE receiver context, rctxt, (response). The Oblivious Gateway Resource uses the HPKE receiver
as the HPKE context, context, to: context (rctxt) as the HPKE context (context) as follows:
1. Export a secret, secret, from context, using the string "message/ 1. Export a secret (secret) from context, using the string "message/
bhttp response" as the exporter_context parameter to bhttp response" as the exporter_context parameter to
context.Export; see Section 5.3 of [HPKE]. The length of this 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 secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD
key and nonce that are associated with context. Note: key and nonce that are associated with context. Note:
Section 4.6 discusses how alternative message formats might use a Section 4.6 discusses how alternative message formats might use a
different context value. different context value.
2. Generate a random value of length max(Nn, Nk) bytes, called 2. Generate a random value of length max(Nn, Nk) bytes, called
response_nonce. response_nonce.
3. Extract a pseudorandom key, prk, using the Extract function 3. Extract a pseudorandom key (prk) using the Extract function
provided by the KDF algorithm associated with context. The ikm provided by the KDF algorithm associated with context. The ikm
input to this function is secret; the salt input is the input to this function is secret; the salt input is the
concatenation of enc (from enc_request) and response_nonce. concatenation of enc (from enc_request) and response_nonce.
4. Use the Expand function provided by the same KDF to create an 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 key, key, of length Nk -- the length of the keys used by the
AEAD associated with context. Generating aead_key uses a label AEAD associated with context. Generating aead_key uses a label
of "key". of "key".
5. Use the same Expand function to create a nonce, nonce, of length 5. Use the same Expand function to create a nonce, nonce, of length
Nn -- the length of the nonce used by the AEAD. Generating Nn -- the length of the nonce used by the AEAD. Generating
aead_nonce uses a label of "nonce". aead_nonce uses a label of "nonce".
6. Encrypt response, passing the AEAD function Seal the values of 6. Encrypt response, passing the AEAD function Seal the values of
aead_key, aead_nonce, an empty aad, and a pt input of response, aead_key, aead_nonce, an empty aad, and a pt input of response.
which yields ct. This yields ct.
7. Concatenate response_nonce and ct, yielding an Encapsulated 7. Concatenate response_nonce and ct, yielding an Encapsulated
Response, enc_response. Note that response_nonce is of fixed Response, enc_response. Note that response_nonce is of fixed
length, so there is no ambiguity in parsing either response_nonce length, so there is no ambiguity in parsing either response_nonce
or ct. or ct.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
secret = context.Export("message/bhttp response", max(Nn, Nk)) secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk)) response_nonce = random(max(Nn, Nk))
skipping to change at line 718 skipping to change at line 718
aead_nonce = Expand(prk, "nonce", Nn) aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response) ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct) enc_response = concat(response_nonce, ct)
Clients decrypt an Encapsulated Response by reversing this process. Clients decrypt an Encapsulated Response by reversing this process.
That is, Clients first parse enc_response into response_nonce and ct. 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 Then, they follow the same process to derive values for aead_key and
aead_nonce, using their sending HPKE context, sctxt, as the HPKE aead_nonce, using their sending HPKE context, sctxt, as the HPKE
context, context. context, context.
The Client uses these values to decrypt ct using the Open function The Client uses these values to decrypt ct using the AEAD function
provided by the AEAD. Decrypting might produce an error, as follows: Open. Decrypting might produce an error, as follows:
response, error = Open(aead_key, aead_nonce, "", ct) response, error = Open(aead_key, aead_nonce, "", ct)
4.5. Request and Response Media Types 4.5. Request and Response Media Types
Media types are used to identify Encapsulated Requests and Responses; Media types are used to identify Encapsulated Requests and Responses;
see Sections 9.2 and 9.3 for definitions of these media types. see Sections 9.2 and 9.3 for definitions of these media types.
Evolution of the format of Encapsulated Requests and Responses is Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified supported through the definition of new formats that are identified
by new media types. New media types might be defined to use a by new media types. New media types might be defined to use a
similar encapsulation with a different HTTP message format than in similar encapsulation with a different HTTP message format than in
[BINARY]; see Section 4.6 for guidance on reusing this encapsulation. [BINARY]; see Section 4.6 for guidance on reusing this encapsulation
Alternatively, a new encapsulation method might be defined. method. Alternatively, a new encapsulation method might be defined.
4.6. Repurposing the Encapsulation Format 4.6. Repurposing the Encapsulation Format
The encrypted payload of an Oblivious HTTP request and response is a The encrypted payload of an Oblivious HTTP request and response is a
binary HTTP message [BINARY]. The Client and Oblivious Gateway binary HTTP message [BINARY]. The Client and Oblivious Gateway
Resource agree on this encrypted payload type by specifying the media Resource agree on this encrypted payload type by specifying the media
type "message/bhttp" in the HPKE info string and HPKE export context type "message/bhttp" in the HPKE info string and HPKE export context
string for request and response encryption, respectively. string for request and response encryption, respectively.
Future specifications may repurpose the encapsulation mechanism Future specifications may repurpose the encapsulation mechanism
skipping to change at line 774 skipping to change at line 774
Section 9.2), and the Encapsulated Request as the request content. Section 9.2), and the Encapsulated Request as the request content.
In the request to the Oblivious Relay Resource, Clients MAY include In the request to the Oblivious Relay Resource, Clients MAY include
additional fields. However, additional fields MUST be independent of additional fields. However, additional fields MUST be independent of
the Encapsulated Request and MUST be fields that the Oblivious Relay the Encapsulated Request and MUST be fields that the Oblivious Relay
Resource will remove before forwarding the Encapsulated Request Resource will remove before forwarding the Encapsulated Request
towards the target, such as the Connection or Proxy-Authorization towards the target, such as the Connection or Proxy-Authorization
header fields [HTTP]. header fields [HTTP].
The Client role in this protocol acts as an HTTP client both with The Client role in this protocol acts as an HTTP client both with
respect to the Oblivious Relay Resource and the Target Resource. The respect to the Oblivious Relay Resource and the Target Resource. The
request, which the Clients make to the Target Resource, diverges from request, which the Client makes to the Target Resource, diverges from
typical HTTP assumptions about the use of a connection (see typical HTTP assumptions about the use of a connection (see
Section 3.3 of [HTTP]) in that the request and response are encrypted Section 3.3 of [HTTP]) in that the request and response are encrypted
rather than sent over a connection. The Oblivious Relay Resource and rather than sent over a connection. The Oblivious Relay Resource and
the Oblivious Gateway Resource also act as HTTP clients toward the the Oblivious Gateway Resource also act as HTTP clients toward the
Oblivious Gateway Resource and Target Resource, respectively. Oblivious Gateway Resource and Target Resource, respectively.
In order to achieve the privacy and security goals of the protocol, a In order to achieve the privacy and security goals of the protocol, a
Client also needs to observe the guidance in Section 6.1. Client also needs to observe the guidance in Section 6.1.
The Oblivious Relay Resource interacts with the Oblivious Gateway The Oblivious Relay Resource interacts with the Oblivious Gateway
skipping to change at line 832 skipping to change at line 832
itself generate a response with an appropriate error status code itself generate a response with an appropriate error status code
(such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which (such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which
is then encapsulated in the same way as a successful response. is then encapsulated in the same way as a successful response.
In order to achieve the privacy and security goals of the protocol, In order to achieve the privacy and security goals of the protocol,
an Oblivious Gateway Resource also needs to observe the guidance in an Oblivious Gateway Resource also needs to observe the guidance in
Section 6.3. Section 6.3.
5.1. Informational Responses 5.1. Informational Responses
This encapsulation does not permit the progressive processing of This encapsulation does not permit progressive processing of
responses. Though the binary HTTP response format does support the responses. Though the binary HTTP response format does support the
inclusion of informational (1xx) status codes, the AEAD encapsulation inclusion of informational (1xx) status codes, the AEAD encapsulation
cannot be removed until the entire message is received. cannot be removed until the entire message is received.
In particular, the Expect header field with 100-continue (see In particular, the Expect header field with 100-continue (see
Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct
a request that includes a 100-continue expectation; the Oblivious a request that includes a 100-continue expectation; the Oblivious
Gateway Resource MUST generate an error if a 100-continue expectation Gateway Resource MUST generate an error if a 100-continue expectation
is received. is received.
skipping to change at line 871 skipping to change at line 871
and 15.6.5 of [HTTP], respectively). This response is encapsulated and 15.6.5 of [HTTP], respectively). This response is encapsulated
in the same way as a successful response. in the same way as a successful response.
Errors in the encapsulation of requests mean that responses cannot be Errors in the encapsulation of requests mean that responses cannot be
encapsulated. This includes cases where the key configuration is encapsulated. This includes cases where the key configuration is
incorrect or outdated. The Oblivious Gateway Resource can generate incorrect or outdated. The Oblivious Gateway Resource can generate
and send a response with a 4xx status code to the Oblivious Relay 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 Resource. This response MAY be forwarded to the Client or treated by
the Oblivious Relay Resource as a failure. If a Client receives a the Oblivious Relay Resource as a failure. If a Client receives a
response that is not an Encapsulated Response, this could indicate response that is not an Encapsulated Response, this could indicate
that the client configuration used to construct the request is that the Client configuration used to construct the request is
incorrect or out of date. incorrect or out of date.
5.3. Signaling Key Configuration Problems 5.3. Signaling Key Configuration Problems
The problem type [PROBLEM] of "https://iana.org/assignments/http- The problem type [PROBLEM] of "https://iana.org/assignments/http-
problem-types#ohttp-key" is defined in this section. An Oblivious problem-types#ohttp-key" is defined in this section. An Oblivious
Gateway Resource MAY use this problem type in a response to indicate Gateway Resource MAY use this problem type in a response to indicate
that an Encapsulated Request used an outdated or incorrect key that an Encapsulated Request used an outdated or incorrect key
configuration. configuration.
skipping to change at line 976 skipping to change at line 976
scope of this document; see Section 6.2.3. scope of this document; see Section 6.2.3.
A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS]. A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].
6.1. Client Responsibilities 6.1. Client Responsibilities
Because Clients do not authenticate the Target Resource when using Because Clients do not authenticate the Target Resource when using
Oblivious HTTP, Clients MUST have some mechanism to authorize an Oblivious HTTP, Clients MUST have some mechanism to authorize an
Oblivious Gateway Resource for use with a Target Resource. One Oblivious Gateway Resource for use with a Target Resource. One
possible means of authorization is an allowlist. This ensures that possible means of authorization is an allowlist. This ensures that
Oblivious Gateway Resources are not abused to forward traffic to Oblivious Gateway Resources are not misused to forward traffic to
arbitrary Target Resources. Section 6.3 describes similar arbitrary Target Resources. Section 6.3 describes similar
responsibilities that apply to Oblivious Gateway Resources. responsibilities that apply to Oblivious Gateway Resources.
Clients MUST ensure that the key configuration they select for Clients MUST ensure that the key configuration they select for
generating Encapsulated Requests is integrity protected and generating Encapsulated Requests is integrity protected and
authenticated so that it can be attributed to the Oblivious Gateway authenticated so that it can be attributed to the Oblivious Gateway
Resource; see Section 3. Resource; see Section 3.
Since Clients connect directly to the Oblivious Relay Resource Since Clients connect directly to the Oblivious Relay Resource
instead of the Target Resource, application configurations wherein instead of the Target Resource, application configurations wherein
skipping to change at line 1026 skipping to change at line 1026
Client can trust that this information is removed by the relay. A Client can trust that this information is removed by the relay. A
Client MAY include information only for the Oblivious Relay Resource Client MAY include information only for the Oblivious Relay Resource
in header fields identified by the Connection header field if it 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 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 [HTTP]. The Client needs to trust that the relay does not replicate
the source addressing information in the request it forwards. the source addressing information in the request it forwards.
Clients rely on the Oblivious Relay Resource to forward Encapsulated Clients rely on the Oblivious Relay Resource to forward Encapsulated
Requests and Responses. However, the relay can only refuse to Requests and Responses. However, the relay can only refuse to
forward messages; it cannot inspect or modify the contents of forward messages; it cannot inspect or modify the contents of
Encapsulated Requests or responses. Encapsulated Requests or Responses.
6.2. Relay Responsibilities 6.2. Relay Responsibilities
The relay that serves the Oblivious Relay Resource has a very simple The relay that serves the Oblivious Relay Resource has a very simple
function to perform. For each request it receives, it makes a function to perform. For each request it receives, it makes a
request of the Oblivious Gateway Resource that includes the same request of the Oblivious Gateway Resource that includes the same
content. When it receives a response, it sends a response to the content. When it receives a response, it sends a response to the
Client that includes the content of the response from the Oblivious Client that includes the content of the response from the Oblivious
Gateway Resource. Gateway Resource.
skipping to change at line 1124 skipping to change at line 1124
the higher rate. the higher rate.
6.2.3. Traffic Analysis 6.2.3. Traffic Analysis
Using HTTPS protects information about which resources are the Using HTTPS protects information about which resources are the
subject of request and prevents a network observer from being able to subject of request and prevents a network observer from being able to
trivially correlate messages on either side of a relay. However, trivially correlate messages on either side of a relay. However,
using HTTPS does not prevent traffic analysis by such network using HTTPS does not prevent traffic analysis by such network
observers. observers.
The time at which Encapsulated Request or response messages are sent The time at which Encapsulated Request or Response messages are sent
can reveal information to a network observer. Though messages can reveal information to a network observer. Though messages
exchanged between the Oblivious Relay Resource and the Oblivious exchanged between the Oblivious Relay Resource and the Oblivious
Gateway Resource might be sent in a single connection, traffic Gateway Resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the analysis could be used to match messages that are forwarded by the
relay. relay.
A relay could, as part of its function, delay requests before A relay could, as part of its function, delay requests before
forwarding them. Delays might increase the anonymity set into which forwarding them. Delays might increase the anonymity set into which
each request is attributed. Any delay also increases the time that a each request is attributed. Any delay also increases the time that a
Client waits for a response, so delays SHOULD only be added with the Client waits for a response, so delays SHOULD only be added with the
skipping to change at line 1220 skipping to change at line 1220
label was chosen for symmetry only as it provides key diversity only label was chosen for symmetry only as it provides key diversity only
within the HPKE context created using the "message/bhttp request" within the HPKE context created using the "message/bhttp request"
label; see Section 4.6. label; see Section 4.6.
6.5. Replay Attacks 6.5. Replay Attacks
A server is responsible for either rejecting replayed requests or A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect Clients ensuring that the effect of replays does not adversely affect Clients
or resources. or resources.
Encrypted requests can be copied and replayed by the Oblivious Relay Encapsulated Requests can be copied and replayed by the Oblivious
Resource. The threat model for Oblivious HTTP allows the possibility Relay Resource. The threat model for Oblivious HTTP allows the
that an Oblivious Relay Resource might replay requests. Furthermore, possibility that an Oblivious Relay Resource might replay requests.
if a Client sends an Encapsulated Request in TLS early data (see Furthermore, if a Client sends an Encapsulated Request in TLS early
Section 8 of [TLS] and [RFC8470]), a network-based adversary might be data (see Section 8 of [TLS] and [RFC8470]), a network-based
able to cause the request to be replayed. In both cases, the effect adversary might be able to cause the request to be replayed. In both
of a replay attack and the mitigations that might be employed are cases, the effect of a replay attack and the mitigations that might
similar to TLS early data. be employed are similar to TLS early data.
It is the responsibility of the application that uses Oblivious HTTP It is the responsibility of the application that uses Oblivious HTTP
to either reject replayed requests or ensure that replayed requests to either reject replayed requests or ensure that replayed requests
have no adverse effects on their operation. This section describes have no adverse effect on their operation. This section describes
some approaches that are universally applicable and suggestions for some approaches that are universally applicable and suggestions for
more targeted techniques. more targeted techniques.
A Client or Oblivious Relay Resource MUST NOT automatically attempt A Client or Oblivious Relay Resource MUST NOT automatically attempt
to retry a failed request unless it receives a positive signal to retry a failed request unless it receives a positive signal
indicating that the request was not processed or forwarded. The 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/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 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 GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. version) are all sufficient signals that no processing occurred.
skipping to change at line 1495 skipping to change at line 1495
One goal of this design is that independent Client requests are only One goal of this design is that independent Client requests are only
linkable by their content. However, the choice of Client linkable by their content. However, the choice of Client
configuration might be used to correlate requests. A Client configuration might be used to correlate requests. A Client
configuration includes the Oblivious Relay Resource URI, the configuration includes the Oblivious Relay Resource URI, the
Oblivious Gateway key configuration, and the Oblivious Gateway Oblivious Gateway key configuration, and the Oblivious Gateway
Resource URI. A configuration is active if Clients can successfully Resource URI. A configuration is active if Clients can successfully
use it for interacting with a target. use it for interacting with a target.
Oblivious Relay and Gateway Resources can identify when requests use Oblivious Relay and Gateway Resources can identify when requests use
the same configuration by matching the key ID from the key the same configuration by matching the key identifier from the key
configuration or the Oblivious Gateway Resource URI. The Oblivious configuration or the Oblivious Gateway Resource URI. The Oblivious
Gateway Resource might use the source address of requests to Gateway Resource might use the source address of requests to
correlate requests that use an Oblivious Relay Resource run by the correlate requests that use an Oblivious Relay Resource run by the
same operator. If the Oblivious Gateway Resource is willing to use same operator. If the Oblivious Gateway Resource is willing to use
trial decryption, requests can be further separated into smaller trial decryption, requests can be further separated into smaller
groupings based on the keys that are used. groupings based on active configurations that clients use.
Each active Client configuration partitions the Client anonymity set. Each active Client configuration partitions the Client anonymity set.
In practice, it is infeasible to reduce the number of active In practice, it is infeasible to reduce the number of active
configurations to one. Enabling diversity in choice of Oblivious configurations to one. Enabling diversity in choice of Oblivious
Relay Resource naturally increases the number of active Relay Resource naturally increases the number of active
configurations. More than one configuration might need to be active configurations. More than one configuration might need to be active
to allow for key rotation and server maintenance. to allow for key rotation and server maintenance.
Client privacy depends on having each configuration used by many Client privacy depends on having each configuration used by many
other Clients. It is critical to prevent the use of unique Client other Clients. It is critical to prevent the use of unique Client
skipping to change at line 1549 skipping to change at line 1549
requests relative to a simple HTTP request-response exchange. requests relative to a simple HTTP request-response exchange.
Deploying relay services that are on path between Clients and servers Deploying relay services that are on path between Clients and servers
avoids adding significant additional delay due to network topology. avoids adding significant additional delay due to network topology.
A study of a similar system [ODOH-PETS] found that deploying proxies A study of a similar system [ODOH-PETS] found that deploying proxies
close to servers was most effective in minimizing additional latency. close to servers was most effective in minimizing additional latency.
8.2. Resource Mappings 8.2. Resource Mappings
This protocol assumes a fixed, one-to-one mapping between the This protocol assumes a fixed, one-to-one mapping between the
Oblivious Relay Resource and the Oblivious Gateway Resource. This Oblivious Relay Resource and the Oblivious Gateway Resource. This
means that any encrypted request sent to the Oblivious Relay Resource means that any Encapsulated Request sent to the Oblivious Relay
will always be forwarded to the Oblivious Gateway Resource. This Resource will always be forwarded to the Oblivious Gateway Resource.
constraint was imposed to simplify relay configuration and mitigate This constraint was imposed to simplify relay configuration and
against the Oblivious Relay Resource being used as a generic relay mitigate against the Oblivious Relay Resource being used as a generic
for unknown Oblivious Gateway Resources. The relay will only forward relay for unknown Oblivious Gateway Resources. The relay will only
for Oblivious Gateway Resources that it has explicitly configured and forward for Oblivious Gateway Resources that it has explicitly
allowed. configured and allowed.
It is possible for a server to be configured with multiple Oblivious It is possible for a server to be configured with multiple Oblivious
Relay Resources, each for a different Oblivious Gateway Resource, as Relay Resources, each for a different Oblivious Gateway Resource as
needed. If the goal is to support a large number of Oblivious needed. If the goal is to support a large number of Oblivious
Gateway Resources, Clients might be provided with a URI template Gateway Resources, Clients might be provided with a URI template
[TEMPLATE], from which multiple Oblivious Relay Resources could be [TEMPLATE], from which multiple Oblivious Relay Resources could be
constructed. constructed.
8.3. Network Management 8.3. Network Management
Oblivious HTTP might be incompatible with network interception Oblivious HTTP might be incompatible with network interception
regimes, such as those that rely on configuring Clients with trust regimes, such as those that rely on configuring Clients with trust
anchors and intercepting TLS connections. While TLS might be anchors and intercepting TLS connections. While TLS might be
intercepted successfully, interception middleboxes devices might not intercepted successfully, interception middlebox devices might not
receive updates that would allow Oblivious HTTP to be correctly receive updates that would allow Oblivious HTTP to be correctly
identified using the media types defined in Sections 9.2 and 9.3. identified using the media types defined in Sections 9.2 and 9.3.
Oblivious HTTP has a simple key management design that is not Oblivious HTTP has a simple key management design that is not
trivially altered to enable interception by intermediaries. Clients trivially altered to enable interception by intermediaries. Clients
that are configured to enable interception might choose to disable that are configured to enable interception might choose to disable
Oblivious HTTP in order to ensure that content is accessible to Oblivious HTTP in order to ensure that content is accessible to
middleboxes. middleboxes.
9. IANA Considerations 9. IANA Considerations
IANA has registered the following media types in the "Media Types" IANA has registered the following media types in the "Media Types"
registry at <https://iana.org/assignments/media-types>, following the registry at https://iana.org/assignments/media-types, following the
procedures of [RFC6838]: "application/ohttp-keys" (Section 9.1), procedures of [RFC6838]: "application/ohttp-keys" (Section 9.1),
"message/ohttp-req" (Section 9.2), and "message/ohttp-res" "message/ohttp-req" (Section 9.2), and "message/ohttp-res"
(Section 9.3). (Section 9.3).
IANA has added the following types to the "HTTP Problem Types" IANA has added the following types to the "HTTP Problem Types"
registry at <https://iana.org/assignments/http-problem-types>: "date" registry at https://iana.org/assignments/http-problem-types: "date"
(Section 9.4) and "ohttp-key" (Section 9.5). (Section 9.4) and "ohttp-key" (Section 9.5).
9.1. application/ohttp-keys Media Type 9.1. application/ohttp-keys Media Type
The "application/ohttp-keys" media type identifies a key The "application/ohttp-keys" media type identifies a key
configuration used by Oblivious HTTP. configuration used by Oblivious HTTP.
Type name: application Type name: application
Subtype name: ohttp-keys Subtype name: ohttp-keys
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: "binary" Encoding considerations: "binary"
Security considerations: See Section 6.9 Security considerations: See Section 6.9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC 9458 Published specification: RFC 9458
Applications that use this media type: This type identifies a key Applications that use this media type: This type identifies a key
configuration as used by Oblivious HTTP and applications that use configuration as used by Oblivious HTTP and applications that use
Oblivious HTTP. Oblivious HTTP.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information:
See Authors' Addresses section See Authors' Addresses section
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section Author: See Authors' Addresses section
Change controller: IETF Change controller: IETF
9.2. message/ohttp-req Media Type 9.2. message/ohttp-req Media Type
The "message/ohttp-req" identifies an encrypted binary HTTP request. The "message/ohttp-req" identifies an encrypted binary HTTP request.
This is a binary format that is defined in Section 4.3. This is a binary format that is defined in Section 4.3.
Type name: message Type name: message
Subtype name: ohttp-req Subtype name: ohttp-req
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: "binary" Encoding considerations: "binary"
Security considerations: See Section 6.9 Security considerations: See Section 6.9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC 9458 Published specification: RFC 9458
Applications that use this media type: Oblivious HTTP and Applications that use this media type: Oblivious HTTP and
applications that use Oblivious HTTP use this media type to applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP requests. identify encapsulated binary HTTP requests.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information:
See Authors' Addresses section See Authors' Addresses section
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section Author: See Authors' Addresses section
Change controller: IETF Change controller: IETF
9.3. message/ohttp-res Media Type 9.3. message/ohttp-res Media Type
The "message/ohttp-res" identifies an encrypted binary HTTP response. The "message/ohttp-res" identifies an encrypted binary HTTP response.
This is a binary format that is defined in Section 4.4. This is a binary format that is defined in Section 4.4.
Type name: message Type name: message
Subtype name: ohttp-res Subtype name: ohttp-res
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: "binary" Encoding considerations: "binary"
Security considerations: See Section 6.9 Security considerations: See Section 6.9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC 9458 Published specification: RFC 9458
Applications that use this media type: Oblivious HTTP and Applications that use this media type: Oblivious HTTP and
applications that use Oblivious HTTP use this media type to applications that use Oblivious HTTP use this media type to
identify encapsulated binary HTTP responses. identify encapsulated binary HTTP responses.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information:
See Authors' Addresses section See Authors' Addresses section
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section Author: See Authors' Addresses section
Change controller: IETF Change controller: IETF
9.4. Registration of "date" Problem Type 9.4. Registration of "date" Problem Type
IANA has added a new entry in the "HTTP Problem Types" registry IANA has added a new entry in the "HTTP Problem Types" registry
established by [PROBLEM]. established by [PROBLEM].
Type URI: https://iana.org/assignments/http-problem-types#date Type URI: https://iana.org/assignments/http-problem-types#date
Title: Date Not Acceptable Title: Date Not Acceptable
Recommended HTTP Status Code: 400 Recommended HTTP Status Code: 400
skipping to change at line 1866 skipping to change at line 1818
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230, Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022, DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>. <https://www.rfc-editor.org/info/rfc9230>.
[ODOH-PETS] [ODOH-PETS]
Singanamalla, S., Chunhapanya, S., Hoyland, J., Vavruša, Singanamalla, S., Chunhapanya, S., Hoyland, J., Vavruša,
M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan, M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan,
N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A
Practical Privacy Enhancement to DNS", Volume 2021, Issue Practical Privacy Enhancement to DNS", PoPETS Proceedings
4, pp. 575-592, DOI 10.2478/popets-2021-0085, January Volume 2021, Issue 4, pp. 575-592, DOI 10.2478/popets-
2021, <https://doi.org/10.2478/popets-2021-0085>. 2021-0085, January 2021,
<https://doi.org/10.2478/popets-2021-0085>.
[OHTTP-ANALYSIS] [OHTTP-ANALYSIS]
"Tamarin Model of Oblivious HTTP", commit 6824eee, October "Tamarin Model of Oblivious HTTP", commit 6824eee, October
2022, <https://github.com/cloudflare/ohttp-analysis>. 2022, <https://github.com/cloudflare/ohttp-analysis>.
[PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, [PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
and Scalable Computation of Aggregate Statistics", March and Scalable Computation of Aggregate Statistics", March
2017, <https://crypto.stanford.edu/prio/paper.pdf>. 2017, <https://crypto.stanford.edu/prio/paper.pdf>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
skipping to change at line 1896 skipping to change at line 1849
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>. <https://www.rfc-editor.org/info/rfc6570>.
[UWT] Nottingham, M., "Unsanctioned Web Tracking", W3C TAG, July [UWT] Nottingham, M., "Unsanctioned Web Tracking", W3C TAG
2015, Finding, July 2015,
<https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>. <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.
[X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
Appendix A. Complete Example of a Request and Response Appendix A. Complete Example of a Request and Response
A single request and response exchange is shown here. Binary values A single request and response exchange is shown here. Binary values
(key configuration, secret keys, the content of messages, and (key configuration, secret keys, the content of messages, and
skipping to change at line 1949 skipping to change at line 1902
then generates an HPKE sending context that uses the server public then generates an HPKE sending context that uses the server public
key. This context is constructed from the following ephemeral secret key. This context is constructed from the following ephemeral secret
key: key:
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73 bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
The corresponding public key is: The corresponding public key is:
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472 4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
And is an info parameter of: The context is created with an info parameter of:
6d6573736167652f626874747020726571756573740001002000010001 6d6573736167652f626874747020726571756573740001002000010001
Applying the Seal operation from the HPKE context produces an Applying the Seal operation from the HPKE context produces an
encrypted message, allowing the Client to construct the following encrypted message, allowing the Client to construct the following
Encapsulated Request: Encapsulated Request:
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1 010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796 9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525 5e7d86b83dd440b2c0185204b4d63525
skipping to change at line 2057 skipping to change at line 2010
and Eric Rescorla made technical contributions. The authors also and Eric Rescorla made technical contributions. The authors also
thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable
assistance. assistance.
Index Index
C E K O T C E K O T
C C
Client Section 2, Paragraph 1; Section 2, Paragraph 3; Client Section 1, Paragraph 5, Item 3; Section 1, Paragraph 6;
Section 1, Paragraph 7; Section 2, Paragraph 1; Section 2,
Paragraph 3; Section 2, Paragraph 3; Section 2, Paragraph 3;
Section 2, Paragraph 3; Section 2, Paragraph 6, Item 1; Section 2, Paragraph 3; Section 2, Paragraph 6, Item 1;
Section 2, Paragraph 6, Item 2; Section 2, Paragraph 6, Item Section 2, Paragraph 6, Item 2; Section 2, Paragraph 6, Item
3; Section 2, Paragraph 8, Item 2; Section 2, Paragraph 8, 3; Section 2, Paragraph 7; Section 2, Paragraph 8, Item 2;
Item 3; Section 2, Paragraph 9; Section 2, Paragraph 9; Section 2, Paragraph 8, Item 3; Section 2, Paragraph 9;
Section 2, Paragraph 9; Section 2.2; Section 2.2, Paragraph Section 2, Paragraph 9; Section 2, Paragraph 9; Section 2.2;
3.2.1; Section 2.2, Paragraph 3.2.1; Section 3, Paragraph 1; Section 2.2, Paragraph 3.2.1; Section 2.2, Paragraph 3.2.1;
Section 3, Paragraph 2; Section 3, Paragraph 2; Section 3, Section 3, Paragraph 1; Section 3, Paragraph 2; Section 3,
Paragraph 3; Section 3.2, Paragraph 3; Section 4.3, Paragraph 2; Section 3, Paragraph 3; Section 3.2, Paragraph
Paragraph 2, Item 3; Section 4.3, Paragraph 3; Section 4.4, 3; Section 4.3, Paragraph 2, Item 3; Section 4.3, Paragraph
Paragraph 6; Section 4.6, Paragraph 1; Section 5, Paragraph 3; Section 4.4, Paragraph 6; Section 4.6, Paragraph 1;
1; Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5, Paragraph 1; Section 5, Paragraph 2; Section 5,
Paragraph 2; Section 5, Paragraph 3; Section 5, Paragraph 4;
Section 5, Paragraph 4; Section 5, Paragraph 4; Section 5, Section 5, Paragraph 4; Section 5, Paragraph 4; Section 5,
Paragraph 4; Section 5, Paragraph 8; Section 5.2, Paragraph Paragraph 8; Section 5.2, Paragraph 4; Section 5.2,
4; Section 5.2, Paragraph 4; Section 5.3, Paragraph 4; Paragraph 4; Section 5.2, Paragraph 4; Section 5.3,
Section 5.3, Paragraph 4; Section 5.3, Paragraph 4; Paragraph 4; Section 5.3, Paragraph 4; Section 5.3,
Section 5.3, Paragraph 4; Section 6, Paragraph 1; Section 6, Paragraph 4; Section 5.3, Paragraph 4; Section 6, Paragraph
Paragraph 1; Section 6, Paragraph 2, Item 1; Section 6, 1; Section 6, Paragraph 1; Section 6, Paragraph 2, Item 1;
Paragraph 2, Item 1; Section 6, Paragraph 2, Item 1; Section 6, Paragraph 2, Item 1; Section 6, Paragraph 2, Item
Section 6, Paragraph 2, Item 2; Section 6, Paragraph 3; 1; Section 6, Paragraph 2, Item 2; Section 6, Paragraph 3;
Section 6, Paragraph 5, Item 1; Section 6, Paragraph 7; Section 6, Paragraph 5, Item 1; Section 6, Paragraph 7;
Section 6, Paragraph 8; Section 6, Paragraph 10, Item 1; Section 6, Paragraph 8; Section 6, Paragraph 10, Item 1;
Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10, Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10,
Item 2; Section 6, Paragraph 10, Item 2; Section 6.1, Item 2; Section 6, Paragraph 10, Item 2; Section 6.1,
Paragraph 6; Section 6.1, Paragraph 6; Section 6.1, Paragraph 6; Section 6.1, Paragraph 6; Section 6.1,
Paragraph 6; Section 6.1, Paragraph 6; Section 6.2, Paragraph 6; Section 6.1, Paragraph 6; Section 6.2,
Paragraph 1; Section 6.2, Paragraph 2; Section 6.2, Paragraph 1; Section 6.2, Paragraph 2; Section 6.2,
Paragraph 4; Section 6.2, Paragraph 4; Section 6.2.1, Paragraph 4; Section 6.2, Paragraph 4; Section 6.2.1,
Paragraph 1; Section 6.2.1, Paragraph 1; Section 6.2.1, Paragraph 1; Section 6.2.1, Paragraph 1; Section 6.2.1,
Paragraph 2; Section 6.2.1, Paragraph 2; Section 6.2.1, Paragraph 2; Section 6.2.1, Paragraph 2; Section 6.2.1,
skipping to change at line 2106 skipping to change at line 2062
Paragraph 1; Section 6.9, Paragraph 1; Section 7, Paragraph Paragraph 1; Section 6.9, Paragraph 1; Section 7, Paragraph
1; Section 7, Paragraph 1; Section 7, Paragraph 1; 1; Section 7, Paragraph 1; Section 7, Paragraph 1;
Section 7, Paragraph 3; Section 7, Paragraph 3; Section 7, Section 7, Paragraph 3; Section 7, Paragraph 3; Section 7,
Paragraph 4; Section 7, Paragraph 4; Section 7, Paragraph 5; Paragraph 4; Section 7, Paragraph 4; Section 7, Paragraph 5;
Section 7, Paragraph 5; Section 7, Paragraph 5; Section 7, Section 7, Paragraph 5; Section 7, Paragraph 5; Section 7,
Paragraph 6; Appendix A, Paragraph 1; Appendix A, Paragraph Paragraph 6; Appendix A, Paragraph 1; Appendix A, Paragraph
1; Appendix A, Paragraph 6; Appendix A, Paragraph 6; 1; Appendix A, Paragraph 6; Appendix A, Paragraph 6;
Appendix A, Paragraph 8; Appendix A, Paragraph 8; Appendix A, Paragraph 8; Appendix A, Paragraph 8;
Appendix A, Paragraph 8; Appendix A, Paragraph 14; Appendix A, Paragraph 8; Appendix A, Paragraph 14;
Appendix A, Paragraph 16; Appendix A, Paragraph 36 Appendix A, Paragraph 16; Appendix A, Paragraph 36
Clients Section 1, Paragraph 7; Section 2.2, Paragraph 3.8.1; Clients Section 1, Paragraph 5, Item 2; Section 1, Paragraph
Section 3, Paragraph 1; Section 3, Paragraph 3; Section 3, 7; Section 2.2, Paragraph 3.8.1; Section 3, Paragraph 1;
Paragraph 3; Section 3.2, Paragraph 3; Section 3.2, Section 3, Paragraph 3; Section 3, Paragraph 3; Section 3.2,
Paragraph 3; Section 4.3, Paragraph 1; Section 4.4, Paragraph 3; Section 3.2, Paragraph 3; Section 4.3,
Paragraph 5; Section 4.4, Paragraph 5; Section 5, Paragraph Paragraph 1; Section 4.4, Paragraph 5; Section 4.4,
1; Section 5, Paragraph 2; Section 5.1, Paragraph 2; Paragraph 5; Section 5, Paragraph 1; Section 5.1, Paragraph
Section 6, Paragraph 10, Item 1; Section 6.1, Paragraph 1; 2; Section 6, Paragraph 10, Item 1; Section 6.1, Paragraph
Section 6.1, Paragraph 1; Section 6.1, Paragraph 2; 1; Section 6.1, Paragraph 1; Section 6.1, Paragraph 2;
Section 6.1, Paragraph 3; Section 6.1, Paragraph 3; Section 6.1, Paragraph 3; Section 6.1, Paragraph 3;
Section 6.1, Paragraph 4; Section 6.1, Paragraph 4; Section 6.1, Paragraph 4; Section 6.1, Paragraph 4;
Section 6.1, Paragraph 5; Section 6.1, Paragraph 7; Section 6.1, Paragraph 5; Section 6.1, Paragraph 7;
Section 6.2, Paragraph 3; Section 6.2, Paragraph 4; Section 6.2, Paragraph 3; Section 6.2, Paragraph 4;
Section 6.2.1, Paragraph 1; Section 6.2.1, Paragraph 1; Section 6.2.1, Paragraph 1; Section 6.2.1, Paragraph 1;
Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3;
Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3; Section 6.2.1, Paragraph 3;
Section 6.2.2, Paragraph 2; Section 6.2.3, Paragraph 3; Section 6.2.2, Paragraph 2; Section 6.2.3, Paragraph 3;
Section 6.2.3, Paragraph 5; Section 6.2.3, Paragraph 5; Section 6.2.3, Paragraph 5; Section 6.2.3, Paragraph 5;
Section 6.2.3, Paragraph 6; Section 6.5, Paragraph 1; Section 6.2.3, Paragraph 6; Section 6.5, Paragraph 1;
skipping to change at line 2148 skipping to change at line 2104
Paragraph 3; Section 6.2, Paragraph 5 Paragraph 3; Section 6.2, Paragraph 5
Encapsulated Request Section 2, Paragraph 7 Encapsulated Request Section 2, Paragraph 7
Encapsulated Response Appendix A, Paragraph 36 Encapsulated Response Appendix A, Paragraph 36
Encapsulated Request Section 6, Paragraph 10, Item 1 Encapsulated Request Section 6, Paragraph 10, Item 1
Encapsulated Request Section 2, Paragraph 6, Item 3; Encapsulated Request Section 2, Paragraph 6, Item 3;
Section 2.2; Section 2.2, Paragraph 3.10.1; Section 2.2, Section 2.2; Section 2.2, Paragraph 3.10.1; Section 2.2,
Paragraph 3.12.1; Section 4, Paragraph 2, Item 1; Paragraph 3.12.1; Section 4, Paragraph 2, Item 1;
Section 4.1, Paragraph 3; Section 4.1, Paragraph 3; Section 4.1, Paragraph 3; Section 4.1, Paragraph 3;
Section 4.1, Paragraph 4; Section 4.1, Paragraph 4; Section 4.1, Paragraph 4; Section 4.1, Paragraph 4;
Section 4.1, Paragraph 6; Section 4.3, Paragraph 3; Section 4.1, Paragraph 6; Section 4.3, Paragraph 3;
Section 4.3, Paragraph 8; Section 4.3, Paragraph 8; Section 4.3, Paragraph 4, Item 5; Section 4.3, Paragraph 8;
Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5, Section 4.3, Paragraph 8; Section 5, Paragraph 1; Section 5,
Paragraph 1; Section 5, Paragraph 1; Section 5, Paragraph 1; Paragraph 1; Section 5, Paragraph 1; Section 5, Paragraph 1;
Section 5, Paragraph 1; Section 5.3, Paragraph 1; Section 6, Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5,
Paragraph 3; Section 6.1, Paragraph 6; Section 6.2.3, Paragraph 7; Section 5.3, Paragraph 1; Section 6, Paragraph
Paragraph 2; Section 6.3, Paragraph 2; Section 6.4, 3; Section 6.1, Paragraph 6; Section 6.2.3, Paragraph 2;
Paragraph 2; Section 6.5, Paragraph 2; Appendix A, Paragraph Section 6.3, Paragraph 2; Section 6.4, Paragraph 2;
14 Section 6.5, Paragraph 2; Section 8.2, Paragraph 1;
Appendix A, Paragraph 14
Encapsulated Requests Section 1, Paragraph 5, Item 2;
Section 1, Paragraph 5, Item 3; Section 2.2, Paragraph
3.8.1; Section 3, Paragraph 1; Section 4.5, Paragraph 1;
Section 4.5, Paragraph 2; Section 6.1, Paragraph 2;
Section 6.1, Paragraph 7; Section 6.1, Paragraph 7;
Section 6.2.1, Paragraph 1; Section 6.5, Paragraph 2;
Section 6.5.1, Paragraph 1
Encapsulated Response Section 2.2; Section 2.2, Paragraph Encapsulated Response Section 2.2; Section 2.2, Paragraph
3.10.1; Section 4, Paragraph 2, Item 2; Section 4.2, 3.10.1; Section 4, Paragraph 2, Item 2; Section 4.2,
Paragraph 3; Section 4.2, Paragraph 3; Section 4.2, Paragraph 3; Section 4.2, Paragraph 3; Section 4.2,
Paragraph 4; Section 4.2, Paragraph 4; Section 4.2, Paragraph 4; Section 4.2, Paragraph 4; Section 4.2,
Paragraph 6; Section 4.4, Paragraph 1; Section 4.4, Paragraph 6; Section 4.4, Paragraph 1; Section 4.4,
Paragraph 2, Item 7; Section 5.2, Paragraph 4; Appendix A, Paragraph 2, Item 7; Section 5, Paragraph 8; Section 5,
Paragraph 24; Appendix A, Paragraph 32 Paragraph 8; Section 5, Paragraph 8; Section 5, Paragraph 8;
Section 5.2, Paragraph 4; Appendix A, Paragraph 24;
Appendix A, Paragraph 32
Encapsulated Responses Section 1, Paragraph 5, Item 3
K K
key configuration Section 5.2, Paragraph 4 key configuration Section 5.2, Paragraph 4
key configurations Section 6.1, Paragraph 3 key configurations Section 6.1, Paragraph 3
key configuration Section 3, Paragraph 3 key configuration Section 3, Paragraph 3; Section 7, Paragraph
2
key configurations Section 3, Paragraph 2; Section 3, key configurations Section 3, Paragraph 2; Section 3,
Paragraph 3 Paragraph 3
key configuration Section 3, Paragraph 1; Section 3, Paragraph key configuration Section 3, Paragraph 1; Section 3, Paragraph
1; Section 3, Paragraph 2; Section 3.1, Paragraph 1; 1; Section 3, Paragraph 2; Section 3.1, Paragraph 1;
Section 3.1, Paragraph 2; Section 3.1, Paragraph 4; Section 3.1, Paragraph 2; Section 3.1, Paragraph 4;
Section 3.2, Paragraph 1; Section 3.2, Paragraph 1; Section 3.2, Paragraph 1; Section 3.2, Paragraph 1;
Section 3.2, Paragraph 2; Section 3.2, Paragraph 3; Section 3.2, Paragraph 2; Section 3.2, Paragraph 3;
Section 4.3, Paragraph 1; Section 4.3, Paragraph 2, Item 3; Section 4.3, Paragraph 1; Section 4.3, Paragraph 2, Item 3;
Section 5.3, Paragraph 1; Section 5.3, Paragraph 4; Section 5.3, Paragraph 1; Section 5.3, Paragraph 4;
Section 5.3, Paragraph 4; Section 6.1, Paragraph 2; Section 5.3, Paragraph 4; Section 6.1, Paragraph 2;
Section 6.6, Paragraph 1; Section 6.6, Paragraph 1; Section 6.6, Paragraph 1; Section 6.6, Paragraph 1;
Section 6.9, Paragraph 1; Section 7, Paragraph 1; Section 7, Section 6.9, Paragraph 1; Section 7, Paragraph 1;
Paragraph 2; Section 9.1, Paragraph 1; Section 9.1, Section 9.1, Paragraph 1; Section 9.1, Paragraph 2.18.1;
Paragraph 2.18.1; Section 9.5, Paragraph 2.4.1; Appendix A, Section 9.5, Paragraph 2.4.1; Appendix A, Paragraph 1;
Paragraph 1; Appendix A, Paragraph 4; Appendix A, Paragraph Appendix A, Paragraph 4; Appendix A, Paragraph 6;
6; Appendix A, Paragraph 8 Appendix A, Paragraph 8
key configurations Section 3, Paragraph 2; Section 3.2, key configurations Section 3, Paragraph 2; Section 3.2,
Paragraph 1; Section 3.2, Paragraph 3; Section 3.2, Paragraph 1; Section 3.2, Paragraph 3; Section 3.2,
Paragraph 3 Paragraph 3
O O
Oblivious Gateway Resource Section 2.2, Paragraph 3.8.1; Oblivious Gateway Resource Section 2.2, Paragraph 3.8.1;
Section 3.1, Paragraph 5.10.1; Section 6.5.1, Paragraph 3 Section 3.1, Paragraph 5.10.1; Section 6.5.1, Paragraph 3
Oblivious Relay Resource Section 6.2.3, Paragraph 5 Oblivious Relay Resource Section 6.2.3, Paragraph 5
Oblivious Gateway Resource Section 2, Paragraph 2, Item 2; Oblivious Gateway Resource Section 2, Paragraph 2, Item 2;
Section 4.4, Paragraph 1; Section 6.10, Paragraph 3 Section 4.4, Paragraph 1; Section 6.10, Paragraph 3;
Section 8.2, Paragraph 1
Oblivious Relay Resource Section 5.2, Paragraph 4 Oblivious Relay Resource Section 5.2, Paragraph 4
Oblivious Relay Resources Section 8.2, Paragraph 2 Oblivious Relay Resources Section 8.2, Paragraph 2
Oblivious Gateway Resource Section 4.3, Paragraph 9, Item Oblivious Gateway Resource Section 4.3, Paragraph 9, Item
1.2.2 1.2.2
Oblivious Gateway Resource Section 7, Paragraph 1
Oblivious Gateway Resource Section 6.2.2, Paragraph 1; Oblivious Gateway Resource Section 6.2.2, Paragraph 1;
Section 6.5.1, Paragraph 3; Section 6.5.2, Paragraph 7 Section 6.5.1, Paragraph 3; Section 6.5.2, Paragraph 7
Oblivious Gateway Resources Section 6.2.3, Paragraph 6 Oblivious Gateway Resources Section 6.2.3, Paragraph 6
Oblivious Gateway Resource Section 1, Paragraph 5, Item 3; Oblivious Gateway Resource Section 1, Paragraph 5, Item 2;
Section 2, Paragraph 2, Item 3; Section 5.2, Paragraph 3; Section 1, Paragraph 5, Item 3; Section 2, Paragraph 2, Item
Section 5.2, Paragraph 3; Section 6, Paragraph 5, Item 3; 3; Section 5.2, Paragraph 3; Section 5.2, Paragraph 3;
Section 6.1, Paragraph 1; Section 6.1, Paragraph 2; Section 6, Paragraph 5, Item 3; Section 6.1, Paragraph 1;
Section 6.3, Paragraph 4; Section 6.3, Paragraph 4; Section 6.1, Paragraph 2; Section 6.3, Paragraph 4;
Section 6.10, Paragraph 3; Section 6.10, Paragraph 4 Section 6.3, Paragraph 4; Section 6.10, Paragraph 3;
Section 6.10, Paragraph 4
Oblivious Gateway Resources Section 8.2, Paragraph 2 Oblivious Gateway Resources Section 8.2, Paragraph 2
Oblivious Gateway Resource Section 4.3, Paragraph 9, Item Oblivious Gateway Resource Section 4.3, Paragraph 9, Item
1.2.1; Section 4.3, Paragraph 9, Item 1.2.2 1.2.1; Section 4.3, Paragraph 9, Item 1.2.2
Oblivious Gateway Resource Section 5, Paragraph 4; Section 5, Oblivious Gateway Resource Section 2, Paragraph 3; Section 2,
Paragraph 5; Section 6, Paragraph 3 Paragraph 3; Section 5, Paragraph 4; Section 5, Paragraph 5;
Oblivious Gateway Resource Section 1, Paragraph 5, Item 2; Section 6, Paragraph 3; Section 7, Paragraph 2
Section 1, Paragraph 6; Section 1, Paragraph 7; Section 2, Oblivious Gateway Resource Section 1, Paragraph 6; Section 1,
Paragraph 2, Item 1; Section 2, Paragraph 2, Item 1; Paragraph 7; Section 2, Paragraph 2, Item 1; Section 2,
Section 2, Paragraph 3; Section 2, Paragraph 3; Section 2, Paragraph 2, Item 1; Section 2, Paragraph 3; Section 2,
Paragraph 3; Section 2, Paragraph 5; Section 2, Paragraph 6, Paragraph 5; Section 2, Paragraph 6, Item 4; Section 2,
Item 5; Section 2, Paragraph 7; Section 2, Paragraph 7; Paragraph 6, Item 5; Section 2, Paragraph 7; Section 2,
Section 2, Paragraph 8, Item 1; Section 2, Paragraph 9; Paragraph 7; Section 2, Paragraph 8, Item 1; Section 2,
Section 2, Paragraph 9; Section 2.1, Paragraph 1; Paragraph 9; Section 2, Paragraph 9; Section 2.1, Paragraph
Section 2.2; Section 3, Paragraph 1; Section 3.1, Paragraph 1; Section 2.2; Section 3, Paragraph 1; Section 3.1,
5.2.1; Section 4.3, Paragraph 8; Section 4.3, Paragraph Paragraph 5.2.1; Section 4.3, Paragraph 8; Section 4.3,
9.1.1; Section 4.3, Paragraph 9, Item 4; Section 4.3, Paragraph 9.1.1; Section 4.3, Paragraph 9, Item 4;
Paragraph 12; Section 4.6, Paragraph 1; Section 5, Paragraph Section 4.3, Paragraph 12; Section 4.6, Paragraph 1;
2; Section 5, Paragraph 2; Section 5, Paragraph 4; Section 5, Paragraph 2; Section 5, Paragraph 2; Section 5,
Section 5, Paragraph 7; Section 5, Paragraph 8; Section 5, Paragraph 4; Section 5, Paragraph 7; Section 5, Paragraph 8;
Paragraph 9; Section 5, Paragraph 10; Section 5.1, Paragraph Section 5, Paragraph 9; Section 5, Paragraph 10;
2; Section 5.2, Paragraph 2; Section 5.2, Paragraph 4; Section 5.1, Paragraph 2; Section 5.2, Paragraph 2;
Section 5.3, Paragraph 1; Section 5.3, Paragraph 4; Section 5.2, Paragraph 4; Section 5.3, Paragraph 1;
Section 6, Paragraph 1; Section 6, Paragraph 6; Section 6, Section 5.3, Paragraph 4; Section 6, Paragraph 1; Section 6,
Paragraph 7; Section 6, Paragraph 8; Section 6, Paragraph 8; Paragraph 6; Section 6, Paragraph 7; Section 6, Paragraph 8;
Section 6.2, Paragraph 1; Section 6.2, Paragraph 1; Section 6, Paragraph 8; Section 6.2, Paragraph 1;
Section 6.2.3, Paragraph 2; Section 6.3, Paragraph 1; Section 6.2, Paragraph 1; Section 6.2.3, Paragraph 2;
Section 6.3, Paragraph 1; Section 6.3, Paragraph 1; Section 6.3, Paragraph 1; Section 6.3, Paragraph 1;
Section 6.3, Paragraph 4; Section 6.4, Paragraph 1; Section 6.3, Paragraph 1; Section 6.3, Paragraph 4;
Section 6.4, Paragraph 1; Section 6.5.1, Paragraph 1; Section 6.4, Paragraph 1; Section 6.4, Paragraph 1;
Section 6.5.1, Paragraph 3; Section 6.5.2, Paragraph 1; Section 6.5.1, Paragraph 1; Section 6.5.1, Paragraph 3;
Section 6.5.2, Paragraph 4; Section 6.5.2, Paragraph 5; Section 6.5.2, Paragraph 1; Section 6.5.2, Paragraph 4;
Section 6.5.2, Paragraph 8; Section 6.5.2, Paragraph 10; Section 6.5.2, Paragraph 5; Section 6.5.2, Paragraph 8;
Section 6.5.2, Paragraph 10; Section 6.7, Paragraph 3; Section 6.5.2, Paragraph 10; Section 6.5.2, Paragraph 10;
Section 6.9, Paragraph 1; Section 6.10, Paragraph 1; Section 6.7, Paragraph 3; Section 6.9, Paragraph 1;
Section 6.10, Paragraph 1; Section 6.10, Paragraph 3; Section 6.10, Paragraph 1; Section 6.10, Paragraph 1;
Section 6.10, Paragraph 3; Section 6.10, Paragraph 4; Section 6.10, Paragraph 3; Section 6.10, Paragraph 3;
Section 6.10, Paragraph 5; Section 7, Paragraph 1; Section 6.10, Paragraph 4; Section 6.10, Paragraph 5;
Section 7, Paragraph 2; Section 7, Paragraph 2; Section 7, Section 7, Paragraph 2; Section 7, Paragraph 2; Section 8.2,
Paragraph 2; Section 8.2, Paragraph 1; Section 8.2,
Paragraph 1; Section 8.2, Paragraph 2; Appendix A, Paragraph Paragraph 1; Section 8.2, Paragraph 2; Appendix A, Paragraph
1; Appendix A, Paragraph 2; Appendix A, Paragraph 4; 1; Appendix A, Paragraph 2; Appendix A, Paragraph 4;
Appendix A, Paragraph 8; Appendix A, Paragraph 18; Appendix A, Paragraph 8; Appendix A, Paragraph 18;
Appendix A, Paragraph 20; Appendix A, Paragraph 20; Appendix A, Paragraph 20; Appendix A, Paragraph 20;
Appendix A, Paragraph 34 Appendix A, Paragraph 34
Oblivious Gateway Resources Section 4.4, Paragraph 1; Oblivious Gateway Resources Section 4.4, Paragraph 1;
Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10, Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10,
Item 1; Section 6.1, Paragraph 1; Section 6.1, Paragraph 1; Item 1; Section 6, Paragraph 10, Item 2; Section 6.1,
Section 6.5.1, Paragraph 4; Section 6.5.1, Paragraph 5; Paragraph 1; Section 6.1, Paragraph 1; Section 6.5.1,
Section 6.5.2, Paragraph 9; Section 8.2, Paragraph 1; Paragraph 4; Section 6.5.1, Paragraph 5; Section 6.5.2,
Paragraph 9; Section 8.2, Paragraph 1; Section 8.2,
Paragraph 1
Oblivious Relay Resource Section 1, Paragraph 5, Item 2;
Section 2.1, Paragraph 1; Section 5.2, Paragraph 4;
Section 6.1, Paragraph 6; Section 6.1, Paragraph 6;
Section 6.2, Paragraph 2; Section 6.5, Paragraph 2;
Section 6.5, Paragraph 4; Section 8.2, Paragraph 1;
Section 8.2, Paragraph 1 Section 8.2, Paragraph 1
Oblivious Relay Resource Section 2.1, Paragraph 1;
Section 5.2, Paragraph 4; Section 6.1, Paragraph 6;
Section 6.1, Paragraph 6; Section 6.2, Paragraph 2;
Section 6.5, Paragraph 4
Oblivious Relay Resources Section 6.10, Paragraph 4 Oblivious Relay Resources Section 6.10, Paragraph 4
Oblivious Relay and Gateway Resources Section 2, Paragraph 2, Oblivious Relay and Gateway Resources Section 2, Paragraph 2,
Item 3; Section 7, Paragraph 2 Item 3; Section 7, Paragraph 2
Oblivious Relay Resource Section 1, Paragraph 5, Item 2; Oblivious Relay Resource Section 1, Paragraph 6; Section 1,
Section 1, Paragraph 6; Section 1, Paragraph 7; Section 1, Paragraph 7; Section 1, Paragraph 7; Section 2, Paragraph 2,
Paragraph 7; Section 2, Paragraph 2, Item 3; Section 2, Item 3; Section 2, Paragraph 6, Item 3; Section 2, Paragraph
Paragraph 6, Item 3; Section 2, Paragraph 6, Item 4; 6, Item 4; Section 2, Paragraph 8, Item 1; Section 2,
Section 2, Paragraph 8, Item 1; Section 2, Paragraph 8, Item Paragraph 8, Item 2; Section 2.2, Paragraph 3.2.1;
2; Section 2.2, Paragraph 3.2.1; Section 2.2; Section 5, Section 2.2; Section 5, Paragraph 1; Section 5, Paragraph 1;
Paragraph 1; Section 5, Paragraph 1; Section 5, Paragraph 1;
Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5, Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5,
Paragraph 2; Section 5, Paragraph 2; Section 5, Paragraph 4; Paragraph 1; Section 5, Paragraph 2; Section 5, Paragraph 2;
Section 5, Paragraph 4; Section 5, Paragraph 4; Section 5, Section 5, Paragraph 4; Section 5, Paragraph 4; Section 5,
Paragraph 5; Section 5, Paragraph 5; Section 5, Paragraph 6; Paragraph 4; Section 5, Paragraph 5; Section 5, Paragraph 5;
Section 5.2, Paragraph 2; Section 5.3, Paragraph 4; Section 5, Paragraph 6; Section 5.2, Paragraph 2;
Section 6, Paragraph 3; Section 6, Paragraph 5, Item 2; Section 5.3, Paragraph 4; Section 6, Paragraph 3; Section 6,
Section 6, Paragraph 7; Section 6, Paragraph 7; Section 6, Paragraph 5, Item 2; Section 6, Paragraph 7; Section 6,
Paragraph 8; Section 6, Paragraph 10, Item 1; Section 6, Paragraph 7; Section 6, Paragraph 8; Section 6, Paragraph
Paragraph 10, Item 1; Section 6.1, Paragraph 3; Section 6.1, 10, Item 1; Section 6, Paragraph 10, Item 1; Section 6.1,
Paragraph 3; Section 6.1, Paragraph 4; Section 6.1,
Paragraph 6; Section 6.1, Paragraph 7; Section 6.2, Paragraph 6; Section 6.1, Paragraph 7; Section 6.2,
Paragraph 1; Section 6.2, Paragraph 3; Section 6.2.3, Paragraph 1; Section 6.2, Paragraph 3; Section 6.2.3,
Paragraph 2; Section 6.2.3, Paragraph 5; Section 6.5, Paragraph 2; Section 6.2.3, Paragraph 5; Section 6.5,
Paragraph 2; Section 6.7, Paragraph 4; Section 6.7, Paragraph 2; Section 6.7, Paragraph 4; Section 6.7,
Paragraph 4; Section 7, Paragraph 1; Section 7, Paragraph 2; Paragraph 4; Section 7, Paragraph 1; Section 7, Paragraph 2;
Section 7, Paragraph 3; Section 8.2, Paragraph 1; Section 7, Paragraph 3; Section 8.2, Paragraph 1;
Section 8.2, Paragraph 1; Section 8.2, Paragraph 1;
Appendix A, Paragraph 1; Appendix A, Paragraph 16; Appendix A, Paragraph 1; Appendix A, Paragraph 16;
Appendix A, Paragraph 18; Appendix A, Paragraph 36 Appendix A, Paragraph 18; Appendix A, Paragraph 36
Oblivious Relay Resources Section 6.2.2, Paragraph 1; Oblivious Relay Resources Section 6.2.2, Paragraph 1;
Section 6.2.3, Paragraph 6; Section 8.2, Paragraph 2 Section 6.2.3, Paragraph 6; Section 8.2, Paragraph 2
T T
Target Resource Section 6.9, Paragraph 3 Target Resource Section 6.9, Paragraph 3
Target Resource Section 5, Paragraph 7 Target Resource Section 5, Paragraph 7
Target Resource Section 2, Paragraph 3; Section 2, Paragraph Target Resource Section 2, Paragraph 3; Section 2, Paragraph
 End of changes. 123 change blocks. 
251 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.48.