Internet DRAFT - draft-ietf-ohai-ohttp

draft-ietf-ohai-ohttp







Oblivious HTTP Application Intermediation                     M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                              C. A. Wood
Expires: 26 February 2024                                     Cloudflare
                                                          25 August 2023


                             Oblivious HTTP
                        draft-ietf-ohai-ohttp-10

Abstract

   This document describes Oblivious HTTP, a protocol for forwarding
   encrypted HTTP messages.  Oblivious HTTP allows a client to make
   multiple requests to an origin server without that server being able
   to link those requests to the client or to identify the requests as
   having come from the same client, while placing only limited trust in
   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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.





Thomson & Wood          Expires 26 February 2024                [Page 1]

Internet-Draft               Oblivious HTTP                  August 2023


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 February 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Conventions and Definitions . . . . . . . . . . . . . . .   8
   3.  Key Configuration . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Key Configuration Encoding  . . . . . . . . . . . . . . .   9
     3.2.  Key Configuration Media Type  . . . . . . . . . . . . . .  11
   4.  HPKE Encapsulation  . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Request Format  . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  Response Format . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Encapsulation of Requests . . . . . . . . . . . . . . . .  13
     4.4.  Encapsulation of Responses  . . . . . . . . . . . . . . .  15
     4.5.  Request and Response Media Types  . . . . . . . . . . . .  16
     4.6.  Repurposing the Encapsulation Format  . . . . . . . . . .  17
   5.  HTTP Usage  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  Informational Responses . . . . . . . . . . . . . . . . .  19
     5.2.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     5.3.  Signaling Key Configuration Problems  . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     6.1.  Client Responsibilities . . . . . . . . . . . . . . . . .  22
     6.2.  Relay Responsibilities  . . . . . . . . . . . . . . . . .  23
       6.2.1.  Differential Treatment  . . . . . . . . . . . . . . .  24
       6.2.2.  Denial of Service . . . . . . . . . . . . . . . . . .  24
       6.2.3.  Traffic Analysis  . . . . . . . . . . . . . . . . . .  25
     6.3.  Server Responsibilities . . . . . . . . . . . . . . . . .  26



Thomson & Wood          Expires 26 February 2024                [Page 2]

Internet-Draft               Oblivious HTTP                  August 2023


     6.4.  Key Management  . . . . . . . . . . . . . . . . . . . . .  27
     6.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  27
       6.5.1.  Use of Date for Anti-Replay . . . . . . . . . . . . .  28
       6.5.2.  Correcting Clock Differences  . . . . . . . . . . . .  29
     6.6.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  31
     6.7.  Post-Compromise Security  . . . . . . . . . . . . . . . .  31
     6.8.  Client Clock Exposure . . . . . . . . . . . . . . . . . .  31
     6.9.  Media Type Security . . . . . . . . . . . . . . . . . . .  32
     6.10. Separate Gateway and Target . . . . . . . . . . . . . . .  32
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  33
   8.  Operational and Deployment Considerations . . . . . . . . . .  34
     8.1.  Performance Overhead  . . . . . . . . . . . . . . . . . .  34
     8.2.  Resource Mappings . . . . . . . . . . . . . . . . . . . .  34
     8.3.  Network Management  . . . . . . . . . . . . . . . . . . .  35
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
     9.1.  application/ohttp-keys Media Type . . . . . . . . . . . .  35
     9.2.  message/ohttp-req Media Type  . . . . . . . . . . . . . .  36
     9.3.  message/ohttp-res Media Type  . . . . . . . . . . . . . .  36
     9.4.  Registration of "date" Problem Type . . . . . . . . . . .  37
     9.5.  Registration of "ohttp-key" Problem Type  . . . . . . . .  37
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  37
     10.2.  Informative References . . . . . . . . . . . . . . . . .  39
   Appendix A.  Complete Example of a Request and Response . . . . .  41
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  49

1.  Introduction

   HTTP requests reveal information about client identities to servers.
   While the actual content of the request message is under the control
   of the client, other information that is more difficult to control
   can still be used to identify the client.

   In particular, the source IP address of the underlying connection
   reveals identifying information that the client has only limited
   control over.  While client-configured HTTP proxies can provide a
   degree of protection against IP address tracking, they present an
   unfortunate tradeoff: if they are used without TLS, the contents of
   communication are revealed to the proxy; if they are used with TLS, a
   new connection needs to be used for each request to assure 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,
   a protocol for encrypting and sending HTTP messages from a client to
   a gateway.  This uses a trusted relay service in a manner that



Thomson & Wood          Expires 26 February 2024                [Page 3]

Internet-Draft               Oblivious HTTP                  August 2023


   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]
       using Hybrid Public Key Encryption (HPKE; [HPKE]) to protect
       their contents,

   2.  a method for forwarding these encapsulated messages between
       clients and an Oblivious Gateway Resource through a trusted
       Oblivious Relay Resource using HTTP, and

   3.  requirements for how the Oblivious Gateway Resource handles
       encapsulated HTTP messages and produces encapsulated responses
       for the client.

   The combination of encapsulation and relaying ensures that Oblivious
   Gateway Resource never sees the client's IP address and the Oblivious
   Relay Resource never sees plaintext HTTP message content.

   Oblivious HTTP allows connection reuse between the client and
   Oblivious Relay Resource, as well as between that relay and the
   Oblivious Gateway Resource, so this scheme represents a performance
   improvement over using just one request in each connection.  With
   limited trust placed in the Oblivious Relay Resource (see Section 6),
   Clients are assured that requests are not uniquely attributed to them
   or linked to other requests.

2.  Overview

   An Oblivious HTTP Client must initially know the following:

   *  The identity of an Oblivious Gateway Resource.  This might include
      some information about what Target Resources the Oblivious Gateway
      Resource supports.

   *  The details of an HPKE public key for the Oblivious Gateway
      Resource, including an identifier for that key and the HPKE
      algorithms that are used with that key.

   *  The identity of an Oblivious Relay Resource that will accept relay
      requests carrying an Encapsulated Request as its content and
      forward the content in these requests to a particular Oblivious
      Gateway Resource.  Oblivious HTTP uses a one-to-one mapping
      between Oblivious Relay and Gateway Resources; see Section 8.2 for
      more details.





Thomson & Wood          Expires 26 February 2024                [Page 4]

