rfc9458.original   rfc9458.txt 
Oblivious HTTP Application Intermediation M. Thomson Internet Engineering Task Force (IETF) M. Thomson
Internet-Draft Mozilla Request for Comments: 9458 Mozilla
Intended status: Standards Track C. A. Wood Category: Standards Track C. A. Wood
Expires: 16 September 2023 Cloudflare ISSN: 2070-1721 Cloudflare
15 March 2023 January 2024
Oblivious HTTP Oblivious HTTP
draft-ietf-ohai-ohttp-08
Abstract Abstract
This document describes a system for forwarding encrypted HTTP This document describes Oblivious HTTP, a protocol for forwarding
messages. This allows a client to make multiple requests to an encrypted HTTP messages. Oblivious HTTP allows a client to make
origin server without that server being able to link those requests multiple requests to an origin server without that server being able
to the client or to identify the requests as having come from the to link those requests to the client or to identify the requests as
same client, while placing only limited trust in the nodes used to having come from the same client, while placing only limited trust in
forward the messages. the nodes used to forward the messages.
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/. Subscribe at
https://www.ietf.org/mailman/listinfo/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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 September 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9458.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Overview 2. Overview
2.1. Applicability 2.1. Applicability
2.2. Conventions and Definitions 2.2. Conventions and Definitions
3. Key Configuration 3. Key Configuration
3.1. Key Configuration Encoding 3.1. Key Configuration Encoding
3.2. Key Configuration Media Type 3.2. Key Configuration Media Type
skipping to change at line 98 skipping to change at line 77
5.3. Signaling Key Configuration Problems 5.3. Signaling Key Configuration Problems
6. Security Considerations 6. Security Considerations
6.1. Client Responsibilities 6.1. Client Responsibilities
6.2. Relay Responsibilities 6.2. Relay Responsibilities
6.2.1. Differential Treatment 6.2.1. Differential Treatment
6.2.2. Denial of Service 6.2.2. Denial of Service
6.2.3. Traffic Analysis 6.2.3. Traffic Analysis
6.3. Server Responsibilities 6.3. Server Responsibilities
6.4. Key Management 6.4. Key Management
6.5. Replay Attacks 6.5. Replay Attacks
6.5.1. Use of Date for Anti-Replay 6.5.1. Use of Date for Anti-replay
6.5.2. Correcting Clock Differences 6.5.2. Correcting Clock Differences
6.6. Forward Secrecy 6.6. Forward Secrecy
6.7. Post-Compromise Security 6.7. Post-Compromise Security
6.8. Client Clock Exposure 6.8. Client Clock Exposure
6.9. Media Type Security 6.9. Media Type Security
6.10. Separate Gateway and Target 6.10. Separate Gateway and Target
7. Privacy Considerations 7. Privacy Considerations
8. Operational and Deployment Considerations 8. Operational and Deployment Considerations
8.1. Performance Overhead 8.1. Performance Overhead
8.2. Resource Mappings 8.2. Resource Mappings
skipping to change at line 121 skipping to change at line 100
9.1. application/ohttp-keys Media Type 9.1. application/ohttp-keys Media Type
9.2. message/ohttp-req Media Type 9.2. message/ohttp-req Media Type
9.3. message/ohttp-res Media Type 9.3. message/ohttp-res Media Type
9.4. Registration of "date" Problem Type 9.4. Registration of "date" Problem Type
9.5. Registration of "ohttp-key" Problem Type 9.5. Registration of "ohttp-key" Problem Type
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Appendix A. Complete Example of a Request and Response Appendix A. Complete Example of a Request and Response
Acknowledgments Acknowledgments
Index
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
An HTTP request reveals information about the client's identity to HTTP requests reveal information about client identities to servers.
the server. Some of that information is in the request content, and While the actual content of the request message is under the control
therefore under the control of the client. However, the source IP of the client, other information that is more difficult to control
address of the underlying connection reveals information that the can still be used to identify the client.
client has only limited control over.
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.
Client-configured HTTP proxies can provide a degree of protection
against IP address tracking, and systems like virtual private
networks and the Tor network [DMS2004] provide additional options for
clients.
However, even when IP address tracking is mitigated using one of In particular, the source IP address of the underlying connection
these techniques, each request needs to be on a completely new TLS reveals identifying information that the client has only limited
connection to avoid the connection itself being used to correlate control over. While client-configured HTTP proxies can provide a
behavior. This imposes considerable performance and efficiency degree of protection against IP address tracking, they present an
overheads, due to the additional round trip to the server (at a unfortunate trade-off: if they are used without TLS, the contents of
minimum), additional data exchanged, and additional CPU cost of communication are revealed to the proxy; if they are used with TLS, a
cryptographic computations. new connection needs to be used for each request to ensure that the
origin server cannot use the connection as a way to correlate
requests, incurring significant performance overheads.
To overcome these limitations, this document defines Oblivious HTTP, To overcome these limitations, this document defines Oblivious HTTP,
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 through a trusted relay service. In particular, the a gateway. This uses a trusted relay service in a manner that
protocol in this document describes: mitigates the use of metadata such as IP address and connection
information for client identification, with reasonable performance
characteristics. This document describes:
1. an algorithm for encapsulating binary HTTP messages [BINARY] 1. an algorithm for encapsulating binary HTTP messages [BINARY]
using Hybrid Public Key Encryption (HPKE; [HPKE]) to protect using Hybrid Public Key Encryption (HPKE) [HPKE] to protect their
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 the Oblivious Gateway Resource never sees the Client's IP address and that the
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 201 skipping to change at line 177
* 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 251 skipping to change at line 227
1. The Client constructs an HTTP request for a Target Resource. 1. The Client constructs an HTTP request for a Target Resource.
2. The Client encodes the HTTP request in a binary HTTP message and 2. The Client encodes the HTTP request in a binary HTTP message and
then encapsulates that message using HPKE and the process from then encapsulates that message using HPKE and the process from
Section 4.3. Section 4.3.
3. The Client sends a POST request to the Oblivious Relay Resource 3. The Client sends a POST request to the Oblivious Relay Resource
with the Encapsulated Request as the content of that message. with the Encapsulated Request as the content of that message.
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 283 skipping to change at line 259
protection between the Client and the Oblivious Gateway, but protection between the Client and the Oblivious Gateway, but
importantly not between the Client and the Target Resource. While importantly not between the Client and the Target Resource. While
the Target Resource is a distinct HTTP resource from the Oblivious the Target Resource is a distinct HTTP resource from the Oblivious
Gateway Resource, they are both logically under the control of the Gateway Resource, they are both logically under the control of the
Oblivious Gateway, since the Oblivious Gateway Resource can Oblivious Gateway, since the Oblivious Gateway Resource can
unilaterally dictate the responses returned from the Target Resource unilaterally dictate the responses returned from the Target Resource
to the Client. This arrangement is shown in Figure 1. to the Client. This arrangement is shown in Figure 1.
2.1. Applicability 2.1. Applicability
Oblivious HTTP has limited applicability. Imporantly, it requires Oblivious HTTP has limited applicability. Importantly, it requires
expicit support from a willing Oblivious Relay Resource and Oblivious explicit support from a willing Oblivious Relay Resource and
Gateway Resource, thereby limiting the use of Oblivious HTTP for Oblivious Gateway Resource, thereby limiting the use of Oblivious
generic applications; see Section 6.3 for more information. HTTP for generic applications; see Section 6.3 for more information.
Many uses of HTTP benefit from being able to carry state between Many uses of HTTP benefit from being able to carry state between
requests, such as with cookies ([COOKIES]), authentication requests, such as with cookies [COOKIES], authentication (Section 11
(Section 11 of [HTTP]), or even alternative services ([RFC7838]). of [HTTP]), or even alternative services [RFC7838]. Oblivious HTTP
Oblivious HTTP removes linkage at the transport layer, which is only removes linkage at the transport layer, which is only useful for an
useful for an application that does not carry state between requests. application that does not carry state between requests.
Oblivious HTTP is primarily useful where privacy risks associated Oblivious HTTP is primarily useful where the privacy risks associated
with possible stateful treatment of requests are sufficiently large with possible stateful treatment of requests are sufficiently large
that the cost of deploying this protocol can be justified. Oblivious that the cost of deploying this protocol can be justified. Oblivious
HTTP is simpler and less costly than more robust systems, like Prio HTTP is simpler and less costly than more robust systems, like Prio
([PRIO]) or Tor ([DMS2004]), which can provide stronger guarantees at [PRIO] or Tor [DMS2004], which can provide stronger guarantees at
higher operational costs. higher operational costs.
Oblivious HTTP is more costly than a direct connection to a server. Oblivious HTTP is more costly than a direct connection to a server.
Some costs, like those involved with connection setup, can be Some costs, like those involved with connection setup, can be
amortized, but there are several ways in which Oblivious HTTP is more amortized, but there are several ways in which Oblivious HTTP is more
expensive than a direct request: expensive than a direct request:
* Each request requires at least two regular HTTP requests, which * Each request requires at least two regular HTTP requests, which
could increase latency. could increase latency.
* Each request is expanded in size with additional HTTP fields, * Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and AEAD expansion. encryption-related metadata, and Authenticated Encryption with
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 made to a recursive resolver reveal DNS queries: DNS queries made to a recursive resolver reveal
information about the requester, particularly if linked to other information about the requester, particularly if linked to other
queries. queries.
* Telemetry submission. Applications that submit reports about Telemetry submission: Applications that submit reports about their
their usage to their developers might use Oblivious HTTP for some usage to their developers might use Oblivious HTTP for some types
types of moderately sensitive data. of moderately 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 is pseudonymous. Other examples include the identity of the user were pseudonymous. Other examples include
submission of 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
constraints that are necessary to realize the goals of the protocol. constraints that are necessary to realize the goals of the protocol.
2.2. Conventions and Definitions 2.2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses terminology from [HTTP] and defines several terms This document uses terminology from [HTTP] and defines several terms
as follows: as follows:
Client: A Client originates Oblivious HTTP requests. A Client is Client:
also an HTTP client in two ways: for the Target Resource and for A Client originates Oblivious HTTP requests. A Client is also an
the Oblivious Relay Resource. However, when referring to the HTTP HTTP client in two ways: for the Target Resource and for the
Oblivious Relay Resource. However, when referring to the HTTP
definition of client (Section 3.3 of [HTTP]), the term "HTTP definition of client (Section 3.3 of [HTTP]), the term "HTTP
client" is used; see Section 5. client" is used; see Section 5.
Encapsulated Request: An HTTP request that is encapsulated in an Encapsulated Request:
HPKE-encrypted message; see Section 4.3. An HTTP request that is encapsulated in an HPKE-encrypted message;
see Section 4.3.
Encapsulated Response: An HTTP response that is encapsulated in an Encapsulated Response:
HPKE-encrypted message; see Section 4.4. An HTTP response that is encapsulated in an HPKE-encrypted
message; see Section 4.4.
Oblivious Relay Resource: An intermediary that forwards Encapsulated Oblivious Relay Resource:
Requests and Responses between Clients and a single Oblivious An intermediary that forwards Encapsulated Requests and Responses
Gateway Resource. In context, this can be referred to as simply a between Clients and a single Oblivious Gateway Resource. In
"relay". context, this can be referred to simply as a "relay".
Oblivious Gateway Resource: A resource that can receive an Oblivious Gateway Resource:
Encapsulated Request, extract the contents of that request, A resource that can receive an Encapsulated Request, extract the
forward it to a Target Resource, receive a response, encapsulate contents of that request, forward it to a Target Resource, receive
that response, then return the resulting Encapsulated Response. a response, encapsulate that response, and then return the
In context, this can be referred to as simply a "gateway". resulting Encapsulated Response. In context, this can be referred
to simply as a "gateway".
Target Resource: The resource that is the target of an Encapsulated Target Resource:
Request. This resource logically handles only regular HTTP The resource that is the target of an Encapsulated Request. This
requests and responses and so might be ignorant of the use of resource logically handles only regular HTTP requests and
Oblivious HTTP to reach it. responses, so it might be ignorant of the use of Oblivious HTTP to
reach it.
This document includes pseudocode that uses the functions and This document includes pseudocode that uses the functions and
conventions defined in [HPKE]. conventions defined in [HPKE].
Encoding an integer to a sequence of bytes in network byte order is 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 described using the function encode(n, v), where n is the number of
bytes and v is the integer value. ASCII [ASCII] encoding of a string bytes and v is the integer value. ASCII [ASCII] encoding of a string
s is indicated using the function encode_str(s). s is indicated using the function encode_str(s).
Formats are described using notation from Section 1.3 of [QUIC]. An Formats are described using notation from Section 1.3 of [QUIC]. An
skipping to change at line 401 skipping to change at line 383
the Oblivious Gateway Resource in order to send Encapsulated the Oblivious Gateway Resource in order to send Encapsulated
Requests. In order to ensure that Clients do not encapsulate Requests. In order to ensure that Clients do not encapsulate
messages that other entities can intercept, the key configuration messages that other entities can intercept, the key configuration
MUST be authenticated and have integrity protection. MUST be authenticated and have integrity protection.
This document does not define how that acquisition occurs. However, This document does not define how that acquisition occurs. However,
in order to help facilitate interoperability, it does specify a in order to help facilitate interoperability, it does specify a
format for the keys. This ensures that different Client format for the keys. This ensures that different Client
implementations can be configured in the same way and also enables implementations can be configured in the same way and also enables
advertising key configurations in a consistent format. This format advertising key configurations in a consistent format. This format
might be used, for example with HTTPS, as part of a system for might be used, for example, with HTTPS, as part of a system for
configuring or discovering key configurations. Note however that configuring or discovering key configurations. However, note that
such a system needs to consider the potential for key configuration such a system needs to consider the potential for key configuration
to be used to compromise Client privacy; see Section 7. to be used to compromise Client privacy; see Section 7.
A Client might have multiple key configurations to select from when A Client might have multiple key configurations to select from when
encapsulating a request. Clients are responsible for selecting a encapsulating a request. Clients are responsible for selecting a
preferred key configuration from those it supports. Clients need to preferred key configuration from those it supports. Clients need to
consider both the key encapsulation method (KEM) and the combinations consider both the Key Encapsulation Method (KEM) and the combinations
of key derivation function (KDF) and authenticated encryption with of the Key Derivation Function (KDF) and AEAD in this decision.
associated data (AEAD) in this decision.
3.1. Key Configuration Encoding 3.1. Key Configuration Encoding
A single key configuration consists of a key identifier, a public A single key configuration consists of a key identifier, a public
key, an identifier for the KEM that the public key uses, and a set of key, an identifier for the KEM that the public key uses, and a set of
HPKE symmetric algorithms. Each symmetric algorithm consists of an HPKE symmetric algorithms. Each symmetric algorithm consists of an
identifier for a KDF and an identifier for an AEAD. identifier for a KDF and an identifier for an AEAD.
Figure 2 shows a single key configuration. Figure 2 shows a single key configuration.
skipping to change at line 439 skipping to change at line 420
HPKE KEM ID (16), HPKE KEM ID (16),
HPKE Public Key (Npk * 8), HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532, HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ..., HPKE Symmetric Algorithms (32) ...,
} }
Figure 2: A Single Key Configuration Figure 2: A Single Key Configuration
That is, a key configuration consists of the following fields: That is, a key configuration consists of the following fields:
Key Identifier: An 8 bit value that identifies the key used by the Key Identifier:
Oblivious Gateway Resource. An 8-bit value that identifies the key used by the Oblivious
Gateway Resource.
HPKE KEM ID: A 16 bit value that identifies the Key Encapsulation HPKE KEM ID:
Method (KEM) used for the identified key as defined in Section 7.1 A 16-bit value that identifies the KEM used for the identified key
of [HPKE] or the HPKE KDF IANA registry as defined in Section 7.1 of [HPKE] or the "HPKE KEM Identifiers"
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids). registry <https://www.iana.org/assignments/hpke>.
HPKE Public Key: The public key used by the gateway. The length of HPKE Public Key:
the public key is Npk, which is determined by the choice of HPKE The public key used by the gateway. The length of the public key
KEM as defined in Section 4 of [HPKE]. is Npk, which is determined by the choice of HPKE KEM as defined
in Section 4 of [HPKE].
HPKE Symmetric Algorithms Length: A 16 bit integer in network byte HPKE Symmetric Algorithms Length:
order that encodes the length, in bytes, of the HPKE Symmetric A 16-bit integer in network byte order that encodes the length, in
Algorithms field that follows. bytes, of the HPKE Symmetric Algorithms field that follows.
HPKE Symmetric Algorithms: One or more pairs of identifiers for the HPKE Symmetric Algorithms:
different combinations of HPKE KDF and AEAD that the Oblivious One or more pairs of identifiers for the different combinations of
Gateway Resource supports: HPKE KDF and AEAD that the Oblivious Gateway Resource supports:
HPKE KDF ID: A 16 bit HPKE KDF identifier as defined in HPKE KDF ID:
Section 7.2 of [HPKE] or the HPKE KDF IANA registry A 16-bit HPKE KDF identifier as defined in Section 7.2 of
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kdf- [HPKE] or the "HPKE KDF Identifiers" registry
ids). <https://www.iana.org/assignments/hpke>.
HPKE AEAD ID: A 16 bit HPKE AEAD identifier as defined in HPKE AEAD ID:
Section 7.3 of [HPKE] or the HPKE AEAD IANA registry A 16-bit HPKE AEAD identifier as defined in Section 7.3 of
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead- [HPKE] or the "HPKE AEAD Identifiers" registry
ids). <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) that are concatenated; see Section 9.1 for a definition Section 3.1). Each encoded configuration is prefixed with a 2-byte
of the media type. integer in network byte order that indicates the length of the key
configuration in bytes. The length-prefixed encodings are
concatenated to form a list. See Section 9.1 for a definition of the
media type.
Evolution of the key configuration format is supported through the Evolution of the key configuration format is supported through the
definition of new formats that are identified by new media types. definition of new formats that are identified by new media types.
A Client that receives an "application/ohttp-keys" object with
encoding errors might be able to recover one or more key
configurations. Differences in how key configurations are recovered
might be exploited to segregate Clients, so Clients MUST discard
incorrectly encoded key configuration collections.
4. HPKE Encapsulation 4. HPKE Encapsulation
This document defines how a binary-encoded HTTP message [BINARY] is This document defines how a binary-encoded HTTP message [BINARY] is
encapsulated using HPKE [HPKE]. Separate media types are defined to encapsulated using HPKE [HPKE]. Separate media types are defined to
distinguish request and response messages: distinguish request and response messages:
* An Encapsulated Request format defined in Section 4.1 is * An Encapsulated Request format defined in Section 4.1 is
identified by the "message/ohttp-req" media type (message/ identified by the "message/ohttp-req" media type (Section 9.2).
ohttp-req Media Type).
* An Encapsulated Response format defined in Section 4.2 is * An Encapsulated Response format defined in Section 4.2 is
identified by the "message/ohttp-res" media type (Section 9.3). identified by the "message/ohttp-res" media type (Section 9.3).
Alternative encapsulations or message formats are indicated using the Alternative encapsulations or message formats are indicated using the
media type; see Section 4.5 and Section 4.6. media type; see Sections 4.5 and 4.6.
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),
Encapsulated KEM Shared Secret (8 * Nenc), Encapsulated KEM Shared Secret (8 * Nenc),
HPKE-Protected Request (..), HPKE-Protected Request (..),
} }
Figure 4: Encapsulated Request Figure 4: Encapsulated Request
That is, an Encapsulated Request comprises a Key Identifier, HPKE KEM That is, an Encapsulated Request comprises a Key Identifier, an HPKE
ID, HPKE KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and KEM ID, an HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared
HPKE-Protected Request. The Key Identifier, HPKE KEM ID, HPKE KDF Secret, and an HPKE-Protected Request. The Key Identifier, HPKE KEM
ID, and HPKE AEAD ID fields are defined in Section 3.1. The ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in Section 3.1.
Encapsulated KEM Shared Secret is the output of the Encap() function The Encapsulated KEM Shared Secret is the output of the Encap()
for the KEM, which is Nenc bytes in length, as defined in Section 4 function for the KEM, which is Nenc bytes in length, as defined in
of [HPKE]. Section 4 of [HPKE].
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 IANA registry or the "HPKE AEAD Identifiers" IANA registry
(https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids). Nn <https://www.iana.org/assignments/hpke>. Nn and Nk refer to the size
and Nk refer to the size of the AEAD nonce and key respectively, in of the AEAD nonce and key, respectively, in bytes.
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, each in network byte order. three 16-bit integers, respectively, each in network byte 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))
info = concat(encode_str("message/bhttp request"), info = concat(encode_str("message/bhttp request"),
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 skR, that the Oblivious Gateway Resource is unwilling to use with
the Oblivious Gateway Resource returns an error. skR, the Oblivious Gateway Resource returns an error.
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, 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. Create 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. Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of 4. Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
[HPKE]), with an empty associated data aad, yielding request or [HPKE]), with an empty associated data aad, yielding request or
an error on failure. If decryption fails, the Oblivious Gateway an error on failure. If decryption fails, the Oblivious Gateway
Resource returns an error. Resource returns an error.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
skipping to change at line 669 skipping to change at line 660
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, as follows: 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 AEAD key secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD
and nonce associated with context. Note: Section 4.6 discusses key and nonce that are associated with context. Note:
how alternative message formats might use a different context Section 4.6 discusses how alternative message formats might use a
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", Nk) secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk)) response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce) salt = concat(enc, response_nonce)
prk = Extract(salt, secret) prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk) aead_key = Expand(prk, "key", Nk)
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.
They then 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 Section 9.2 and Section 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 similar by new media types. New media types might be defined to use a
encapsulation with a different HTTP message format than in [BINARY]; similar encapsulation with a different HTTP message format than in
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 780 skipping to change at line 771
Resource, a header field containing the content type (see Resource, a header field containing the content type (see
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. For respect to the Oblivious Relay Resource and the Target Resource. The
the request, the Clients makes to the Target Resource, this diverges request, which the Client makes to the Target Resource, diverges from
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
Resource as an HTTP client by constructing a request using the same Resource as an HTTP client by constructing a request using the same
restrictions as the Client request, except that the target URI is the restrictions as the Client request, except that the target URI is the
Oblivious Gateway Resource. The content of this request is copied Oblivious Gateway Resource. The content of this request is copied
from the Client. An Oblivious Relay Resource MAY reject requests from the Client. An Oblivious Relay Resource MAY reject requests
that are obviously invalid, such as a request with no content. The that are obviously invalid, such as a request with no content. The
Oblivious Relay Resource MUST NOT add information to the request Oblivious Relay Resource MUST NOT add information to the request
without the Client being aware of the type of information that might without the Client being aware of the type of information that might
be added; see Section 6.2 for more information on relay be added; see Section 6.2 for more information on relay
responsibilities. responsibilities.
When a response is received from the Oblivious Gateway Resource, the When a response is received from the Oblivious Gateway Resource, the
Oblivious Relay Resource forwards the response according to the rules Oblivious Relay Resource forwards the response according to the rules
of an HTTP proxy; see Section 7.6 of [HTTP]. In case of timeout or of an HTTP proxy; see Section 7.6 of [HTTP]. In case of timeout or
error, the Oblivious Relay Resource can generate a response with an error, the Oblivious Relay Resource can generate a response with an
appropriate status code. appropriate status code.
In order to achieve the privacy and security goals of the protocol an In order to achieve the privacy and security goals of the protocol,
Oblivious Relay Resource also needs to observe the guidance in an Oblivious Relay Resource also needs to observe the guidance in
Section 6.2. Section 6.2.
An Oblivious Gateway Resource acts as a gateway for requests to the An Oblivious Gateway Resource acts as a gateway for requests to the
Target Resource (see Section 7.6 of [HTTP]). The one exception is Target Resource (see Section 7.6 of [HTTP]). The one exception is
that any information it might forward in a response MUST be that any information it might forward in a response MUST be
encapsulated, unless it is responding to errors that do not relate to encapsulated, unless it is responding to errors that do not relate to
processing the contents of the encapsulated request; see Section 5.2. processing the contents of the Encapsulated Request; see Section 5.2.
An Oblivious Gateway Resource, if it receives any response from the An Oblivious Gateway Resource, if it receives any response from the
Target Resource, sends a single 200 response containing the Target Resource, sends a single 200 response containing the
encapsulated response. Like the request from the Client, this Encapsulated Response. Like the request from the Client, this
response MUST only contain those fields necessary to carry the response MUST only contain those fields necessary to carry the
encapsulated response: a 200 status code, a header field indicating Encapsulated Response: a 200 status code, a header field indicating
the content type, and the encapsulated response as the response the content type, and the Encapsulated Response as the response
content. As with requests, additional fields MAY be used to convey content. As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated information that does not reveal information about the Encapsulated
response. Response.
An Oblivious Gateway Resource that does not receive a response can An Oblivious Gateway Resource that does not receive a response can
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 an In order to achieve the privacy and security goals of the protocol,
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 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
skipping to change at line 865 skipping to change at line 856
Errors detected by the Oblivious Relay Resource and errors detected Errors detected by the Oblivious Relay Resource and errors detected
by the Oblivious Gateway Resource before removing protection by the Oblivious Gateway Resource before removing protection
(including being unable to remove encapsulation for any reason) (including being unable to remove encapsulation for any reason)
result in the status code being sent without protection in response result in the status code being sent without protection in response
to the POST request made to that resource. to the POST request made to that resource.
Errors detected by the Oblivious Gateway Resource after successfully Errors detected by the Oblivious Gateway Resource after successfully
removing encapsulation and errors detected by the Target Resource removing encapsulation and errors detected by the Target Resource
MUST be sent in an Encapsulated Response. This might be because the MUST be sent in an Encapsulated Response. This might be because the
Encapsulated Request is malformed or the Target Resource does not Encapsulated Request is malformed or the Target Resource does not
produce a response. In either case the Oblivious Gateway Resource produce a response. In either case, the Oblivious Gateway Resource
can generate a response with an appropriate error status code (such can generate a response with an appropriate error status code (such
as 400 (Bad Request) or 504 (Gateway Timeout); see Section 15.5.1 of as 400 (Bad Request) or 504 (Gateway Timeout); see Sections 15.5.1
[HTTP] and Section 15.6.5 of [HTTP], respectively). This response is and 15.6.5 of [HTTP], respectively). This response is encapsulated
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. An Oblivious Gateway Resource problem-types#ohttp-key" is defined in this section. An Oblivious
MAY use this problem type in a response to indicate that an Gateway Resource MAY use this problem type in a response to indicate
Encapsulated Request used an outdated or incorrect key configuration. that an Encapsulated Request used an outdated or incorrect key
configuration.
Figure 7 shows an example response in HTTP/1.1 format. Figure 7 shows an example response in HTTP/1.1 format.
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json Content-Type: application/problem+json
Content-Length: 106 Content-Length: 106
{"type":"https://iana.org/assignments/http-problem-types#ohttp-key", {"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"} "title": "key identifier unknown"}
skipping to change at line 914 skipping to change at line 906
subject to observation or modification by an Oblivious Relay subject to observation or modification by an Oblivious Relay
Resource. A Client might manage the risk of an outdated key Resource. A Client might manage the risk of an outdated key
configuration using a heuristic approach whereby it periodically configuration using a heuristic approach whereby it periodically
refreshes its key configuration if it receives a response with an refreshes its key configuration if it receives a response with an
error status code that has not been encapsulated. error status code that has not been encapsulated.
6. Security Considerations 6. Security Considerations
In this design, a Client wishes to make a request to an Oblivious In this design, a Client wishes to make a request to an Oblivious
Gateway Resource that is forwarded to a Target Resource. The Client Gateway Resource that is forwarded to a Target Resource. The Client
wishes to make this request without linking that request with either: wishes to make this request without linking that request with either
of the following:
1. The identity at the network and transport layer of the Client * The identity at the network and transport layer of the Client
(that is, the Client IP address and TCP or UDP port number the (that is, the Client IP address and TCP or UDP port number the
Client uses to create a connection). Client uses to create a connection).
2. Any other request the Client might have made in the past or might * Any other request the Client might have made in the past or might
make in the future. make in the future.
In order to ensure this, the Client selects a relay (that serves the In order to ensure this, the Client selects a relay (that serves the
Oblivious Relay Resource) that it trusts will protect this Oblivious Relay Resource) that it trusts will protect this
information by forwarding the Encapsulated Request and Response information by forwarding the Encapsulated Request and Response
without passing it to the server (that serves the Oblivious Gateway without passing it to the server (that serves the Oblivious Gateway
Resource). Resource).
In this section, a deployment where there are three entities is In this section, a deployment where there are three entities is
considered: considered:
* A Client makes requests and receives responses * A Client makes requests and receives responses.
* A relay operates the Oblivious Relay Resource * A relay operates the Oblivious Relay Resource.
* A server operates both the Oblivious Gateway Resource and the * A server operates both the Oblivious Gateway Resource and the
Target Resource Target Resource.
Section 6.10 discusses the security implications for a case where Section 6.10 discusses the security implications for a case where
different servers operate the Oblivious Gateway Resource and Target different servers operate the Oblivious Gateway Resource and Target
Resource. Resource.
Requests from the Client to Oblivious Relay Resource and from Requests from the Client to Oblivious Relay Resource and from
Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS
in order to provide unlinkability in the presence of a network in order to provide unlinkability in the presence of a network
observer. observer.
skipping to change at line 960 skipping to change at line 953
Resource. However, colocation of the Oblivious Gateway Resource and Resource. However, colocation of the Oblivious Gateway Resource and
Target Resource simplifies the interactions between those resources Target Resource simplifies the interactions between those resources
without affecting Client privacy. without affecting Client privacy.
As a consequence of this configuration, Oblivious HTTP prevents As a consequence of this configuration, Oblivious HTTP prevents
linkability described above. Informally, this means: linkability described above. Informally, this means:
1. Requests and responses are known only to Clients and Oblivious 1. Requests and responses are known only to Clients and Oblivious
Gateway Resources. In particular, the Oblivious Relay Resource Gateway Resources. In particular, the Oblivious Relay Resource
knows the origin and destination of an Encapsulated Request and knows the origin and destination of an Encapsulated Request and
Response, yet does not know the decrypted contents. Likewise, Response, yet it does not know the decrypted contents. Likewise,
Oblivious Gateway Resources learn only the Oblivious Relay Oblivious Gateway Resources learn only the Oblivious Relay
Resource and the decrypted request. No entity other than the Resource and the decrypted request. No entity other than the
Client can see the plaintext request and response and can Client can see the plaintext request and response and can
attribute them to the Client. attribute them to the Client.
2. Oblivous Gateway Resources, and therefore Target Resources, 2. Oblivious Gateway Resources, and therefore Target Resources,
cannot link requests from the same Client in the absence of cannot link requests from the same Client in the absence of
unique per-Client keys. unique per-Client keys.
Traffic analysis that might affect these properties are outside the Traffic analysis that might affect these properties is outside the
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
Clients make policy decisions about target connections, e.g., to Clients make policy decisions about target connections, e.g., to
apply certificate pinning, are incompatible with Oblivious HTTP. In apply certificate pinning, are incompatible with Oblivious HTTP. In
such cases, alternative technologies such as HTTP CONNECT such cases, alternative technologies such as HTTP CONNECT
(Section 9.3.6 of [HTTP]) can be used. Applications could implement (Section 9.3.6 of [HTTP]) can be used. Applications could implement
related policies on key configurations and relay connections, though related policies on key configurations and relay connections, though
these might not provide the same properties as policies enforced these might not provide the same properties as policies enforced
directly on target connections. When this difference is relevant, directly on target connections. Instead, when this difference is
applications can instead connect directly to the target at the cost relevant, applications can connect directly to the target at the cost
of either privacy or performance. of either privacy or performance.
Clients cannot carry connection-level state between requests as they Clients cannot carry connection-level state between requests as they
only establish direct connections to the relay responsible for the only establish direct connections to the relay responsible for the
Oblivious Relay resource. However, the content of requests might be Oblivious Relay Resource. However, the content of requests might be
used by a server to correlate requests. Cookies [COOKIES] are the used by a server to correlate requests. Cookies [COOKIES] are the
most obvious feature that might be used to correlate requests, but most obvious feature that might be used to correlate requests, but
any identity information and authentication credentials might have any identity information and authentication credentials might have
the same effect. Clients also need to treat information learned from the same effect. Clients also need to treat information learned from
responses with similar care when constructing subsequent requests, responses with similar care when constructing subsequent requests,
which includes the identity of resources. which includes the identity of resources.
Clients MUST generate a new HPKE context for every request, using a Clients MUST generate a new HPKE context for every request, using a
good source of entropy ([RANDOM]) for generating keys. Key reuse not good source of entropy [RANDOM] for generating keys. Key reuse not
only risks requests being linked, reuse could expose request and only risks requests being linked but also could expose request and
response contents to the relay. response contents to the relay.
The request the Client sends to the Oblivious Relay Resource only The request the Client sends to the Oblivious Relay Resource only
requires minimal information; see Section 5. The request that requires minimal information; see Section 5. The request that
carries the Encapsulated Request and is sent to the Oblivious Relay carries the Encapsulated Request and that is sent to the Oblivious
Resource MUST NOT include identifying information unless the Client Relay Resource MUST NOT include identifying information unless the
can trust that this information is removed by the relay. A Client Client can trust that this information is removed by the relay. A
MAY include information only for the Oblivious Relay Resource in Client MAY include information only for the Oblivious Relay Resource
header fields identified by the Connection header field if it trusts in header fields identified by the Connection header field if it
the relay to remove these as required by Section 7.6.1 of [HTTP]. trusts the relay to remove these, as required by Section 7.6.1 of
The Client needs to trust that the relay does not replicate the [HTTP]. The Client needs to trust that the relay does not replicate
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 1062 skipping to change at line 1055
removes this privacy risk. removes this privacy risk.
Secondly, generic implementations are often configured to augment Secondly, generic implementations are often configured to augment
requests with information about the Client, such as the Via field or requests with information about the Client, such as the Via field or
the Forwarded field [FORWARDED]. A relay MUST NOT add information the Forwarded field [FORWARDED]. A relay MUST NOT add information
when forwarding requests that might be used to identify Clients, when forwarding requests that might be used to identify Clients,
except for information that a Client is aware of; see Section 6.2.1. except for information that a Client is aware of; see Section 6.2.1.
Finally, a relay can also generate responses, though it is assumed to Finally, a relay can also generate responses, though it is assumed to
not be able to examine the content of a request (other than to 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 observe the choice of key identifier, KDF, and AEAD); therefore, it
assumed that it cannot generate an Encapsulated Response. is also assumed that it cannot generate an Encapsulated Response.
6.2.1. Differential Treatment 6.2.1. Differential Treatment
A relay MAY add information to requests if the Client is aware of the A relay MAY add information to requests if the Client is aware of the
nature of the information that could be added. Any addition MUST NOT nature of the information that could be added. Any addition MUST NOT
include information that uniquely and permanently identifies the include information that uniquely and permanently identifies the
Client, including any pseudonymous identifier. Information added by Client, including any pseudonymous identifier. Information added by
the relay - beyond what is already revealed through encapsulated the relay -- beyond what is already revealed through Encapsulated
requests from Clients - can reduce the size of the anonymity set of Requests from Clients -- can reduce the size of the anonymity set of
Clients at a gateway. Clients at a gateway.
A Client does not need to be aware of the exact value added for each A Client does not need to be aware of the exact value added for each
request, but needs to know the range of possible values the relay request but needs to know the range of possible values the relay
might use. How a Client might learn about added information is not might use. How a Client might learn about added information is not
defined in this document. defined in this document.
Moreover, relays MAY apply differential treatment to Clients that Moreover, relays MAY apply differential treatment to Clients that
engage in abusive behavior, e.g., by sending too many requests in engage in abusive behavior, e.g., by sending too many requests in
comparison to other Clients, or as a response to rate limits comparison to other Clients, or as a response to rate limits signaled
signalled from the gateway. Any such differential treatment can from the gateway. Any such differential treatment can reveal
reveal information to the gateway that would not be revealed information to the gateway that would not be revealed otherwise and
otherwise and therefore reduce the size of the anonymity set of therefore reduce the size of the anonymity set of Clients using a
Clients using a gateway. For example, if a relay chooses to rate gateway. For example, if a relay chooses to rate limit or block an
limit or block an abusive Client, this means that any Client requests abusive Client, this means that any Client requests that are not
which are not treated this way are known to be non-abusive by the treated this way are known to be non-abusive by the gateway. Clients
gateway. Clients need to consider the likelihood of such need to consider the likelihood of such differential treatment and
differential treatment and the privacy risks when using a relay. the privacy risks when using a relay.
Some patterns of abuse cannot be detected without access to the Some patterns of abuse cannot be detected without access to the
request that is made to the target. This means that only the gateway request that is made to the target. This means that only the gateway
or target are in a position to identify abuse. A gateway MAY send or the target is in a position to identify abuse. A gateway MAY send
signals toward the relay to provide feedback about specific requests. signals toward the relay to provide feedback about specific requests.
For example, a gateway could respond differently to requests it For example, a gateway could respond differently to requests it
cannot decapsulate, as mentioned in Section 5.2. A relay that acts cannot decapsulate, as mentioned in Section 5.2. A relay that acts
on this feedback could - either inadvertently or by design - lead to on this feedback could -- either inadvertently or by design -- lead
Client deanonymization. to Client deanonymization.
6.2.2. Denial of Service 6.2.2. Denial of Service
As there are privacy benefits from having a large rate of requests As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see Section 6.2.3), servers that operate forwarded by the same relay (see Section 6.2.3), servers that operate
the Oblivious Gateway Resource might need an arrangement with the Oblivious Gateway Resource might need an arrangement with
Oblivious Relay Resources. This arrangement might be necessary to Oblivious Relay Resources. This arrangement might be necessary to
prevent having the large volume of requests being classified as an prevent having the large volume of requests being classified as an
attack by the server. attack by the server.
If a server accepts a larger volume of requests from a relay, it If a server accepts a larger volume of requests from a relay, it
needs to trust that the relay does not allow abusive levels of needs to trust that the relay does not allow abusive levels of
request volumes from Clients. That is, if a server allows requests request volumes from Clients. That is, if a server allows requests
from the relay to be exempt from rate limits, the server might want from the relay to be exempt from rate limits, the server might want
to ensure that the relay applies a rate limiting policy that is to ensure that the relay applies a rate-limiting policy that is
acceptable to the server. acceptable to the server.
Servers that enter into an agreement with a relay that enables a Servers that enter into an agreement with a relay that enables a
higher request rate might choose to authenticate the relay to enable higher request rate might choose to authenticate the relay to enable
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
consent - or at least awareness - of Clients. consent -- or at least awareness -- of Clients.
A relay that forwards large volumes of exchanges can provide better A relay that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched. privacy by providing larger sets of messages that need to be matched.
Traffic analysis is not restricted to network observers. A malicious Traffic analysis is not restricted to network observers. A malicious
Oblivious Relay Resource could use traffic analysis to learn Oblivious Relay Resource could use traffic analysis to learn
information about otherwise encrypted requests and responses relayed information about otherwise encrypted requests and responses relayed
between Clients and gateways. An Oblivious Relay Resource terminates between Clients and gateways. An Oblivious Relay Resource terminates
TLS connections from Clients, so they see message boundaries. This TLS connections from Clients, so they see message boundaries. This
privileged position allows for richer feature extraction from privileged position allows for richer feature extraction from
encrypted data, which might improve traffic analysis. encrypted data, which might improve traffic analysis.
Clients and Oblivious Gateway Resources can use padding to reduce the Clients and Oblivious Gateway Resources can use padding to reduce the
effectiveness of traffic analysis. Padding is a capability provided effectiveness of traffic analysis. Padding is a capability provided
by binary HTTP messages; see Section 3.8 of [BINARY]. If the by binary HTTP messages; see Section 3.8 of [BINARY]. If the
encapsulation method described in this document is used to protect a encapsulation method described in this document is used to protect a
different message type (see Section 4.6), that message format might different message type (see Section 4.6), that message format might
need to include padding support. Oblivious Relay Resources can also need to include padding support. Oblivious Relay Resources can also
use padding for the same reason, but need to operate at the HTTP use padding for the same reason but need to operate at the HTTP layer
layer since they cannot manipulate binary HTTP messages; for example, since they cannot manipulate binary HTTP messages; for example, see
see Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]). Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]).
6.3. Server Responsibilities 6.3. Server Responsibilities
The Oblivious Gateway Resource can be operated by a different entity The Oblivious Gateway Resource can be operated by a different entity
than the Target Resource. However, this means that the Client needs than the Target Resource. However, this means that the Client needs
to trust the Oblivious Gateway Resource not to modify requests or to trust the Oblivious Gateway Resource not to modify requests or
responses. This analysis concerns itself with a deployment scenario responses. This analysis concerns itself with a deployment scenario
where a single server provides both the Oblivious Gateway Resource where a single server provides both the Oblivious Gateway Resource
and Target Resource. and Target Resource.
skipping to change at line 1188 skipping to change at line 1181
help protect against such attacks; see Section 6.2.3. help protect against such attacks; see Section 6.2.3.
If separate entities provide the Oblivious Gateway Resource and If separate entities provide the Oblivious Gateway Resource and
Target Resource, these entities might need an arrangement similar to Target Resource, these entities might need an arrangement similar to
that between server and relay for managing denial of service; see that between server and relay for managing denial of service; see
Section 6.2.2. Moreover, the Oblivious Gateway Resource SHOULD have Section 6.2.2. Moreover, the Oblivious Gateway Resource SHOULD have
some mechanism to ensure that the Oblivious Gateway Resource is not some mechanism to ensure that the Oblivious Gateway Resource is not
misused as a relay for HTTP messages to an arbitrary Target Resource, misused as a relay for HTTP messages to an arbitrary Target Resource,
such as an allowlist. such as an allowlist.
Non-secure requests - such as those with the "http" scheme as opposed Non-secure requests -- such as those with the "http" scheme as
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway opposed to the "https" scheme -- SHOULD NOT be used if the Oblivious
and Target Resources are not on the same origin. If messages are Gateway and Target Resources are not on the same origin. If messages
forwarded between these resources without the protections afforded by are forwarded between these resources without the protections
HTTPS, they could be inspected or modified by a network attacker. afforded by HTTPS, they could be inspected or modified by a network
Note that a request could be forwarded without protection if the two attacker. Note that a request could be forwarded without protection
resources share an origin. if the two resources share an origin.
6.4. Key Management 6.4. Key Management
An Oblivious Gateway Resource needs to have a plan for replacing An Oblivious Gateway Resource needs to have a plan for replacing
keys. This might include regular replacement of keys, which can be keys. This might include regular replacement of keys, which can be
assigned new key identifiers. If an Oblivious Gateway Resource assigned new key identifiers. If an Oblivious Gateway Resource
receives a request that contains a key identifier that it does not receives a request that contains a key identifier that it does not
understand or that corresponds to a key that has been replaced, the understand or that corresponds to a key that has been replaced, the
server can respond with an HTTP 422 (Unprocessable Content) status server can respond with an HTTP 422 (Unprocessable Content) status
code. code.
skipping to change at line 1225 skipping to change at line 1218
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 to ensure that replayed to either reject replayed requests or ensure that replayed requests
requests have no adverse effects on their operation. This section have no adverse effect on their operation. This section describes
describes some approaches that are universally applicable and some approaches that are universally applicable and suggestions for
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.
HTTP/1.1 [HTTP/1.1] provides no equivalent signal. Connection HTTP/1.1 [HTTP/1.1] provides no equivalent signal. Connection
failures or interruptions are not sufficient signals that no failures or interruptions are not sufficient signals that no
skipping to change at line 1278 skipping to change at line 1271
satisfactory for some applications, particularly those that involve satisfactory for some applications, particularly those that involve
the submission of data to a server. The use of idempotent methods 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 might be of some use in managing replay risk, though it is important
to recognize that different idempotent requests can be combined to be to recognize that different idempotent requests can be combined to be
not idempotent. not idempotent.
Even without replay prevention, the server-chosen response_nonce Even without replay prevention, the server-chosen response_nonce
field ensures that responses have unique AEAD keys and nonces even field ensures that responses have unique AEAD keys and nonces even
when requests are replayed. when requests are replayed.
6.5.1. Use of Date for Anti-Replay 6.5.1. Use of Date for Anti-replay
Clients SHOULD include a Date header field in Encapsulated Requests, Clients SHOULD include a Date header field in Encapsulated Requests,
unless the Client has prior knowledge that indicates that the unless the Client has prior knowledge that indicates that the
Oblivious Gateway Resource does not use Date for anti-replay Oblivious Gateway Resource does not use Date for anti-replay
purposes. purposes.
Though HTTP requests often do not include a Date header field, the 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 value of this field might be used by a server to limit the amount of
requests it needs to track if it needs to prevent replay attacks. requests it needs to track if it needs to prevent replay attacks.
skipping to change at line 1303 skipping to change at line 1296
be unique to each request, is sufficient. The Oblivious Gateway be unique to each request, is sufficient. The Oblivious Gateway
Resource can reject any request that is the same as one that was Resource can reject any request that is the same as one that was
previously answered within that time window or if the Date header previously answered within that time window or if the Date header
field from the decrypted request is outside of the current time field from the decrypted request is outside of the current time
window. window.
Oblivious Gateway Resources might need to allow for the time it takes Oblivious Gateway Resources might need to allow for the time it takes
requests to arrive from the Client, with a time window that is large requests to arrive from the Client, with a time window that is large
enough to allow for differences in clocks. Insufficient tolerance of enough to allow for differences in clocks. Insufficient tolerance of
time differences could result in valid requests being unnecessarily time differences could result in valid requests being unnecessarily
rejected. Beyond allowing for multiple round trip times -- to rejected. Beyond allowing for multiple round-trip times -- to
account for retransmission -- network delays are unlikely to be account for retransmission -- network delays are unlikely to be
significant in determining the size of the window, unless all significant in determining the size of the window, unless all
potential Clients are known to have excellent time-keeping. A potential Clients are known to have excellent timekeeping. A
specific window size might need to be determined experimentally. specific window size might need to be determined experimentally.
Oblivious Gateway Resources MUST NOT treat the time window as secret Oblivious Gateway Resources MUST NOT treat the time window as secret
information. An attacker can actively probe with different values information. An attacker can actively probe with different values
for the Date field to determine the time window over which the server for the Date field to determine the time window over which the server
will accept responses. will accept responses.
6.5.2. Correcting Clock Differences 6.5.2. Correcting Clock Differences
An Oblivious Gateway Resource can reject requests that contain a Date An Oblivious Gateway Resource can reject requests that contain a Date
skipping to change at line 1368 skipping to change at line 1361
|<============================+<-------------+ |<============================+<-------------+
| | | | | | | |
| Request | | | | Request | | |
| + Updated Date | | | | + Updated Date | | |
+============================>+------------->| +============================>+------------->|
| | | | | | | |
Figure 9: Retrying with an Updated Date Field Figure 9: Retrying with an Updated Date Field
Retrying immediately allows the Oblivious Gateway Resource to measure Retrying immediately allows the Oblivious Gateway Resource to measure
the round trip time to the Client. The observed delay might reveal the round-trip time to the Client. The observed delay might reveal
something about the location of the Client. Clients could delay something about the location of the Client. Clients could delay
retries to add some uncertainty to any observed delay. retries to add some uncertainty to any observed delay.
Intermediaries can sometimes rewrite the Date field when forwarding Intermediaries can sometimes rewrite the Date field when forwarding
responses. This might cause problems if the Oblivious Gateway responses. This might cause problems if the Oblivious Gateway
Resource and intermediary clocks differ by enough to cause the retry Resource and intermediary clocks differ by enough to cause the retry
to be rejected. Therefore, Clients MUST NOT retry a request with an to be rejected. Therefore, Clients MUST NOT retry a request with an
adjusted date more than once. adjusted date more than once.
Oblivious Gateway Resources that condition their responses on the Oblivious Gateway Resources that condition their responses on the
skipping to change at line 1431 skipping to change at line 1424
limited by regular rotation of server keys. limited by regular rotation of server keys.
6.8. Client Clock Exposure 6.8. Client Clock Exposure
Including a Date field in requests reveals some information about the Including a Date field in requests reveals some information about the
Client clock. This might be used to fingerprint Clients [UWT] or to Client clock. This might be used to fingerprint Clients [UWT] or to
identify Clients that are vulnerable to attacks that depend on identify Clients that are vulnerable to attacks that depend on
incorrect clocks. incorrect clocks.
Clients can randomize the value that they provide for Date to obscure Clients can randomize the value that they provide for Date to obscure
the true value of their clock and reduce the chance of linking of the true value of their clock and reduce the chance of linking
requests over time. However, this increases the risk that their requests over time. However, this increases the risk that their
request is rejected as outside the acceptable window. request is rejected as outside the acceptable window.
6.9. Media Type Security 6.9. Media Type Security
The key configuration media type defined in Section 3.2 represents The key configuration media type defined in Section 3.2 represents
keying material. The content of this media type is not active (see keying material. The content of this media type is not active (see
Section 4.6 of [RFC6838]), but it governs how a Client might interact Section 4.6 of [RFC6838]), but it governs how a Client might interact
with an Oblivious Gateway Resource. The security implications of with an Oblivious Gateway Resource. The security implications of
processing it are described in Section 6.1; privacy implications are processing it are described in Section 6.1; privacy implications are
described in Section 7. described in Section 7.
The security implications of handling the message media types defined The security implications of handling the message media types defined
in Section 4.5 is covered in other parts of this section in more in Section 4.5 is covered in other parts of this section in more
detail. However, these message media types are also encrypted detail. However, these message media types are also encrypted
encapsulations of HTTP requests and responses. encapsulations of HTTP requests and responses.
HTTP messages contain content, which can use any media type. In HTTP messages contain content, which can use any media type. In
particular, requests are processed by an Oblivious Target Resource, particular, requests are processed by an Oblivious Target Resource,
which - as an HTTP resource - defines how content is processed; see which -- as an HTTP resource -- defines how content is processed; see
Section 3.1 of [HTTP]. HTTP clients can also use resource identity Section 3.1 of [HTTP]. HTTP clients can also use resource identity
and response content to determine how content is processed. and response content to determine how content is processed.
Consequently, the security considerations of Section 17 of [HTTP] Consequently, the security considerations of Section 17 of [HTTP]
also apply to the handling of the content of these media types. also apply to the handling of the content of these media types.
6.10. Separate Gateway and Target 6.10. Separate Gateway and Target
This document generally assumes that the same entity operates the This document generally assumes that the same entity operates the
Oblivious Gateway Resource and the Target Resource. However, as the Oblivious Gateway Resource and the Target Resource. However, as the
Oblivious Gateway Resource performs generic HTTP processing, the use Oblivious Gateway Resource performs generic HTTP processing, the use
skipping to change at line 1495 skipping to change at line 1488
the ability of the Target Resource to implement policy exemptions, the ability of the Target Resource to implement policy exemptions,
such as only forwarding requests toward specific Target Resources such as only forwarding requests toward specific Target Resources
according to an allowlist; see Section 6.3. according to an allowlist; see Section 6.3.
7. Privacy Considerations 7. Privacy Considerations
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 Oblivious Gateway Resource Oblivious Gateway key configuration, and the Oblivious Gateway
URI. A configuration is active if Clients can successfully use it Resource URI. A configuration is active if Clients can successfully
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 1554 skipping to change at line 1547
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 Section 9.2 and identified using the media types defined in Sections 9.2 and 9.3.
Section 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
Please update the "Media Types" registry at IANA has registered the following media types in the "Media Types"
https://iana.org/assignments/media-types registry at <https://iana.org/assignments/media-types>, following the
(https://iana.org/assignments/media-types) for the media types procedures of [RFC6838]: "application/ohttp-keys" (Section 9.1),
"application/ohttp-keys" (Section 9.1), "message/ohttp-req" "message/ohttp-req" (Section 9.2), and "message/ohttp-res"
(Section 9.2), and "message/ohttp-res" (Section 9.3), following the (Section 9.3).
procedures of [RFC6838].
Please update the "HTTP Problem Types" registry at IANA has added the following types to the "HTTP Problem Types"
https://iana.org/assignments/http-problem-types registry at <https://iana.org/assignments/http-problem-types>: "date"
(https://iana.org/assignments/http-problem-types) for the types (Section 9.4) and "ohttp-key" (Section 9.5).
"date" (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: this specification 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: Magic number(s): N/A Additional information:
Deprecated alias names for this type: N/A Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A Deprecated alias names for this type: N/A
Person and email address to contact for further information: see Aut
hors' Addresses section File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
See Authors' Addresses section
Intended usage: COMMON 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: this specification 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: Magic number(s): N/A Additional information:
Deprecated alias names for this type: N/A Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A Deprecated alias names for this type: N/A
Person and email address to contact for further information: see Aut
hors' Addresses section File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
See Authors' Addresses section
Intended usage: COMMON 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: this specification 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: Magic number(s): N/A Additional information:
Deprecated alias names for this type: N/A Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A Deprecated alias names for this type: N/A
Person and email address to contact for further information: see Aut
hors' Addresses section File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
See Authors' Addresses section
Intended usage: COMMON 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 are requested to create a new entry in the "HTTP Problem Type" IANA has added a new entry in the "HTTP Problem Types" registry
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
Reference: Section 6.5.2 of this document Reference: Section 6.5.2 of RFC 9458
9.5. Registration of "ohttp-key" Problem Type 9.5. Registration of "ohttp-key" Problem Type
IANA are requested to create a new entry in the "HTTP Problem Type" IANA has added a new entry in the "HTTP Problem Types" registry
registry established by [PROBLEM]. established by [PROBLEM].
Type URI: https://iana.org/assignments/http-problem-types#ohttp-key Type URI: https://iana.org/assignments/http-problem-types#ohttp-key
Title: Oblivious HTTP key configuration not acceptable Title: Oblivious HTTP key configuration not acceptable
Recommended HTTP Status Code: 400 Recommended HTTP Status Code: 400
Reference: Section 5.3 of this document Reference: Section 5.3 of RFC 9458
10. References 10. References
10.1. Normative References 10.1. Normative References
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80, [ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/rfc/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP [BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022, Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
<https://www.rfc-editor.org/rfc/rfc9292>. <https://www.rfc-editor.org/info/rfc9292>.
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid [HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. February 2022, <https://www.rfc-editor.org/info/rfc9180>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[HTTP-CACHING] [HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111, Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>. <https://www.rfc-editor.org/info/rfc9111>.
[PROBLEM] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details [PROBLEM] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", Work in Progress, Internet-Draft, draft- for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
ietf-httpapi-rfc7807bis-06, 1 March 2023, <https://www.rfc-editor.org/info/rfc9457>.
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
rfc7807bis-06>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 10.2. Informative References
[CLOCKSKEW] [CLOCKSKEW]
Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R., Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
"Where the Wild Warnings Are: Root Causes of Chrome HTTPS "Where the Wild Warnings Are: Root Causes of Chrome HTTPS
Certificate Errors", Proceedings of the 2017 ACM SIGSAC Certificate Errors", Proceedings of the 2017 ACM SIGSAC
Conference on Computer and Communications Security, Conference on Computer and Communications Security,
DOI 10.1145/3133956.3134007, October 2017, DOI 10.1145/3133956.3134007, October 2017,
<https://doi.org/10.1145/3133956.3134007>. <https://doi.org/10.1145/3133956.3134007>.
[CONSISTENCY] [CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress, "Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-00, Internet-Draft, draft-ietf-privacypass-key-consistency-01,
24 October 2022, <https://datatracker.ietf.org/doc/html/ 10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-00>. draft-ietf-privacypass-key-consistency-01>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The [DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", August 2004, Second-Generation Onion Router", May 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor- <https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>. design.html>.
[FIELDING] Fielding, R. T., "Architectural Styles and the Design of [FIELDING] Fielding, R. T., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, Network-based Software Architectures", January 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/ <https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[FORWARDED] [FORWARDED]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014, RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/rfc/rfc7239>. <https://www.rfc-editor.org/info/rfc7239>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[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/rfc/rfc9230>. <https://www.rfc-editor.org/info/rfc9230>.
[ODOH-PETS] [ODOH-PETS]
Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T., Singanamalla, S., Chunhapanya, S., Hoyland, J., Vavruša,
Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A. M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan,
Wood, "Oblivious DNS over HTTPS (ODoH): A Practical N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A
Privacy Enhancement to DNS", 7 January 2021, Practical Privacy Enhancement to DNS", PoPETS Proceedings
Volume 2021, Issue 4, pp. 575-592, DOI 10.2478/popets-
2021-0085, January 2021,
<https://www.petsymposium.org/2021/files/papers/issue4/ <https://www.petsymposium.org/2021/files/papers/issue4/
popets-2021-0085.pdf>. popets-2021-0085.pdf>.
[OHTTP-ANALYSIS] [OHTTP-ANALYSIS]
Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August Hoyland, J., "Tamarin Model of Oblivious HTTP", commit
2021, <https://github.com/cloudflare/ohttp-analysis>. 6824eee, October 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", 14 and Scalable Computation of Aggregate Statistics", March
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,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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/rfc/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/rfc/rfc6570>. <https://www.rfc-editor.org/info/rfc6570>.
[UWT] Nottingham, M., "Unsanctioned Web Tracking", 17 July 2015, [UWT] Nottingham, M., "Unsanctioned Web Tracking", W3C TAG
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/rfc/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
intermediate values) are shown in hexadecimal. The request and intermediate values) are shown in hexadecimal. The request and
response here are minimal; the purpose of this example is to show the response here are minimal; the purpose of this example is to show the
cryptographic operations. In this example, the Client is configured cryptographic operations. In this example, the Client is configured
with the Oblivious Relay Resource URI of with the Oblivious Relay Resource URI of
https://proxy.example.org/request.example.net/proxy, and the proxy is https://proxy.example.org/request.example.net/proxy, and the proxy is
configured to map requests to this URI to the Oblivious Gateway configured to map requests to this URI to the Oblivious Gateway
Resource URI https://example.com/oblivious/request. The Target Resource URI https://example.com/oblivious/request. The Target
Resource URI, i.e., the resource the Client ultimately wishes to Resource URI, i.e., the resource the Client ultimately wishes to
query, is https://example.com. query, is https://example.com.
To begin the process, the Oblivious Gateway Resource generates a key To begin the process, the Oblivious Gateway Resource generates a key
pair. In this example the server chooses DHKEM(X25519, HKDF-SHA256) pair. In this example, the server chooses DHKEM(X25519, HKDF-SHA256)
and generates an X25519 key pair [X25519]. The X25519 secret key is: and generates an X25519 key pair [X25519]. The X25519 secret key is:
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a 3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
The Oblivious Gateway Resource constructs a key configuration that The Oblivious Gateway Resource constructs a key configuration that
includes the corresponding public key as follows: includes the corresponding public key as follows:
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e 01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003 79815500080001000100010003
skipping to change at line 1907 skipping to change at line 1911
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 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 1996 skipping to change at line 2000
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store Cache-Control: private, no-store
Content-Type: message/ohttp-res Content-Type: message/ohttp-res
Content-Length: 38 Content-Length: 38
<content is the Encapsulated Response> <content is the Encapsulated Response>
The same response might then be generated by the Oblivious Relay The same response might then be generated by the Oblivious Relay
Resource which might change as little as the Date header. The Client Resource, which might change as little as the Date header. The
is then able to use the HPKE context it created and the nonce from Client is then able to use the HPKE context it created and the nonce
the Encapsulated Response to construct the AEAD key and nonce and from the Encapsulated Response to construct the AEAD key and nonce
decrypt the response. and decrypt the response.
Acknowledgments Acknowledgments
This design is based on a design for Oblivious DoH, described in This design is based on a design for Oblivious DNS (queries) over
[ODOH]. David Benjamin, Mark Nottingham, and Eric Rescorla made HTTPS (DoH), described in [ODOH]. David Benjamin, Mark Nottingham,
technical contributions. The authors also thank Ralph Giles, Lucas and Eric Rescorla made technical contributions. The authors also
Pardue, and Tommy Pauly for invaluable assistance. thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable
assistance.
Index
C E K O T
C
Client Section 1, Paragraph 3; Section 2, Paragraph 1;
Section 2, Paragraph 3; Section 2, Paragraph 3; Section 2,
Paragraph 6, Item 1; Section 2, Paragraph 6, Item 2;
Section 2, Paragraph 6, Item 3; Section 2, Paragraph 8, Item
2; Section 2, Paragraph 8, Item 3; Section 2, Paragraph 9;
Section 2, Paragraph 9; Section 2, Paragraph 9; Section 2.2;
Section 2.2, Paragraph 3.2.1; Section 2.2, Paragraph 3.2.1;
Section 3, Paragraph 1; Section 3, Paragraph 2; Section 3,
Paragraph 2; Section 3, Paragraph 3; Section 4.3, Paragraph
2, Item 3; Section 4.3, Paragraph 3; Section 4.4, Paragraph
6; Section 4.6, Paragraph 1; Section 5, Paragraph 1;
Section 5, Paragraph 2; Section 5, Paragraph 3; Section 5,
Paragraph 4; Section 5, Paragraph 4; Section 5, Paragraph 4;
Section 5, Paragraph 8; Section 5.2, Paragraph 4;
Section 5.2, Paragraph 4; Section 5.3, Paragraph 4;
Section 5.3, Paragraph 4; Section 5.3, Paragraph 4;
Section 5.3, Paragraph 4; Section 6, Paragraph 1; Section 6,
Paragraph 1; Section 6, Paragraph 2, Item 1; Section 6,
Paragraph 2, Item 1; Section 6, Paragraph 2, Item 1;
Section 6, Paragraph 2, Item 2; Section 6, Paragraph 3;
Section 6, Paragraph 5, Item 1; Section 6, Paragraph 7;
Section 6, Paragraph 8; Section 6, Paragraph 10, Item 1;
Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10,
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.2,
Paragraph 1; Section 6.2, Paragraph 2; Section 6.2,
Paragraph 4; Section 6.2, Paragraph 4; 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 3; Section 6.2.1, Paragraph 3; Section 6.2.1,
Paragraph 4; Section 6.2.3, Paragraph 3; Section 6.3,
Paragraph 1; Section 6.5, Paragraph 2; Section 6.5,
Paragraph 4; Section 6.5, Paragraph 6; Section 6.5.1,
Paragraph 1; Section 6.5.1, Paragraph 4; Section 6.5.2,
Paragraph 4; Section 6.5.2, Paragraph 5; Section 6.5.2,
Paragraph 5; Section 6.5.2, Paragraph 7; Section 6.5.2,
Paragraph 7; Section 6.7, Paragraph 2; Section 6.7,
Paragraph 2; Section 6.7, Paragraph 4; Section 6.8,
Paragraph 1; Section 6.9, Paragraph 1; Section 7, Paragraph
1; Section 7, Paragraph 1; Section 7, Paragraph 1;
Section 7, Paragraph 3; Section 7, Paragraph 3; Section 7,
Paragraph 4; Section 7, Paragraph 4; Section 7, Paragraph 5;
Section 7, Paragraph 5; Section 7, Paragraph 5; Section 7,
Paragraph 6; Appendix A, Paragraph 1; Appendix A, Paragraph
1; Appendix A, Paragraph 6; Appendix A, Paragraph 6;
Appendix A, Paragraph 8; Appendix A, Paragraph 8;
Appendix A, Paragraph 8; Appendix A, Paragraph 14;
Appendix A, Paragraph 16; Appendix A, Paragraph 36
Clients Section 1, Paragraph 8; Section 2.2, Paragraph 3.8.1;
Section 3, Paragraph 1; Section 3, Paragraph 3; Section 3,
Paragraph 3; Section 4.3, Paragraph 1; Section 4.4,
Paragraph 5; Section 4.4, Paragraph 5; Section 5, Paragraph
1; Section 5, Paragraph 2; Section 5.1, Paragraph 2;
Section 6, Paragraph 10, Item 1; Section 6.1, Paragraph 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 4; Section 6.1, Paragraph 4;
Section 6.1, Paragraph 5; Section 6.1, Paragraph 7;
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 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.3, Paragraph 5; Section 6.2.3, Paragraph 5;
Section 6.2.3, Paragraph 6; Section 6.5, Paragraph 1;
Section 6.5.1, Paragraph 1; Section 6.5.1, Paragraph 4;
Section 6.5.2, Paragraph 7; Section 6.5.2, Paragraph 8;
Section 6.5.2, Paragraph 10; Section 6.8, Paragraph 1;
Section 6.8, Paragraph 1; Section 6.8, Paragraph 2;
Section 7, Paragraph 1; Section 7, Paragraph 4; Section 7,
Paragraph 4; Section 7, Paragraph 4; Section 7, Paragraph 5;
Section 8.1, Paragraph 1; Section 8.2, Paragraph 2;
Section 8.3, Paragraph 1; Section 8.3, Paragraph 2
E
Encapsulated Request Section 2, Paragraph 2, Item 3;
Section 2, Paragraph 6, Item 3; Section 2, Paragraph 7;
Section 2.2; Section 2.2, Paragraph 3.10.1; Section 2.2,
Paragraph 3.12.1; Section 4, Paragraph 2, Item 1;
Section 4.1, Paragraph 3; Section 4.1, Paragraph 3;
Section 4.1, Paragraph 4; Section 4.1, Paragraph 4;
Section 4.1, Paragraph 6; Section 4.3, Paragraph 3;
Section 4.3, Paragraph 8; Section 4.3, Paragraph 8;
Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5,
Paragraph 1; Section 5, Paragraph 1; Section 5, Paragraph 1;
Section 5, Paragraph 1; Section 5.2, Paragraph 3;
Section 5.3, Paragraph 1; Section 6, Paragraph 3; Section 6,
Paragraph 10, Item 1; Section 6.1, Paragraph 6;
Section 6.2.3, Paragraph 2; Section 6.3, Paragraph 2;
Section 6.4, Paragraph 2; Section 6.5, Paragraph 2;
Section 6.10, Paragraph 2; Appendix A, Paragraph 14
Encapsulated Response Section 2.2; Section 2.2, Paragraph
3.10.1; Section 4, Paragraph 2, Item 2; Section 4.2,
Paragraph 3; Section 4.2, Paragraph 3; Section 4.2,
Paragraph 4; Section 4.2, Paragraph 4; Section 4.2,
Paragraph 6; Section 4.4, Paragraph 1; Section 4.4,
Paragraph 2, Item 7; Section 4.4, Paragraph 5; Section 5.2,
Paragraph 3; Section 5.2, Paragraph 4; Section 6.2,
Paragraph 5; Appendix A, Paragraph 24; Appendix A, Paragraph
32; Appendix A, Paragraph 36
K
key configuration Section 3, Paragraph 1; Section 3, Paragraph
1; Section 3, Paragraph 2; Section 3, Paragraph 3;
Section 3.1, Paragraph 1; Section 3.1, Paragraph 2;
Section 3.1, Paragraph 4; Section 3.2, Paragraph 1;
Section 3.2, Paragraph 2; Section 4.3, Paragraph 1;
Section 4.3, Paragraph 2, Item 3; Section 5.2, Paragraph 4;
Section 5.3, Paragraph 1; Section 5.3, Paragraph 4;
Section 5.3, Paragraph 4; Section 6.1, Paragraph 2;
Section 6.6, Paragraph 1; Section 6.6, Paragraph 1;
Section 6.9, Paragraph 1; Section 7, Paragraph 1; Section 7,
Paragraph 2; Section 9.1, Paragraph 1; Section 9.1,
Paragraph 2.18.1; Section 9.5, Paragraph 2.4.1; Appendix A,
Paragraph 1; Appendix A, Paragraph 4; Appendix A, Paragraph
6; Appendix A, Paragraph 8
key configurations Section 3, Paragraph 2; Section 3,
Paragraph 2; Section 3, Paragraph 3; Section 3.2, Paragraph
1; Section 6.1, Paragraph 3
O
Oblivious Gateway Resource Section 4.3, Paragraph 9.1.3
Oblivious Gateway Resource Section 1, Paragraph 6, Item 2;
Section 1, Paragraph 6, Item 3; Section 1, Paragraph 7;
Section 1, Paragraph 8; Section 2, Paragraph 2, Item 1;
Section 2, Paragraph 2, Item 1; Section 2, Paragraph 2, Item
2; Section 2, Paragraph 2, Item 3; Section 2, Paragraph 3;
Section 2, Paragraph 3; Section 2, Paragraph 3; Section 2,
Paragraph 5; Section 2, Paragraph 6, Item 5; Section 2,
Paragraph 7; Section 2, Paragraph 7; Section 2, Paragraph 8,
Item 1; Section 2, Paragraph 9; Section 2, Paragraph 9;
Section 2.1, Paragraph 1; Section 2.2, Paragraph 3.8.1;
Section 2.2; Section 3, Paragraph 1; Section 3.1, Paragraph
5.2.1; Section 3.1, Paragraph 5.10.1; Section 4.3, Paragraph
8; Section 4.3, Paragraph 9.1.1; Section 4.3, Paragraph
9.1.2; Section 4.3, Paragraph 9.1.3; Section 4.3, Paragraph
9, Item 4; Section 4.3, Paragraph 12; Section 4.4, Paragraph
1; Section 4.6, Paragraph 1; Section 5, Paragraph 2;
Section 5, Paragraph 2; Section 5, Paragraph 4; Section 5,
Paragraph 4; Section 5, Paragraph 5; Section 5, Paragraph 7;
Section 5, Paragraph 8; Section 5, Paragraph 9; Section 5,
Paragraph 10; Section 5.1, Paragraph 2; Section 5.2,
Paragraph 2; Section 5.2, Paragraph 3; Section 5.2,
Paragraph 3; Section 5.2, Paragraph 4; Section 5.3,
Paragraph 1; Section 5.3, Paragraph 4; Section 6, Paragraph
1; Section 6, Paragraph 3; Section 6, Paragraph 5, Item 3;
Section 6, Paragraph 6; Section 6, Paragraph 7; Section 6,
Paragraph 8; Section 6, Paragraph 8; Section 6.1, Paragraph
1; Section 6.1, Paragraph 2; Section 6.2, Paragraph 1;
Section 6.2, Paragraph 1; Section 6.2.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 4; Section 6.3, Paragraph 4;
Section 6.3, Paragraph 4; Section 6.4, Paragraph 1;
Section 6.4, Paragraph 1; Section 6.5.1, Paragraph 1;
Section 6.5.1, Paragraph 3; Section 6.5.1, Paragraph 3;
Section 6.5.1, Paragraph 3; Section 6.5.2, Paragraph 1;
Section 6.5.2, Paragraph 4; Section 6.5.2, Paragraph 5;
Section 6.5.2, Paragraph 7; Section 6.5.2, Paragraph 8;
Section 6.5.2, Paragraph 10; Section 6.5.2, Paragraph 10;
Section 6.7, Paragraph 3; Section 6.9, Paragraph 1;
Section 6.10, Paragraph 1; Section 6.10, Paragraph 1;
Section 6.10, Paragraph 3; Section 6.10, Paragraph 3;
Section 6.10, Paragraph 3; Section 6.10, Paragraph 3;
Section 6.10, Paragraph 4; Section 6.10, Paragraph 4;
Section 6.10, Paragraph 5; Section 7, Paragraph 1;
Section 7, Paragraph 2; Section 7, Paragraph 2; Section 7,
Paragraph 2; Section 8.2, Paragraph 1; Section 8.2,
Paragraph 1; Section 8.2, Paragraph 2; Appendix A, Paragraph
1; Appendix A, Paragraph 2; Appendix A, Paragraph 4;
Appendix A, Paragraph 8; Appendix A, Paragraph 18;
Appendix A, Paragraph 20; Appendix A, Paragraph 20;
Appendix A, Paragraph 34
Oblivious Gateway Resources Section 4.4, Paragraph 1;
Section 6, Paragraph 10, Item 1; Section 6, Paragraph 10,
Item 1; Section 6.1, Paragraph 1; Section 6.1, Paragraph 1;
Section 6.2.3, Paragraph 6; Section 6.5.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;
Section 8.2, Paragraph 2
Oblivious Relay and Gateway Resources Section 2, Paragraph 2,
Item 3; Section 7, Paragraph 2
Oblivious Relay Resource Section 1, Paragraph 6, Item 2;
Section 1, Paragraph 7; Section 1, Paragraph 8; Section 1,
Paragraph 8; Section 2, Paragraph 2, Item 3; Section 2,
Paragraph 6, Item 3; Section 2, Paragraph 6, Item 4;
Section 2, Paragraph 8, Item 1; Section 2, Paragraph 8, Item
2; Section 2.1, Paragraph 1; Section 2.2, Paragraph 3.2.1;
Section 2.2; Section 5, Paragraph 1; Section 5, Paragraph 1;
Section 5, Paragraph 1; Section 5, Paragraph 1; Section 5,
Paragraph 1; Section 5, Paragraph 2; Section 5, Paragraph 2;
Section 5, Paragraph 4; Section 5, Paragraph 4; Section 5,
Paragraph 4; Section 5, Paragraph 5; Section 5, Paragraph 5;
Section 5, Paragraph 6; Section 5.2, Paragraph 2;
Section 5.2, Paragraph 4; Section 5.2, Paragraph 4;
Section 5.3, Paragraph 4; Section 6, Paragraph 3; Section 6,
Paragraph 5, Item 2; Section 6, Paragraph 7; Section 6,
Paragraph 7; Section 6, Paragraph 8; Section 6, Paragraph
10, Item 1; Section 6, Paragraph 10, Item 1; Section 6.1,
Paragraph 3; Section 6.1, Paragraph 6; Section 6.1,
Paragraph 6; Section 6.1, Paragraph 6; Section 6.1,
Paragraph 7; Section 6.2, Paragraph 1; Section 6.2,
Paragraph 2; Section 6.2, Paragraph 3; Section 6.2.3,
Paragraph 2; Section 6.2.3, Paragraph 5; Section 6.2.3,
Paragraph 5; Section 6.5, Paragraph 2; Section 6.5,
Paragraph 4; Section 6.7, Paragraph 4; Section 6.7,
Paragraph 4; Section 7, Paragraph 1; Section 7, Paragraph 2;
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 18; Appendix A, Paragraph 36
Oblivious Relay Resources Section 6.2.2, Paragraph 1;
Section 6.2.3, Paragraph 6; Section 6.10, Paragraph 4;
Section 8.2, Paragraph 2; Section 8.2, Paragraph 2
T
Target Resource Section 2, Paragraph 3; Section 2, Paragraph
5; Section 2, Paragraph 6, Item 1; Section 2, Paragraph 9;
Section 2, Paragraph 9; Section 2, Paragraph 9; Section 2.2,
Paragraph 3.2.1; Section 2.2, Paragraph 3.10.1; Section 2.2;
Section 5, Paragraph 2; Section 5, Paragraph 2; Section 5,
Paragraph 2; Section 5, Paragraph 7; Section 5, Paragraph 8;
Section 5.2, Paragraph 3; Section 5.2, Paragraph 3;
Section 6, Paragraph 1; Section 6, Paragraph 5, Item 3;
Section 6, Paragraph 6; Section 6, Paragraph 8; Section 6.1,
Paragraph 1; Section 6.1, Paragraph 1; Section 6.1,
Paragraph 3; Section 6.3, Paragraph 1; Section 6.3,
Paragraph 1; Section 6.3, Paragraph 4; Section 6.3,
Paragraph 4; Section 6.9, Paragraph 3; Section 6.10,
Paragraph 1; Section 6.10, Paragraph 3; Section 6.10,
Paragraph 3; Section 6.10, Paragraph 3; Section 6.10,
Paragraph 3; Section 6.10, Paragraph 4; Section 6.10,
Paragraph 5; Appendix A, Paragraph 1; Appendix A, Paragraph
20; Appendix A, Paragraph 20
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: mt@lowentropy.net Email: mt@lowentropy.net
Christopher A. Wood Christopher A. Wood
Cloudflare Cloudflare
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 189 change blocks. 
677 lines changed or deleted 436 lines changed or added

This html diff was produced by rfcdiff 1.48.