Internet-Draft               Oblivious HTTP                  August 2023


   This information allows the Client to send HTTP requests to the
   Oblivious Gateway Resource for forwarding to a Target Resource.  The
   Oblivious Gateway Resource does not learn the client's IP address or
   any other identifying information that might be revealed from the
   client at the transport layer, nor does the Oblivious Gateway
   Resource learn which of the requests it receives are from the same
   Client.

                                       .------------------------------.
   +---------+       +----------+     |  +----------+    +----------+  |
   | Client  |       | Relay    |     |  | Gateway  |    | Target   |  |
   |         |       | Resource |     |  | Resource |    | Resource |  |
   +----+----+       +----+-----+     |  +-----+----+    +----+-----+  |
        |                 |            `-------|--------------|-------'
        | Relay           |                    |              |
        | Request         |                    |              |
        | [+ Encapsulated |                    |              |
        |    Request ]    |                    |              |
        +---------------->| Gateway            |              |
        |                 | Request            |              |
        |                 | [+ Encapsulated    |              |
        |                 |    Request ]       |              |
        |                 +------------------->| Request      |
        |                 |                    +------------->|
        |                 |                    |              |
        |                 |                    |     Response |
        |                 |            Gateway |<-------------+
        |                 |           Response |              |
        |                 |    [+ Encapsulated |              |
        |                 |         Response ] |              |
        |           Relay |<-------------------+              |
        |        Response |                    |              |
        | [+ Encapsulated |                    |              |
        |      Response ] |                    |              |
        |<----------------+                    |              |
        |                 |                    |              |

                    Figure 1: Overview of Oblivious HTTP

   In order to forward a request for a Target Resource to the Oblivious
   Gateway Resource, the following steps occur, as shown in Figure 1:

   1.  The Client constructs an HTTP request for a Target Resource.

   2.  The Client encodes the HTTP request in a binary HTTP message and
       then encapsulates that message using HPKE and the process from
       Section 4.3.




Thomson & Wood          Expires 26 February 2024                [Page 5]

Internet-Draft               Oblivious HTTP                  August 2023


   3.  The Client sends a POST request to the Oblivious Relay Resource
       with the Encapsulated Request as the content of that message.

   4.  The Oblivious Relay Resource forwards this request to the
       Oblivious Gateway resource.

   5.  The Oblivious Gateway Resource receives this request and removes
       the HPKE protection to obtain an HTTP request.

   The Oblivious Gateway Resource then handles the HTTP request.  This
   typically involves making an HTTP request using the content of the
   Encapsulated Request.  Once the Oblivious Gateway Resource has an
   HTTP response for this request, the following steps occur to return
   this response to the client:

   1.  The Oblivious Gateway Resource encapsulates the HTTP response
       following the process in Section 4.4 and sends this in response
       to the request from the Oblivious Relay Resource.

   2.  The Oblivious Relay Resource forwards this response to the
       Client.

   3.  The Client removes the encapsulation to obtain the response to
       the original request.

   This interaction provides authentication and confidentiality
   protection between the Client and the Oblivious Gateway, but
   importantly not between the Client and the Target Resource.  While
   the Target Resource is a distinct HTTP resource from the Oblivious
   Gateway Resource, they are both logically under the control of the
   Oblivious Gateway, since the Oblivious Gateway Resource can
   unilaterally dictate the responses returned from the Target Resource
   to the Client.  This arrangement is shown in Figure 1.

2.1.  Applicability

   Oblivious HTTP has limited applicability.  Imporantly, it requires
   expicit support from a willing Oblivious Relay Resource and Oblivious
   Gateway Resource, thereby limiting the use of Oblivious HTTP for
   generic applications; see Section 6.3 for more information.

   Many uses of HTTP benefit from being able to carry state between
   requests, such as with cookies ([COOKIES]), authentication
   (Section 11 of [HTTP]), or even alternative services ([RFC7838]).
   Oblivious HTTP removes linkage at the transport layer, which is only
   useful for an application that does not carry state between requests.





Thomson & Wood          Expires 26 February 2024                [Page 6]

Internet-Draft               Oblivious HTTP                  August 2023


   Oblivious HTTP is primarily useful where privacy risks associated
   with possible stateful treatment of requests are sufficiently large
   that the cost of deploying this protocol can be justified.  Oblivious
   HTTP is simpler and less costly than more robust systems, like Prio
   ([PRIO]) or Tor ([DMS2004]), which can provide stronger guarantees at
   higher operational costs.

   Oblivious HTTP is more costly than a direct connection to a server.
   Some costs, like those involved with connection setup, can be
   amortized, but there are several ways in which Oblivious HTTP is more
   expensive than a direct request:

   *  Each request requires at least two regular HTTP requests, which
      could increase latency.

   *  Each request is expanded in size with additional HTTP fields,
      encryption-related metadata, and AEAD expansion.

   *  Deriving cryptographic keys and applying them for request and
      response protection takes non-negligible computational resources.

   Examples of where preventing the linking of requests might justify
   these costs include:

   *  DNS queries.  DNS queries made to a recursive resolver reveal
      information about the requester, particularly if linked to other
      queries.

   *  Telemetry submission.  Applications that submit reports about
      their usage to their developers might use Oblivious HTTP for some
      types of moderately sensitive data.

   These are examples of requests where there is information in a
   request that - if it were connected to the identity of the user -
   might allow a server to learn something about that user even if the
   identity of the user is pseudonymous.  Other examples include the
   submission of anonymous surveys, making search queries, or requesting
   location-specific content (such as retrieving tiles of a map
   display).

   In addition to these limitations, Section 6 describes operational
   constraints that are necessary to realize the goals of the protocol.









Thomson & Wood          Expires 26 February 2024                [Page 7]

Internet-Draft               Oblivious HTTP                  August 2023


2.2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses terminology from [HTTP] and defines several terms
   as follows:

   Client:  A Client originates Oblivious HTTP requests.  A Client is
      also an HTTP client in two ways: for the Target Resource and for
      the Oblivious Relay Resource.  However, when referring to the HTTP
      definition of client (Section 3.3 of [HTTP]), the term "HTTP
      client" is used; see Section 5.

   Encapsulated Request:  An HTTP request that is encapsulated in an
      HPKE-encrypted message; see Section 4.3.

   Encapsulated Response:  An HTTP response that is encapsulated in an
      HPKE-encrypted message; see Section 4.4.

   Oblivious Relay Resource:  An intermediary that forwards Encapsulated
      Requests and Responses between Clients and a single Oblivious
      Gateway Resource.  In context, this can be referred to as simply a
      "relay".

   Oblivious Gateway Resource:  A resource that can receive an
      Encapsulated Request, extract the contents of that request,
      forward it to a Target Resource, receive a response, encapsulate
      that response, then return the resulting Encapsulated Response.
      In context, this can be referred to as simply a "gateway".

   Target Resource:  The resource that is the target of an Encapsulated
      Request.  This resource logically handles only regular HTTP
      requests and responses and so might be ignorant of the use of
      Oblivious HTTP to reach it.

   This document includes pseudocode that uses the functions and
   conventions defined in [HPKE].

   Encoding an integer to a sequence of bytes in network byte order is
   described using the function encode(n, v), where n is the number of
   bytes and v is the integer value.  ASCII [ASCII] encoding of a string
   s is indicated using the function encode_str(s).





Thomson & Wood          Expires 26 February 2024                [Page 8]

Internet-Draft               Oblivious HTTP                  August 2023


   Formats are described using notation from Section 1.3 of [QUIC].  An
   extension to that notation expresses the number of bits in a field
   using a simple mathematical function.

3.  Key Configuration

   A Client needs to acquire information about the key configuration of
   the Oblivious Gateway Resource in order to send Encapsulated
   Requests.  In order to ensure that Clients do not encapsulate
   messages that other entities can intercept, the key configuration
   MUST be authenticated and have integrity protection.

   This document does not define how that acquisition occurs.  However,
   in order to help facilitate interoperability, it does specify a
   format for the keys.  This ensures that different Client
   implementations can be configured in the same way and also enables
   advertising key configurations in a consistent format.  This format
   might be used, for example with HTTPS, as part of a system for
   configuring or discovering key configurations.  Note however that
   such a system needs to consider the potential for key configuration
   to be used to compromise Client privacy; see Section 7.

   A Client might have multiple key configurations to select from when
   encapsulating a request.  Clients are responsible for selecting a
   preferred key configuration from those it supports.  Clients need to
   consider both the key encapsulation method (KEM) and the combinations
   of key derivation function (KDF) and authenticated encryption with
   associated data (AEAD) in this decision.

3.1.  Key Configuration Encoding

   A single key configuration consists of a key identifier, a public
   key, an identifier for the KEM that the public key uses, and a set of
   HPKE symmetric algorithms.  Each symmetric algorithm consists of an
   identifier for a KDF and an identifier for an AEAD.

   Figure 2 shows a single key configuration.














Thomson & Wood          Expires 26 February 2024                [Page 9]

Internet-Draft               Oblivious HTTP                  August 2023


   HPKE Symmetric Algorithms {
     HPKE KDF ID (16),
     HPKE AEAD ID (16),
   }

   Key Config {
     Key Identifier (8),
     HPKE KEM ID (16),
     HPKE Public Key (Npk * 8),
     HPKE Symmetric Algorithms Length (16) = 4..65532,
     HPKE Symmetric Algorithms (32) ...,
   }

                    Figure 2: A Single Key Configuration

   That is, a key configuration consists of the following fields:

   Key Identifier:  An 8 bit value that identifies the key used by the
      Oblivious Gateway Resource.

   HPKE KEM ID:  A 16 bit value that identifies the Key Encapsulation
      Method (KEM) used for the identified key as defined in Section 7.1
      of [HPKE] or the HPKE KDF IANA registry
      (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids).

   HPKE Public Key:  The public key used by the gateway.  The length of
      the public key is Npk, which is determined by the choice of HPKE
      KEM as defined in Section 4 of [HPKE].

   HPKE Symmetric Algorithms Length:  A 16 bit integer in network byte
      order that encodes the length, in bytes, of the HPKE Symmetric
      Algorithms field that follows.

   HPKE Symmetric Algorithms:  One or more pairs of identifiers for the
      different combinations of HPKE KDF and AEAD that the Oblivious
      Gateway Resource supports:

      HPKE KDF ID:  A 16 bit HPKE KDF identifier as defined in
         Section 7.2 of [HPKE] or the HPKE KDF IANA registry
         (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kdf-
         ids).

      HPKE AEAD ID:  A 16 bit HPKE AEAD identifier as defined in
         Section 7.3 of [HPKE] or the HPKE AEAD IANA registry
         (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-
         ids).





Thomson & Wood          Expires 26 February 2024               [Page 10]

Internet-Draft               Oblivious HTTP                  August 2023


3.2.  Key Configuration Media Type

   The "application/ohttp-keys" format is a media type that identifies a
   serialized collection of key configurations.  The content of this
   media type comprises one or more key configuration encodings (see
   Section 3.1).  Each encoded configuration is prefixed with a two byte
   integer in network byte order that indicates the length of the key
   configuration in bytes.  The length-prefixed encodings are
   concatenated to form a list.  See Section 9.1 for a definition of the
   media type.

   Evolution of the key configuration format is supported through the
   definition of new formats that are identified by new media types.

   A Client that receives an "application/ohttp-keys" object with
   encoding errors might be able to recover one or more key
   configurations.  Differences in how key configurations are recovered
   might be exploited to segregate Clients, so Clients MUST discard
   incorrectly encoded key configuration collections.

4.  HPKE Encapsulation

   This document defines how a binary-encoded HTTP message [BINARY] is
   encapsulated using HPKE [HPKE].  Separate media types are defined to
   distinguish request and response messages:

   *  An Encapsulated Request format defined in Section 4.1 is
      identified by the "message/ohttp-req" media type (message/
      ohttp-req Media Type).

   *  An Encapsulated Response format defined in Section 4.2 is
      identified by the "message/ohttp-res" media type (Section 9.3).

   Alternative encapsulations or message formats are indicated using the
   media type; see Section 4.5 and Section 4.6.

4.1.  Request Format

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

   Request {
     Binary HTTP Message (..),
   }

                    Figure 3: Plaintext Request Content





Thomson & Wood          Expires 26 February 2024               [Page 11]

Internet-Draft               Oblivious HTTP                  August 2023


   This plaintext Request is encapsulated into a message in "message/
   ohttp-req" form by generating an Encapsulated Request.  An
   Encapsulated Request comprises a key identifier; HPKE parameters for
   the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or
   enc); and an HPKE-protected binary HTTP request message.

   An Encapsulated Request is shown in Figure 4.  Section 4.3 describes
   the process for constructing and processing an Encapsulated Request.

   Encapsulated Request {
     Key Identifier (8),
     HPKE KEM ID (16),
     HPKE KDF ID (16),
     HPKE AEAD ID (16),
     Encapsulated KEM Shared Secret (8 * Nenc),
     HPKE-Protected Request (..),
   }

                       Figure 4: Encapsulated Request

   That is, an Encapsulated Request comprises a Key Identifier, HPKE KEM
   ID, HPKE KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and
   HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF
   ID, and HPKE AEAD ID fields are defined in Section 3.1.  The
   Encapsulated KEM Shared Secret is the output of the Encap() function
   for the KEM, which is Nenc bytes in length, as defined in Section 4
   of [HPKE].

4.2.  Response Format

   A message in "message/ohttp-res" format protects a binary HTTP
   response message; see Figure 5.

   Response {
     Binary HTTP Message (..),
   }

                    Figure 5: Plaintext Response Content

   This plaintext Response is encapsulated into a message in "message/
   ohttp-res" form by generating an Encapsulated Response.  An
   Encapsulated Response comprises a nonce and the AEAD-protected binary
   HTTP response message.

   An Encapsulated Response is shown in Figure 6.  Section 4.4 describes
   the process for constructing and processing an Encapsulated Response.





Thomson & Wood          Expires 26 February 2024               [Page 12]

Internet-Draft               Oblivious HTTP                  August 2023


   Encapsulated Response {
     Nonce (8 * max(Nn, Nk)),
     AEAD-Protected Response (..),
   }

                      Figure 6: Encapsulated Response

   That is, an Encapsulated Response contains a Nonce and an AEAD-
   Protected Response.  The Nonce field is either Nn or Nk bytes long,
   whichever is larger.  The Nn and Nk values correspond to parameters
   of the AEAD used in HPKE, which is defined in Section 7.3 of [HPKE]
   or the HPKE AEAD IANA registry
   (https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids).  Nn
   and Nk refer to the size of the AEAD nonce and key respectively, in
   bytes.

4.3.  Encapsulation of Requests

   Clients encapsulate a request, request, using values from a key
   configuration:

   *  the key identifier from the configuration, key_id, with the
      corresponding KEM identified by kem_id,

   *  the public key from the configuration, pkR, and

   *  a combination of KDF, identified by kdf_id, and AEAD, identified
      by aead_id, that the Client selects from those in the key
      configuration.

   The Client then constructs an Encapsulated Request, enc_request, from
   a binary encoded HTTP request [BINARY], request, as follows:

   1.  Construct a message header, hdr, by concatenating the values of
       key_id, kem_id, kdf_id, and aead_id, as one 8-bit integer and
       three 16-bit integers, respectively, each in network byte order.

   2.  Build info by concatenating the ASCII-encoded string "message/
       bhttp request", a zero byte, and the header.  Note: Section 4.6
       discusses how alternative message formats might use a different
       info value.

   3.  Create a sending HPKE context by invoking SetupBaseS()
       (Section 5.1.1 of [HPKE]) with the public key of the receiver pkR
       and info.  This yields the context sctxt and an encapsulation key
       enc.





Thomson & Wood          Expires 26 February 2024               [Page 13]

Internet-Draft               Oblivious HTTP                  August 2023


   4.  Encrypt request by invoking the Seal() method on sctxt
       (Section 5.2 of [HPKE]) with empty associated data aad, yielding
       ciphertext ct.

   5.  Concatenate the values of hdr, enc, and ct, yielding an Encrypted
       Request enc_request.

   Note that enc is of fixed-length, so there is no ambiguity in parsing
   this structure.

   In pseudocode, this procedure is as follows:

   hdr = concat(encode(1, key_id),
                encode(2, kem_id),
                encode(2, kdf_id),
                encode(2, aead_id))
   info = concat(encode_str("message/bhttp request"),
                 encode(1, 0),
                 hdr)
   enc, sctxt = SetupBaseS(pkR, info)
   ct = sctxt.Seal("", request)
   enc_request = concat(hdr, enc, ct)

   An Oblivious Gateway Resource decrypts an Encapsulated Request by
   reversing this process.  To decapsulate an Encapsulated Request,
   enc_request:

   1.  Parses enc_request into key_id, kem_id, kdf_id, aead_id, enc, and
       ct (indicated using the function parse() in pseudocode).  The
       Oblivious Gateway Resource is then able to find the HPKE private
       key, skR, corresponding to key_id.

       a.  If key_id does not identify a key matching the type of
       kem_id, the Oblivious Gateway Resource returns an error.

       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,
       the Oblivious Gateway Resource returns an error.

   2.  Build info by concatenating the ASCII-encoded string "message/
       bhttp request", a zero byte, key_id as an 8-bit integer, plus
       kem_id, kdf_id, and aead_id as three 16-bit integers.

   3.  Create a receiving HPKE context, rctxt, by invoking SetupBaseR()
       (Section 5.1.1 of [HPKE]) with skR, enc, and info.






Thomson & Wood          Expires 26 February 2024               [Page 14]

Internet-Draft               Oblivious HTTP                  August 2023


   4.  Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
       [HPKE]), with an empty associated data aad, yielding request or
       an error on failure.  If decryption fails, the Oblivious Gateway
       Resource returns an error.

   In pseudocode, this procedure is as follows:

   key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
   info = concat(encode_str("message/bhttp request"),
                 encode(1, 0),
                 encode(1, key_id),
                 encode(2, kem_id),
                 encode(2, kdf_id),
                 encode(2, aead_id))
   rctxt = SetupBaseR(enc, skR, info)
   request, error = rctxt.Open("", ct)

   The Oblivious Gateway Resource retains the HPKE context, rctxt, so
   that it can encapsulate a response.

4.4.  Encapsulation of Responses

   Oblivious Gateway Resources generate an Encapsulated Response,
   enc_response, from a binary encoded HTTP response [BINARY], response.
   The Oblivious Gateway Resource uses the HPKE receiver context, rctxt,
   as the HPKE context, context, as follows:

   1.  Export a secret, secret, from context, using the string "message/
       bhttp response" as the exporter_context parameter to
       context.Export; see Section 5.3 of [HPKE].  The length of this
       secret is max(Nn, Nk), where Nn and Nk are the length of AEAD key
       and nonce associated with context.  Note: Section 4.6 discusses
       how alternative message formats might use a different context
       value.

   2.  Generate a random value of length max(Nn, Nk) bytes, called
       response_nonce.

   3.  Extract a pseudorandom key, prk, using the Extract function
       provided by the KDF algorithm associated with context.  The ikm
       input to this function is secret; the salt input is the
       concatenation of enc (from enc_request) and response_nonce.

   4.  Use the Expand function provided by the same KDF to create an
       AEAD key, key, of length Nk - the length of the keys used by the
       AEAD associated with context.  Generating aead_key uses a label
       of "key".




Thomson & Wood          Expires 26 February 2024               [Page 15]

Internet-Draft               Oblivious HTTP                  August 2023


   5.  Use the same Expand function to create a nonce, nonce, of length
       Nn - the length of the nonce used by the AEAD.  Generating
       aead_nonce uses a label of "nonce".

   6.  Encrypt response, passing the AEAD function Seal the values of
       aead_key, aead_nonce, an empty aad, and a pt input of response,
       which yields ct.

   7.  Concatenate response_nonce and ct, yielding an Encapsulated
       Response, enc_response.  Note that response_nonce is of fixed-
       length, so there is no ambiguity in parsing either response_nonce
       or ct.

   In pseudocode, this procedure is as follows:

   secret = context.Export("message/bhttp response", max(Nn, Nk))
   response_nonce = random(max(Nn, Nk))
   salt = concat(enc, response_nonce)
   prk = Extract(salt, secret)
   aead_key = Expand(prk, "key", Nk)
   aead_nonce = Expand(prk, "nonce", Nn)
   ct = Seal(aead_key, aead_nonce, "", response)
   enc_response = concat(response_nonce, ct)

   Clients decrypt an Encapsulated Response by reversing this process.
   That is, Clients first parse enc_response into response_nonce and ct.
   They then follow the same process to derive values for aead_key and
   aead_nonce, using their sending HPKE context, sctxt, as the HPKE
   context, context.

   The Client uses these values to decrypt ct using the Open function
   provided by the AEAD.  Decrypting might produce an error, as follows:

   response, error = Open(aead_key, aead_nonce, "", ct)

4.5.  Request and Response Media Types

   Media types are used to identify Encapsulated Requests and Responses;
   see Section 9.2 and Section 9.3 for definitions of these media types.

   Evolution of the format of Encapsulated Requests and Responses is
   supported through the definition of new formats that are identified
   by new media types.  New media types might be defined to use similar
   encapsulation with a different HTTP message format than in [BINARY];
   see Section 4.6 for guidance on reusing this encapsulation.
   Alternatively, a new encapsulation method might be defined.





Thomson & Wood          Expires 26 February 2024               [Page 16]

Internet-Draft               Oblivious HTTP                  August 2023


4.6.  Repurposing the Encapsulation Format

   The encrypted payload of an Oblivious HTTP request and response is a
   binary HTTP message [BINARY].  The Client and Oblivious Gateway
   Resource agree on this encrypted payload type by specifying the media
   type "message/bhttp" in the HPKE info string and HPKE export context
   string for request and response encryption, respectively.

   Future specifications may repurpose the encapsulation mechanism
   described in this document.  This requires that the specification
   define a new media type.  The encapsulation process for that content
   type can follow the same process, using new constant strings for the
   HPKE info and exporter context inputs.

   For example, a future specification might encapsulate DNS messages,
   which use the "application/dns-message" media type [RFC8484].  In
   creating a new, encrypted media types, specifications might define
   the use of string "application/dns-message request" (plus a zero byte
   and the header for the full value) for request encryption and the
   string "application/dns-message response" for response encryption.

5.  HTTP Usage

   A Client interacts with the Oblivious Relay Resource by constructing
   an Encapsulated Request.  This Encapsulated Request is included as
   the content of a POST request to the Oblivious Relay Resource.  This
   request only needs those fields necessary to carry the Encapsulated
   Request: a method of POST, a target URI of the Oblivious Relay
   Resource, a header field containing the content type (see
   Section 9.2), and the Encapsulated Request as the request content.
   In the request to the Oblivious Relay Resource, Clients MAY include
   additional fields.  However, additional fields MUST be independent of
   the Encapsulated Request and MUST be fields that the Oblivious Relay
   Resource will remove before forwarding the Encapsulated Request
   towards the target, such as the Connection or Proxy-Authorization
   header fields [HTTP].

   The Client role in this protocol acts as an HTTP client both with
   respect to the Oblivious Relay Resource and the Target Resource.  For
   the request, the Clients makes to the Target Resource, this diverges
   from typical HTTP assumptions about the use of a connection (see
   Section 3.3 of [HTTP]) in that the request and response are encrypted
   rather than sent over a connection.  The Oblivious Relay Resource and
   the Oblivious Gateway Resource also act as HTTP clients toward the
   Oblivious Gateway Resource and Target Resource respectively.

   In order to achieve the privacy and security goals of the protocol a
   Client also needs to observe the guidance in Section 6.1.



Thomson & Wood          Expires 26 February 2024               [Page 17]

Internet-Draft               Oblivious HTTP                  August 2023


   The Oblivious Relay Resource interacts with the Oblivious Gateway
   Resource as an HTTP client by constructing a request using the same
   restrictions as the Client request, except that the target URI is the
   Oblivious Gateway Resource.  The content of this request is copied
   from the Client.  An Oblivious Relay Resource MAY reject requests
   that are obviously invalid, such as a request with no content.  The
   Oblivious Relay Resource MUST NOT add information to the request
   without the Client being aware of the type of information that might
   be added; see Section 6.2 for more information on relay
   responsibilities.

   When a response is received from the Oblivious Gateway Resource, the
   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
   error, the Oblivious Relay Resource can generate a response with an
   appropriate status code.

   In order to achieve the privacy and security goals of the protocol an
   Oblivious Relay Resource also needs to observe the guidance in
   Section 6.2.

   An Oblivious Gateway Resource acts as a gateway for requests to the
   Target Resource (see Section 7.6 of [HTTP]).  The one exception is
   that any information it might forward in a response MUST be
   encapsulated, unless it is responding to errors that do not relate to
   processing the contents of the encapsulated request; see Section 5.2.

   An Oblivious Gateway Resource, if it receives any response from the
   Target Resource, sends a single 200 response containing the
   encapsulated response.  Like the request from the Client, this
   response MUST only contain those fields necessary to carry the
   encapsulated response: a 200 status code, a header field indicating
   the content type, and the encapsulated response as the response
   content.  As with requests, additional fields MAY be used to convey
   information that does not reveal information about the encapsulated
   response.

   An Oblivious Gateway Resource that does not receive a response can
   itself generate a response with an appropriate error status code
   (such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which
   is then encapsulated in the same way as a successful response.

   In order to achieve the privacy and security goals of the protocol an
   Oblivious Gateway Resource also needs to observe the guidance in
   Section 6.3.






Thomson & Wood          Expires 26 February 2024               [Page 18]

Internet-Draft               Oblivious HTTP                  August 2023


5.1.  Informational Responses

   This encapsulation does not permit progressive processing of
   responses.  Though the binary HTTP response format does support the
   inclusion of informational (1xx) status codes, the AEAD encapsulation
   cannot be removed until the entire message is received.

   In particular, the Expect header field with 100-continue (see
   Section 10.1.1 of [HTTP]) cannot be used.  Clients MUST NOT construct
   a request that includes a 100-continue expectation; the Oblivious
   Gateway Resource MUST generate an error if a 100-continue expectation
   is received.

5.2.  Errors

   A server that receives an invalid message for any reason MUST
   generate an HTTP response with a 4xx status code.

   Errors detected by the Oblivious Relay Resource and errors detected
   by the Oblivious Gateway Resource before removing protection
   (including being unable to remove encapsulation for any reason)
   result in the status code being sent without protection in response
   to the POST request made to that resource.

   Errors detected by the Oblivious Gateway Resource after successfully
   removing encapsulation and errors detected by the Target Resource
   MUST be sent in an Encapsulated Response.  This might be because the
   Encapsulated Request is malformed or the Target Resource does not
   produce a response.  In either case the Oblivious Gateway Resource
   can generate a response with an appropriate error status code (such
   as 400 (Bad Request) or 504 (Gateway Timeout); see Section 15.5.1 of
   [HTTP] and Section 15.6.5 of [HTTP], respectively).  This response is
   encapsulated in the same way as a successful response.

   Errors in the encapsulation of requests mean that responses cannot be
   encapsulated.  This includes cases where the key configuration is
   incorrect or outdated.  The Oblivious Gateway Resource can generate
   and send a response with a 4xx status code to the Oblivious Relay
   Resource.  This response MAY be forwarded to the Client or treated by
   the Oblivious Relay Resource as a failure.  If a Client receives a
   response that is not an Encapsulated Response, this could indicate
   that the client configuration used to construct the request is
   incorrect or out of date.








Thomson & Wood          Expires 26 February 2024               [Page 19]

Internet-Draft               Oblivious HTTP                  August 2023


5.3.  Signaling Key Configuration Problems

   The problem type [PROBLEM] of "https://iana.org/assignments/http-
   problem-types#ohttp-key" is defined.  An Oblivious Gateway Resource
   MAY use this problem type in a response to indicate that an
   Encapsulated Request used an outdated or incorrect key configuration.

   Figure 7 shows an example response in HTTP/1.1 format.

   HTTP/1.1 400 Bad Request
   Date: Mon, 07 Feb 2022 00:28:05 GMT
   Content-Type: application/problem+json
   Content-Length: 106

   {"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
   "title": "key identifier unknown"}

              Figure 7: Example Rejection of Key Configuration

   As this response cannot be encrypted, it might not reach the Client.
   A Client cannot rely on the Oblivious Gateway Resource using this
   problem type.  A Client might also be configured to disregard
   responses that are not encapsulated on the basis that they might be
   subject to observation or modification by an Oblivious Relay
   Resource.  A Client might manage the risk of an outdated key
   configuration using a heuristic approach whereby it periodically
   refreshes its key configuration if it receives a response with an
   error status code that has not been encapsulated.

6.  Security Considerations

   In this design, a Client wishes to make a request to an Oblivious
   Gateway Resource that is forwarded to a Target Resource.  The Client
   wishes to make this request without linking that request with either:

   1.  The identity at the network and transport layer of the Client
       (that is, the Client IP address and TCP or UDP port number the
       Client uses to create a connection).

   2.  Any other request the Client might have made in the past or might
       make in the future.

   In order to ensure this, the Client selects a relay (that serves the
   Oblivious Relay Resource) that it trusts will protect this
   information by forwarding the Encapsulated Request and Response
   without passing it to the server (that serves the Oblivious Gateway
   Resource).




Thomson & Wood          Expires 26 February 2024               [Page 20]

Internet-Draft               Oblivious HTTP                  August 2023


   In this section, a deployment where there are three entities is
   considered:

   *  A Client makes requests and receives responses

   *  A relay operates the Oblivious Relay Resource

   *  A server operates both the Oblivious Gateway Resource and the
      Target Resource

   Section 6.10 discusses the security implications for a case where
   different servers operate the Oblivious Gateway Resource and Target
   Resource.

   Requests from the Client to Oblivious Relay Resource and from
   Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS
   in order to provide unlinkability in the presence of a network
   observer.

   To achieve the stated privacy goals, the Oblivious Relay Resource
   cannot be operated by the same entity as the Oblivious Gateway
   Resource.  However, colocation of the Oblivious Gateway Resource and
   Target Resource simplifies the interactions between those resources
   without affecting Client privacy.

   As a consequence of this configuration, Oblivious HTTP prevents
   linkability described above.  Informally, this means:

   1.  Requests and responses are known only to Clients and Oblivious
       Gateway Resources.  In particular, the Oblivious Relay Resource
       knows the origin and destination of an Encapsulated Request and
       Response, yet does not know the decrypted contents.  Likewise,
       Oblivious Gateway Resources learn only the Oblivious Relay
       Resource and the decrypted request.  No entity other than the
       Client can see the plaintext request and response and can
       attribute them to the Client.

   2.  Oblivous Gateway Resources, and therefore Target Resources,
       cannot link requests from the same Client in the absence of
       unique per-Client keys.

   Traffic analysis that might affect these properties are outside the
   scope of this document; see Section 6.2.3.

   A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].






Thomson & Wood          Expires 26 February 2024               [Page 21]

Internet-Draft               Oblivious HTTP                  August 2023


6.1.  Client Responsibilities

   Because Clients do not authenticate the Target Resource when using
   Oblivious HTTP, Clients MUST have some mechanism to authorize an
   Oblivious Gateway Resource for use with a Target Resource.  One
   possible means of authorization is an allowlist.  This ensures that
   Oblivious Gateway Resources are not abused to forward traffic to
   arbitrary Target Resources.  Section 6.3 describes similar
   responsibilities that apply to Oblivious Gateway Resources.

   Clients MUST ensure that the key configuration they select for
   generating Encapsulated Requests is integrity protected and
   authenticated so that it can be attributed to the Oblivious Gateway
   Resource; see Section 3.

   Since Clients connect directly to the Oblivious Relay Resource
   instead of the Target Resource, application configurations wherein
   Clients make policy decisions about target connections, e.g., to
   apply certificate pinning, are incompatible with Oblivious HTTP.  In
   such cases, alternative technologies such as HTTP CONNECT
   (Section 9.3.6 of [HTTP]) can be used.  Applications could implement
   related policies on key configurations and relay connections, though
   these might not provide the same properties as policies enforced
   directly on target connections.  When this difference is relevant,
   applications can instead connect directly to the target at the cost
   of either privacy or performance.

   Clients cannot carry connection-level state between requests as they
   only establish direct connections to the relay responsible for the
   Oblivious Relay resource.  However, the content of requests might be
   used by a server to correlate requests.  Cookies [COOKIES] are the
   most obvious feature that might be used to correlate requests, but
   any identity information and authentication credentials might have
   the same effect.  Clients also need to treat information learned from
   responses with similar care when constructing subsequent requests,
   which includes the identity of resources.

   Clients MUST generate a new HPKE context for every request, using a
   good source of entropy ([RANDOM]) for generating keys.  Key reuse not
   only risks requests being linked, reuse could expose request and
   response contents to the relay.

   The request the Client sends to the Oblivious Relay Resource only
   requires minimal information; see Section 5.  The request that
   carries the Encapsulated Request and is sent to the Oblivious Relay
   Resource MUST NOT include identifying information unless the Client
   can trust that this information is removed by the relay.  A Client
   MAY include information only for the Oblivious Relay Resource in



Thomson & Wood          Expires 26 February 2024               [Page 22]

Internet-Draft               Oblivious HTTP                  August 2023


   header fields identified by the Connection header field if it trusts
   the relay to remove these as required by Section 7.6.1 of [HTTP].
   The Client needs to trust that the relay does not replicate the
   source addressing information in the request it forwards.

   Clients rely on the Oblivious Relay Resource to forward Encapsulated
   Requests and responses.  However, the relay can only refuse to
   forward messages, it cannot inspect or modify the contents of
   Encapsulated Requests or responses.

6.2.  Relay Responsibilities

   The relay that serves the Oblivious Relay Resource has a very simple
   function to perform.  For each request it receives, it makes a
   request of the Oblivious Gateway Resource that includes the same
   content.  When it receives a response, it sends a response to the
   Client that includes the content of the response from the Oblivious
   Gateway Resource.

   When forwarding a request, the relay MUST follow the forwarding rules
   in Section 7.6 of [HTTP].  A generic HTTP intermediary implementation
   is suitable for the purposes of serving an Oblivious Relay Resource,
   but additional care is needed to ensure that Client privacy is
   maintained.

   Firstly, a generic implementation will forward unknown fields.  For
   Oblivious HTTP, an Oblivious Relay Resource SHOULD NOT forward
   unknown fields.  Though Clients are not expected to include fields
   that might contain identifying information, removing unknown fields
   removes this privacy risk.

   Secondly, generic implementations are often configured to augment
   requests with information about the Client, such as the Via field or
   the Forwarded field [FORWARDED].  A relay MUST NOT add information
   when forwarding requests that might be used to identify Clients,
   except for information that a Client is aware of; see Section 6.2.1.

   Finally, a relay can also generate responses, though it is assumed to
   not be able to examine the content of a request (other than to
   observe the choice of key identifier, KDF, and AEAD), so it is also
   assumed that it cannot generate an Encapsulated Response.










Thomson & Wood          Expires 26 February 2024               [Page 23]

Internet-Draft               Oblivious HTTP                  August 2023


6.2.1.  Differential Treatment

   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
   include information that uniquely and permanently identifies the
   Client, including any pseudonymous identifier.  Information added by
   the relay - beyond what is already revealed through encapsulated
   requests from Clients - can reduce the size of the anonymity set of
   Clients at a gateway.

   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
   might use.  How a Client might learn about added information is not
   defined in this document.

   Moreover, relays MAY apply differential treatment to Clients that
   engage in abusive behavior, e.g., by sending too many requests in
   comparison to other Clients, or as a response to rate limits
   signalled from the gateway.  Any such differential treatment can
   reveal information to the gateway that would not be revealed
   otherwise and therefore reduce the size of the anonymity set of
   Clients using a gateway.  For example, if a relay chooses to rate
   limit or block an abusive Client, this means that any Client requests
   which are not treated this way are known to be non-abusive by the
   gateway.  Clients need to consider the likelihood of such
   differential treatment and the privacy risks when using a relay.

   Some patterns of abuse cannot be detected without access to the
   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
   signals toward the relay to provide feedback about specific requests.
   For example, a gateway could respond differently to requests it
   cannot decapsulate, as mentioned in Section 5.2.  A relay that acts
   on this feedback could - either inadvertently or by design - lead to
   Client deanonymization.

6.2.2.  Denial of Service

   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
   the Oblivious Gateway Resource might need an arrangement with
   Oblivious Relay Resources.  This arrangement might be necessary to
   prevent having the large volume of requests being classified as an
   attack by the server.

   If a server accepts a larger volume of requests from a relay, it
   needs to trust that the relay does not allow abusive levels of
   request volumes from Clients.  That is, if a server allows requests



Thomson & Wood          Expires 26 February 2024               [Page 24]

Internet-Draft               Oblivious HTTP                  August 2023


   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
   acceptable to the server.

   Servers that enter into an agreement with a relay that enables a
   higher request rate might choose to authenticate the relay to enable
   the higher rate.

6.2.3.  Traffic Analysis

   Using HTTPS protects information about which resources are the
   subject of request and prevents a network observer from being able to
   trivially correlate messages on either side of a relay.  However,
   using HTTPS does not prevent traffic analysis by such network
   observers.

   The time at which Encapsulated Request or response messages are sent
   can reveal information to a network observer.  Though messages
   exchanged between the Oblivious Relay Resource and the Oblivious
   Gateway Resource might be sent in a single connection, traffic
   analysis could be used to match messages that are forwarded by the
   relay.

   A relay could, as part of its function, delay requests before
   forwarding them.  Delays might increase the anonymity set into which
   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
   consent - or at least awareness - of Clients.

   A relay that forwards large volumes of exchanges can provide better
   privacy by providing larger sets of messages that need to be matched.

   Traffic analysis is not restricted to network observers.  A malicious
   Oblivious Relay Resource could use traffic analysis to learn
   information about otherwise encrypted requests and responses relayed
   between Clients and gateways.  An Oblivious Relay Resource terminates
   TLS connections from Clients, so they see message boundaries.  This
   privileged position allows for richer feature extraction from
   encrypted data, which might improve traffic analysis.












Thomson & Wood          Expires 26 February 2024               [Page 25]

Internet-Draft               Oblivious HTTP                  August 2023


   Clients and Oblivious Gateway Resources can use padding to reduce the
   effectiveness of traffic analysis.  Padding is a capability provided
   by binary HTTP messages; see Section 3.8 of [BINARY].  If the
   encapsulation method described in this document is used to protect a
   different message type (see Section 4.6), that message format might
   need to include padding support.  Oblivious Relay Resources can also
   use padding for the same reason, but need to operate at the HTTP
   layer since they cannot manipulate binary HTTP messages; for example,
   see Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]).

6.3.  Server Responsibilities

   The Oblivious Gateway Resource can be operated by a different entity
   than the Target Resource.  However, this means that the Client needs
   to trust the Oblivious Gateway Resource not to modify requests or
   responses.  This analysis concerns itself with a deployment scenario
   where a single server provides both the Oblivious Gateway Resource
   and Target Resource.

   A server that operates both Oblivious Gateway and Target Resources is
   responsible for removing request encryption, generating a response to
   the Encapsulated Request, and encrypting the response.

   Servers should account for traffic analysis based on response size or
   generation time.  Techniques such as padding or timing delays can
   help protect against such attacks; see Section 6.2.3.

   If separate entities provide the Oblivious Gateway Resource and
   Target Resource, these entities might need an arrangement similar to
   that between server and relay for managing denial of service; see
   Section 6.2.2.  Moreover, the Oblivious Gateway Resource SHOULD have
   some mechanism to ensure that the Oblivious Gateway Resource is not
   misused as a relay for HTTP messages to an arbitrary Target Resource,
   such as an allowlist.

   Non-secure requests - such as those with the "http" scheme as opposed
   to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
   and Target Resources are not on the same origin.  If messages are
   forwarded between these resources without the protections afforded by
   HTTPS, they could be inspected or modified by a network attacker.
   Note that a request could be forwarded without protection if the two
   resources share an origin.









Thomson & Wood          Expires 26 February 2024               [Page 26]

Internet-Draft               Oblivious HTTP                  August 2023


6.4.  Key Management

   An Oblivious Gateway Resource needs to have a plan for replacing
   keys.  This might include regular replacement of keys, which can be
   assigned new key identifiers.  If an Oblivious Gateway Resource
   receives a request that contains a key identifier that it does not
   understand or that corresponds to a key that has been replaced, the
   server can respond with an HTTP 422 (Unprocessable Content) status
   code.

   A server can also use a 422 status code if the server has a key that
   corresponds to the key identifier, but the Encapsulated Request
   cannot be successfully decrypted using the key.

   A server MUST ensure that the HPKE keys it uses are not valid for any
   other protocol that uses HPKE with the "message/bhttp request" label.
   Designers of protocols that reuse this encryption format, especially
   new versions of this protocol, can ensure key diversity by choosing a
   different label in their use of HPKE.  The "message/bhttp response"
   label was chosen for symmetry only as it provides key diversity only
   within the HPKE context created using the "message/bhttp request"
   label; see Section 4.6.

6.5.  Replay Attacks

   A server is responsible for either rejecting replayed requests or
   ensuring that the effect of replays does not adversely affect Clients
   or resources.

   Encrypted requests can be copied and replayed by the Oblivious Relay
   resource.  The threat model for Oblivious HTTP allows the possibility
   that an Oblivious Relay Resource might replay requests.  Furthermore,
   if a Client sends an Encapsulated Request in TLS early data (see
   Section 8 of [TLS] and [RFC8470]), a network-based adversary might be
   able to cause the request to be replayed.  In both cases, the effect
   of a replay attack and the mitigations that might be employed are
   similar to TLS early data.

   It is the responsibility of the application that uses Oblivious HTTP
   to either reject replayed requests or to ensure that replayed
   requests have no adverse effects on their operation.  This section
   describes some approaches that are universally applicable and
   suggestions for more targeted techniques.

   A Client or Oblivious Relay Resource MUST NOT automatically attempt
   to retry a failed request unless it receives a positive signal
   indicating that the request was not processed or forwarded.  The
   HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [HTTP/2]), the



Thomson & Wood          Expires 26 February 2024               [Page 27]

Internet-Draft               Oblivious HTTP                  August 2023


   HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [HTTP/3]), or a
   GOAWAY frame with a low enough identifier (in either protocol
   version) are all sufficient signals that no processing occurred.
   HTTP/1.1 [HTTP/1.1] provides no equivalent signal.  Connection
   failures or interruptions are not sufficient signals that no
   processing occurred.

   The anti-replay mechanisms described in Section 8 of [TLS] are
   generally applicable to Oblivious HTTP requests.  The encapsulated
   keying material (or enc) can be used in place of a nonce to uniquely
   identify a request.  This value is a high-entropy value that is
   freshly generated for every request, so two valid requests will have
   different values with overwhelming probability.

   The mechanism used in TLS for managing differences in Client and
   server clocks cannot be used as it depends on being able to observe
   previous interactions.  Oblivious HTTP explicitly prevents such
   linkability.

   The considerations in [RFC8470] as they relate to managing the risk
   of replay also apply, though there is no option to delay the
   processing of a request.

   Limiting requests to those with safe methods might not be
   satisfactory for some applications, particularly those that involve
   the submission of data to a server.  The use of idempotent methods
   might be of some use in managing replay risk, though it is important
   to recognize that different idempotent requests can be combined to be
   not idempotent.

   Even without replay prevention, the server-chosen response_nonce
   field ensures that responses have unique AEAD keys and nonces even
   when requests are replayed.

6.5.1.  Use of Date for Anti-Replay

   Clients SHOULD include a Date header field in Encapsulated Requests,
   unless the Client has prior knowledge that indicates that the
   Oblivious Gateway Resource does not use Date for anti-replay
   purposes.

   Though HTTP requests often do not include a Date header field, the
   value of this field might be used by a server to limit the amount of
   requests it needs to track if it needs to prevent replay attacks.

   An Oblivious Gateway Resource can maintain state for requests for a
   small window of time over which it wishes to accept requests.  The
   Oblivious Gateway Resource can store all requests it processes within



Thomson & Wood          Expires 26 February 2024               [Page 28]

Internet-Draft               Oblivious HTTP                  August 2023


   this window.  Storing just the enc field of a request, which should
   be unique to each request, is sufficient.  The Oblivious Gateway
   Resource can reject any request that is the same as one that was
   previously answered within that time window or if the Date header
   field from the decrypted request is outside of the current time
   window.

   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
   enough to allow for differences in clocks.  Insufficient tolerance of
   time differences could result in valid requests being unnecessarily
   rejected.  Beyond allowing for multiple round trip times -- to
   account for retransmission -- network delays are unlikely to be
   significant in determining the size of the window, unless all
   potential Clients are known to have excellent time-keeping.  A
   specific window size might need to be determined experimentally.

   Oblivious Gateway Resources MUST NOT treat the time window as secret
   information.  An attacker can actively probe with different values
   for the Date field to determine the time window over which the server
   will accept responses.

6.5.2.  Correcting Clock Differences

   An Oblivious Gateway Resource can reject requests that contain a Date
   value that is outside of its active window with a 400 series status
   code.  The problem type [PROBLEM] of "https://iana.org/assignments/
   http-problem-types#date" is defined to allow the server to signal
   that the Date value in the request was unacceptable.

   Figure 8 shows an example response in HTTP/1.1 format.

   HTTP/1.1 400 Bad Request
   Date: Mon, 07 Feb 2022 00:28:05 GMT
   Content-Type: application/problem+json
   Content-Length: 128

   {"type":"https://iana.org/assignments/http-problem-types#date",
   "title": "date field in request outside of acceptable range"}

             Figure 8: Example Rejection of Request Date Field

   Disagreements about time are unlikely if both Client and Oblivious
   Gateway Resource have a good source of time; see [NTP].  However,
   clock differences are known to be commonplace; see Section 7.1 of
   [CLOCKSKEW].





Thomson & Wood          Expires 26 February 2024               [Page 29]

Internet-Draft               Oblivious HTTP                  August 2023


   Including a Date header field in the response allows the Client to
   correct clock errors by retrying the same request using the value of
   the Date field provided by the Oblivious Gateway Resource.  The value
   of the Date field can be copied if the response is fresh, with an
   adjustment based on the Age field otherwise; see Section 4.2 of
   [HTTP-CACHING].  When retrying a request, the Client MUST create a
   fresh encryption of the modified request, using a new HPKE context.

   +---------+       +-------------------+      +----------+
   | Client  |       | Relay and Gateway |      | Target   |
   |         |       |     Resources     |      | Resource |
   +----+----+       +----+-----------+--+      +----+-----+
        |                 |           |              |
        |                 |           |              |
        |  Request        |           |              |
        +============================>+------------->|
        |                 |           |              |
        |                 |           | 400 Response |
        |                 |           |       + Date |
        |<============================+<-------------+
        |                 |           |              |
        |  Request        |           |              |
        |  + Updated Date |           |              |
        +============================>+------------->|
        |                 |           |              |

               Figure 9: Retrying with an Updated Date Field

   Retrying immediately allows the Oblivious Gateway Resource to measure
   the round trip time to the Client.  The observed delay might reveal
   something about the location of the Client.  Clients could delay
   retries to add some uncertainty to any observed delay.

   Intermediaries can sometimes rewrite the Date field when forwarding
   responses.  This might cause problems if the Oblivious Gateway
   Resource and intermediary clocks differ by enough to cause the retry
   to be rejected.  Therefore, Clients MUST NOT retry a request with an
   adjusted date more than once.

   Oblivious Gateway Resources that condition their responses on the
   Date header field SHOULD either ensure that intermediaries do not
   cache responses (by including a Cache-Control directive of no-store)
   or designate the response as conditional on the value of the Date
   request header field (by including the token "date" in a Vary header
   field).






Thomson & Wood          Expires 26 February 2024               [Page 30]

Internet-Draft               Oblivious HTTP                  August 2023


   Clients MUST NOT use the date provided by the Oblivious Gateway
   Resource for any other purpose, including future requests to any
   resource.  Any request that uses information provided by the
   Oblivious Gateway Resource might be correlated using that
   information.

6.6.  Forward Secrecy

   This document does not provide forward secrecy for either requests or
   responses during the lifetime of the key configuration.  A measure of
   forward secrecy can be provided by generating a new key configuration
   then deleting the old keys after a suitable period.

6.7.  Post-Compromise Security

   This design does not provide post-compromise security for responses.

   A Client only needs to retain keying material that might be used to
   compromise the confidentiality and integrity of a response until that
   response is consumed, so there is negligible risk associated with a
   Client compromise.

   A server retains a secret key that might be used to remove protection
   from messages over much longer periods.  A server compromise that
   provided access to the Oblivious Gateway Resource secret key could
   allow an attacker to recover the plaintext of all requests sent
   toward affected keys and all of the responses that were generated.

   Even if server keys are compromised, an adversary cannot access
   messages exchanged by the Client with the Oblivious Relay Resource as
   messages are protected by TLS.  Use of a compromised key also
   requires that the Oblivious Relay Resource cooperate with the
   attacker or that the attacker is able to compromise these TLS
   connections.

   The total number of messages affected by server key compromise can be
   limited by regular rotation of server keys.

6.8.  Client Clock Exposure

   Including a Date field in requests reveals some information about the
   Client clock.  This might be used to fingerprint Clients [UWT] or to
   identify Clients that are vulnerable to attacks that depend on
   incorrect clocks.







Thomson & Wood          Expires 26 February 2024               [Page 31]

Internet-Draft               Oblivious HTTP                  August 2023


   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
   requests over time.  However, this increases the risk that their
   request is rejected as outside the acceptable window.

6.9.  Media Type Security

   The key configuration media type defined in Section 3.2 represents
   keying material.  The content of this media type is not active (see
   Section 4.6 of [RFC6838]), but it governs how a Client might interact
   with an Oblivious Gateway Resource.  The security implications of
   processing it are described in Section 6.1; privacy implications are
   described in Section 7.

   The security implications of handling the message media types defined
   in Section 4.5 is covered in other parts of this section in more
   detail.  However, these message media types are also encrypted
   encapsulations of HTTP requests and responses.

   HTTP messages contain content, which can use any media type.  In
   particular, requests are processed by an Oblivious Target Resource,
   which - as an HTTP resource - defines how content is processed; see
   Section 3.1 of [HTTP].  HTTP clients can also use resource identity
   and response content to determine how content is processed.
   Consequently, the security considerations of Section 17 of [HTTP]
   also apply to the handling of the content of these media types.

6.10.  Separate Gateway and Target

   This document generally assumes that the same entity operates the
   Oblivious Gateway Resource and the Target Resource.  However, as the
   Oblivious Gateway Resource performs generic HTTP processing, the use
   of forwarding cannot be completely precluded.

   The scheme specified in the Encapsulated Request determines the
   security requirements for any protocol that is used between the
   Oblivious Gateway and Target Resources.  Using HTTPS is RECOMMENDED;
   see Section 6.3.

   A Target Resource that is operated on a different server from the
   Oblivious Gateway Resource is an ordinary HTTP resource.  A Target
   Resource can privilege requests that are forwarded by a given
   Oblivious Gateway Resource if it trusts the operator of the Oblivious
   Gateway Resource to only forward requests that meet the expectations
   of the Target Resource.  Otherwise, the Target Resource treats
   requests from an Oblivious Gateway Resource no differently than any
   other HTTP client.




Thomson & Wood          Expires 26 February 2024               [Page 32]

Internet-Draft               Oblivious HTTP                  August 2023


   For instance, an Oblivious Gateway Resource might -- possibly with
   the help of Oblivious Relay Resources -- be trusted not to forward an
   excessive volume of requests.  This might allow the Target Resource
   to accept a greater volume of requests from that Oblivious Gateway
   Resource relative to other HTTP clients.

   An Oblivious Gateway Resource could implement policies that improve
   the ability of the Target Resource to implement policy exemptions,
   such as only forwarding requests toward specific Target Resources
   according to an allowlist; see Section 6.3.

7.  Privacy Considerations

   One goal of this design is that independent Client requests are only
   linkable by their content.  However, the choice of Client
   configuration might be used to correlate requests.  A Client
   configuration includes the Oblivious Relay Resource URI, the
   Oblivious Gateway key configuration, and Oblivious Gateway Resource
   URI.  A configuration is active if Clients can successfully use it
   for interacting with a target.

   Oblivious Relay and Gateway Resources can identify when requests use
   the same configuration by matching the key ID from the key
   configuration or the Oblivious Gateway Resource URI.  The Oblivious
   Gateway Resource might use the source address of requests to
   correlate requests that use an Oblivious Relay Resource run by the
   same operator.  If the Oblivious Gateway Resource is willing to use
   trial decryption, requests can be further separated into smaller
   groupings based on the keys that are used.

   Each active Client configuration partitions the Client anonymity set.
   In practice, it is infeasible to reduce the number of active
   configurations to one.  Enabling diversity in choice of Oblivious
   Relay Resource naturally increases the number of active
   configurations.  More than one configuration might need to be active
   to allow for key rotation and server maintenance.

   Client privacy depends on having each configuration used by many
   other Clients.  It is critical to prevent the use of unique Client
   configurations, which might be used to track individual Clients, but
   it is also important to avoid creating small groupings of Clients
   that might weaken privacy protections.

   A specific method for a Client to acquire configurations is not
   included in this specification.  Applications using this design MUST
   provide accommodations to mitigate tracking using Client
   configurations.  [CONSISTENCY] provides options for ensuring that
   Client configurations are consistent between Clients.



Thomson & Wood          Expires 26 February 2024               [Page 33]

Internet-Draft               Oblivious HTTP                  August 2023


   The content of requests or responses, if used in forming new
   requests, can be used to correlate requests.  This includes obvious
   methods of linking requests, like cookies [COOKIES], but it also
   includes any information in either message that might affect how
   subsequent requests are formulated.  For example, [FIELDING]
   describes how interactions that are individually stateless can be
   used to build a stateful system when a Client acts on the content of
   a response.

8.  Operational and Deployment Considerations

   This section discusses various operational and deployment
   considerations.

8.1.  Performance Overhead

   Using Oblivious HTTP adds both cryptographic overhead and latency to
   requests relative to a simple HTTP request-response exchange.
   Deploying relay services that are on path between Clients and servers
   avoids adding significant additional delay due to network topology.
   A study of a similar system [ODOH-PETS] found that deploying proxies
   close to servers was most effective in minimizing additional latency.

8.2.  Resource Mappings

   This protocol assumes a fixed, one-to-one mapping between the
   Oblivious Relay Resource and the Oblivious Gateway Resource.  This
   means that any encrypted request sent to the Oblivious Relay Resource
   will always be forwarded to the Oblivious Gateway Resource.  This
   constraint was imposed to simplify relay configuration and mitigate
   against the Oblivious Relay Resource being used as a generic relay
   for unknown Oblivious Gateway Resources.  The relay will only forward
   for Oblivious Gateway Resources that it has explicitly configured and
   allowed.

   It is possible for a server to be configured with multiple Oblivious
   Relay Resources, each for a different Oblivious Gateway Resource as
   needed.  If the goal is to support a large number of Oblivious
   Gateway Resources, Clients might be provided with a URI template
   [TEMPLATE], from which multiple Oblivious Relay Resources could be
   constructed.










Thomson & Wood          Expires 26 February 2024               [Page 34]

Internet-Draft               Oblivious HTTP                  August 2023


8.3.  Network Management

   Oblivious HTTP might be incompatible with network interception
   regimes, such as those that rely on configuring Clients with trust
   anchors and intercepting TLS connections.  While TLS might be
   intercepted successfully, interception middleboxes devices might not
   receive updates that would allow Oblivious HTTP to be correctly
   identified using the media types defined in Section 9.2 and
   Section 9.3.

   Oblivious HTTP has a simple key management design that is not
   trivially altered to enable interception by intermediaries.  Clients
   that are configured to enable interception might choose to disable
   Oblivious HTTP in order to ensure that content is accessible to
   middleboxes.

9.  IANA Considerations

   Please update the "Media Types" registry at
   https://iana.org/assignments/media-types
   (https://iana.org/assignments/media-types) for the media types
   "application/ohttp-keys" (Section 9.1), "message/ohttp-req"
   (Section 9.2), and "message/ohttp-res" (Section 9.3), following the
   procedures of [RFC6838].

   Please update the "HTTP Problem Types" registry at
   https://iana.org/assignments/http-problem-types
   (https://iana.org/assignments/http-problem-types) for the types
   "date" (Section 9.4) and "ohttp-key" (Section 9.5).

9.1.  application/ohttp-keys Media Type

   The "application/ohttp-keys" media type identifies a key
   configuration used by Oblivious HTTP.

   Type name:  application
   Subtype name:  ohttp-keys
   Required parameters:  N/A
   Optional parameters:  N/A
   Encoding considerations:  "binary"
   Security considerations:  see Section 6.9
   Interoperability considerations:  N/A
   Published specification:  this specification
   Applications that use this media type:  This type identifies a key
      configuration as used by Oblivious HTTP and applications that use
      Oblivious HTTP.
   Fragment identifier considerations:  N/A
   Additional information:  Magic number(s):  N/A



Thomson & Wood          Expires 26 February 2024               [Page 35]

Internet-Draft               Oblivious HTTP                  August 2023


                            Deprecated alias names for this type:  N/A
                            File extension(s):  N/A
                            Macintosh file type code(s):  N/A
   Person and email address to contact for further information:  see Aut
      hors' Addresses section
   Intended usage:  COMMON
   Restrictions on usage:  N/A
   Author:  see Authors' Addresses section
   Change controller:  IETF

9.2.  message/ohttp-req Media Type

   The "message/ohttp-req" identifies an encrypted binary HTTP request.
   This is a binary format that is defined in Section 4.3.

   Type name:  message
   Subtype name:  ohttp-req
   Required parameters:  N/A
   Optional parameters:  N/A
   Encoding considerations:  "binary"
   Security considerations:  see Section 6.9
   Interoperability considerations:  N/A
   Published specification:  this specification
   Applications that use this media type:  Oblivious HTTP and
      applications that use Oblivious HTTP use this media type to
      identify encapsulated binary HTTP requests.
   Fragment identifier considerations:  N/A
   Additional information:  Magic number(s):  N/A
                            Deprecated alias names for this type:  N/A
                            File extension(s):  N/A
                            Macintosh file type code(s):  N/A
   Person and email address to contact for further information:  see Aut
      hors' Addresses section
   Intended usage:  COMMON
   Restrictions on usage:  N/A
   Author:  see Authors' Addresses section
   Change controller:  IETF

9.3.  message/ohttp-res Media Type

   The "message/ohttp-res" identifies an encrypted binary HTTP response.
   This is a binary format that is defined in Section 4.4.

   Type name:  message
   Subtype name:  ohttp-res
   Required parameters:  N/A
   Optional parameters:  N/A
   Encoding considerations:  "binary"



Thomson & Wood          Expires 26 February 2024               [Page 36]

Internet-Draft               Oblivious HTTP                  August 2023


   Security considerations:  see Section 6.9
   Interoperability considerations:  N/A
   Published specification:  this specification
   Applications that use this media type:  Oblivious HTTP and
      applications that use Oblivious HTTP use this media type to
      identify encapsulated binary HTTP responses.
   Fragment identifier considerations:  N/A
   Additional information:  Magic number(s):  N/A
                            Deprecated alias names for this type:  N/A
                            File extension(s):  N/A
                            Macintosh file type code(s):  N/A
   Person and email address to contact for further information:  see Aut
      hors' Addresses section
   Intended usage:  COMMON
   Restrictions on usage:  N/A
   Author:  see Authors' Addresses section
   Change controller:  IETF

9.4.  Registration of "date" Problem Type

   IANA are requested to create a new entry in the "HTTP Problem Type"
   registry established by [PROBLEM].

   Type URI:  https://iana.org/assignments/http-problem-types#date
   Title:  Date Not Acceptable
   Recommended HTTP Status Code:  400
   Reference:  Section 6.5.2 of this document

9.5.  Registration of "ohttp-key" Problem Type

   IANA are requested to create a new entry in the "HTTP Problem Type"
   registry established by [PROBLEM].

   Type URI:  https://iana.org/assignments/http-problem-types#ohttp-key
   Title:  Oblivious HTTP key configuration not acceptable
   Recommended HTTP Status Code:  400
   Reference:  Section 5.3 of this document

10.  References

10.1.  Normative References

   [ASCII]    Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/rfc/rfc20>.






Thomson & Wood          Expires 26 February 2024               [Page 37]

Internet-Draft               Oblivious HTTP                  August 2023


   [BINARY]   Thomson, M. and C. A. Wood, "Binary Representation of HTTP
              Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9292>.

   [HPKE]     Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [HTTP-CACHING]
              Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Caching", STD 98, RFC 9111,
              DOI 10.17487/RFC9111, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9111>.

   [PROBLEM]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
              for HTTP APIs", Work in Progress, Internet-Draft, draft-
              ietf-httpapi-rfc7807bis-07, 28 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
              rfc7807bis-07>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8470]  Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
              Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
              2018, <https://www.rfc-editor.org/rfc/rfc8470>.




Thomson & Wood          Expires 26 February 2024               [Page 38]

Internet-Draft               Oblivious HTTP                  August 2023


   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

10.2.  Informative References

   [CLOCKSKEW]
              Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
              Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
              "Where the Wild Warnings Are: Root Causes of Chrome HTTPS
              Certificate Errors", ACM, Proceedings of the 2017 ACM
              SIGSAC Conference on Computer and Communications Security,
              DOI 10.1145/3133956.3134007, October 2017,
              <https://doi.org/10.1145/3133956.3134007>.

   [CONSISTENCY]
              Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
              "Key Consistency and Discovery", Work in Progress,
              Internet-Draft, draft-ietf-privacypass-key-consistency-01,
              10 July 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-privacypass-key-consistency-01>.

   [COOKIES]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6265>.

   [DMS2004]  Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
              Second-Generation Onion Router", August 2004,
              <https://svn.torproject.org/svn/projects/design-paper/tor-
              design.html>.

   [FIELDING] Fielding, R. T., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000,
              <https://www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.

   [FORWARDED]
              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              RFC 7239, DOI 10.17487/RFC7239, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7239>.

   [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

   [HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.



Thomson & Wood          Expires 26 February 2024               [Page 39]

Internet-Draft               Oblivious HTTP                  August 2023


   [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

   [NTP]      Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5905>.

   [ODOH]     Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
              Wood, "Oblivious DNS over HTTPS", RFC 9230,
              DOI 10.17487/RFC9230, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9230>.

   [ODOH-PETS]
              Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T.,
              Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A.
              Wood, "Oblivious DNS over HTTPS (ODoH): A Practical
              Privacy Enhancement to DNS", 7 January 2021,
              <https://www.petsymposium.org/2021/files/papers/issue4/
              popets-2021-0085.pdf>.

   [OHTTP-ANALYSIS]
              Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August
              2021, <https://github.com/cloudflare/ohttp-analysis>.

   [PRIO]     Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
              and Scalable Computation of Aggregate Statistics", 14
              March 2017, <https://crypto.stanford.edu/prio/paper.pdf>.

   [RANDOM]   Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6570>.





Thomson & Wood          Expires 26 February 2024               [Page 40]

Internet-Draft               Oblivious HTTP                  August 2023


   [UWT]      Nottingham, M., "Unsanctioned Web Tracking", 17 July 2015,
              <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.

   [X25519]   Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/rfc/rfc7748>.

Appendix A.  Complete Example of a Request and Response

   A single request and response exchange is shown here.  Binary values
   (key configuration, secret keys, the content of messages, and
   intermediate values) are shown in hexadecimal.  The request and
   response here are minimal; the purpose of this example is to show the
   cryptographic operations.  In this example, the Client is configured
   with the Oblivious Relay Resource URI of
   https://proxy.example.org/request.example.net/proxy, and the proxy is
   configured to map requests to this URI to the Oblivious Gateway
   Resource URI https://example.com/oblivious/request.  The Target
   Resource URI, i.e., the resource the Client ultimately wishes to
   query, is https://example.com.

   To begin the process, the Oblivious Gateway Resource generates a key
   pair.  In this example the server chooses DHKEM(X25519, HKDF-SHA256)
   and generates an X25519 key pair [X25519].  The X25519 secret key is:

   3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a

   The Oblivious Gateway Resource constructs a key configuration that
   includes the corresponding public key as follows:

   01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
   79815500080001000100010003

   This key configuration is somehow obtained by the Client.  Then, when
   a Client wishes to send an HTTP GET request to the target
   https://example.com, it constructs the following binary HTTP message:

   00034745540568747470730b6578616d706c652e636f6d012f

   The Client then reads the Oblivious Gateway Resource key
   configuration and selects a mutually supported KDF and AEAD.  In this
   example, the Client selects HKDF-SHA256 and AES-128-GCM.  The Client
   then generates an HPKE sending context that uses the server public
   key.  This context is constructed from the following ephemeral secret
   key:

   bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73




Thomson & Wood          Expires 26 February 2024               [Page 41]

Internet-Draft               Oblivious HTTP                  August 2023


   The corresponding public key is:

   4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472

   And an info parameter of:

   6d6573736167652f626874747020726571756573740001002000010001

   Applying the Seal operation from the HPKE context produces an
   encrypted message, allowing the Client to construct the following
   Encapsulated Request:

   010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
   9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
   5e7d86b83dd440b2c0185204b4d63525

   The Client then sends this to the Oblivious Relay Resource in a POST
   request, which might look like the following HTTP/1.1 request:

   POST /request.example.net/proxy HTTP/1.1
   Host: proxy.example.org
   Content-Type: message/ohttp-req
   Content-Length: 78

   <content is the Encapsulated Request above>

   The Oblivious Relay Resource receives this request and forwards it to
   the Oblivious Gateway Resource, which might look like:

   POST /oblivious/request HTTP/1.1
   Host: example.com
   Content-Type: message/ohttp-req
   Content-Length: 78

   <content is the Encapsulated Request above>

   The Oblivious Gateway Resource receives this request, selects the key
   it generated previously using the key identifier from the message,
   and decrypts the message.  As this request is directed to the same
   server, the Oblivious Gateway Resource does not need to initiate an
   HTTP request to the Target Resource.  The request can be served
   directly by the Target Resource, which generates a minimal response
   (consisting of just a 200 status code) as follows:

   0140c8

   The response is constructed by exporting a secret from the HPKE
   context:



Thomson & Wood          Expires 26 February 2024               [Page 42]

Internet-Draft               Oblivious HTTP                  August 2023


   62d87a6ba569ee81014c2641f52bea36

   The key derivation for the Encapsulated Response uses both the
   encapsulated KEM key from the request and a randomly selected nonce.
   This produces a salt of:

   4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
   c789e7151fcba46158ca84b04464910d

   The salt and secret are both passed to the Extract function of the
   selected KDF (HKDF-SHA256) to produce a pseudorandom key of:

   979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db

   The pseudorandom key is used with the Expand function of the KDF and
   an info field of "key" to produce a 16-byte key for the selected AEAD
   (AES-128-GCM):

   5d0172a080e428b16d298c4ea0db620d

   With the same KDF and pseudorandom key, an info field of "nonce" is
   used to generate a 12-byte nonce:

   f6bf1aeb88d6df87007fa263

   The AEAD Seal() function is then used to encrypt the response, which
   is added to the randomized nonce value to produce the Encapsulated
   Response:

   c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
   857fbd

   The Oblivious Gateway Resource constructs a response with the same
   content:

   HTTP/1.1 200 OK
   Date: Wed, 27 Jan 2021 04:45:07 GMT
   Cache-Control: private, no-store
   Content-Type: message/ohttp-res
   Content-Length: 38

   <content is the Encapsulated Response>

   The same response might then be generated by the Oblivious Relay
   Resource which might change as little as the Date header.  The Client
   is then able to use the HPKE context it created and the nonce from
   the Encapsulated Response to construct the AEAD key and nonce and
   decrypt the response.



Thomson & Wood          Expires 26 February 2024               [Page 43]

Internet-Draft               Oblivious HTTP                  August 2023


Acknowledgments

   This design is based on a design for Oblivious DoH, described in
   [ODOH].  David Benjamin, Mark Nottingham, and Eric Rescorla made
   technical contributions.  The authors also thank Ralph Giles, Lucas
   Pardue, and Tommy Pauly for invaluable assistance.

Index

   C E K O T

      C

         Client  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 3.2, 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,



Thomson & Wood          Expires 26 February 2024               [Page 44]

Internet-Draft               Oblivious HTTP                  August 2023


            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 6; Section 2.2, Paragraph 3.8.1;
            Section 3, Paragraph 1; Section 3, Paragraph 3; Section 3,
            Paragraph 3; Section 3.2, Paragraph 3; Section 3.2,
            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;



Thomson & Wood          Expires 26 February 2024               [Page 45]

Internet-Draft               Oblivious HTTP                  August 2023


            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 1; Section 3.2, Paragraph 2;
            Section 3.2, Paragraph 3; 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 3.2, Paragraph 3; Section 3.2, Paragraph 3;
            Section 6.1, Paragraph 3

      O

         Oblivious Gateway Resource  Section 4.3, Paragraph 9.1.3
         Oblivious Gateway Resource  Section 1, Paragraph 4, Item 2;




Thomson & Wood          Expires 26 February 2024               [Page 46]

Internet-Draft               Oblivious HTTP                  August 2023


            Section 1, Paragraph 4, Item 3; Section 1, Paragraph 5;
            Section 1, Paragraph 6; 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;



Thomson & Wood          Expires 26 February 2024               [Page 47]

Internet-Draft               Oblivious HTTP                  August 2023


            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 4, Item 2;
            Section 1, Paragraph 5; Section 1, Paragraph 6; Section 1,
            Paragraph 6; 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




Thomson & Wood          Expires 26 February 2024               [Page 48]

Internet-Draft               Oblivious HTTP                  August 2023


            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

   Martin Thomson
   Mozilla
   Email: mt@lowentropy.net


   Christopher A. Wood
   Cloudflare
   Email: caw@heapingbits.net























Thomson & Wood          Expires 26 February 2024               [Page 49]