2.1.Applicability

Oblivious HTTP has limited applicability. Importantly, it requires explicitsupport from a willingOblivious Relay Resource andOblivious Gateway Resource,thereby limiting the use of Oblivious HTTP for generic applications;seeSection 6.3 for more information.¶

Many uses of HTTP benefit from being able to carry state between requests, suchas with cookies[COOKIES], authentication (Section 11 of [HTTP]), or evenalternative services[RFC7838]. Oblivious HTTP removes linkage at thetransport layer, which is only useful for an application that does not carrystate between requests.¶

Oblivious HTTP is primarily useful where the privacy risks associated withpossible stateful treatment of requests are sufficiently large that the cost ofdeploying this protocol can be justified. Oblivious HTTP is simpler and lesscostly than more robust systems, like Prio[PRIO] or Tor[DMS2004], whichcan 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 areseveral ways in which Oblivious HTTP is more expensive than a direct request:¶

• Each request requires at least two regular HTTP requests, which couldincrease latency.¶

• Each request is expanded in size with additional HTTP fields,encryption-related metadata, and Authenticated Encryption with Associated Data(AEAD) expansion.¶

• Deriving cryptographic keys and applying them for request andresponse protection takes non-negligible computational resources.¶

Examples of where preventing the linking of requests might justify these costsinclude:¶

DNS queries:

DNS queries made to a recursive resolver reveal information about therequester, particularly if linked to other queries.¶

Telemetry submission:

Applications that submit reports about their usage to their developers mightuse 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 tolearn something about that user even if the identity of the user werepseudonymous. Other examples include submitting anonymous surveys, makingsearch queries, or requesting location-specific content (such as retrievingtiles of a map display).¶

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

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 asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.¶

This document uses terminology from[HTTP] and defines several terms asfollows:¶

Client:

A Client originates Oblivious HTTP requests. A Client is also an HTTP clientin two ways: for theTarget Resource and for theOblivious RelayResource. However, when referring to the HTTP definition of client (Section 3.3 of [HTTP]), the term "HTTP client" is used; seeSection 5.¶

Encapsulated Request:

An HTTP request that is encapsulated in an HPKE-encrypted message; seeSection 4.3.¶

Encapsulated Response:

An HTTP response that is encapsulated in an HPKE-encrypted message; seeSection 4.4.¶

Oblivious Relay Resource:

An intermediary that forwardsEncapsulated Requests andResponses betweenClients and a singleOblivious Gateway Resource. In context, this can bereferred to simply as a "relay".¶

Oblivious Gateway Resource:

A resource that can receive anEncapsulated Request, extract the contents ofthat request, forward it to aTarget Resource, receive a response, encapsulatethat response, and then return the resultingEncapsulated Response. Incontext, this can be referred to simply as a "gateway".¶

Target Resource:

The resource that is the target of anEncapsulated Request. This resourcelogically handles only regular HTTP requests and responses, so it might beignorant of the use of Oblivious HTTP to reach it.¶

This document includes pseudocode that uses the functions and conventionsdefined in[HPKE].¶

Encoding an integer to a sequence of bytes in network byte order is describedusing the functionencode(n, v), wheren is the number of bytes andv isthe integer value. ASCII[ASCII] encoding of a strings isindicated using the functionencode_str(s).¶

Formats are described using notation fromSection 1.3 of [QUIC]. An extensionto that notation expresses the number of bits in a field using a simplemathematical function.¶

3.1.Key Configuration Encoding

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

Figure 2 shows a single key configuration.¶

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) ...,}

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

Key Identifier:

An 8-bit value that identifies the key used by theOblivious Gateway Resource.¶

HPKE KEM ID:

A 16-bit value that identifies the KEM used for the identified key as definedinSection 7.1 of [HPKE] or the"HPKE KEM Identifiers" registry.¶

HPKE Public Key:

The public key used by the gateway. The length of the public key isNpk, which isdetermined by the choice of HPKE KEM as defined inSection 4 of [HPKE].¶

HPKE Symmetric Algorithms Length:

A 16-bit integer in network byte order that encodes the length, in bytes, ofthe HPKE Symmetric Algorithms field that follows.¶

HPKE Symmetric Algorithms:

One or more pairs of identifiers for the different combinations of HPKE KDFand AEAD that the Oblivious Gateway Resource supports:¶

HPKE KDF ID:

A 16-bit HPKE KDF identifier as defined inSection 7.2 of [HPKE] or the"HPKE KDF Identifiers"registry.¶

HPKE AEAD ID:

A 16-bit HPKE AEAD identifier as defined inSection 7.3 of [HPKE] or the"HPKE AEAD Identifiers" registry.¶

3.2.Key Configuration Media Type

The "application/ohttp-keys" format is a media type that identifies a serializedcollection ofkey configurations. The content of this media type comprises oneor more key configuration encodings (seeSection 3.1). Each encodedconfiguration is prefixed with a 2-byte integer in network byte order thatindicates the length of the key configuration in bytes. The length-prefixedencodings are concatenated to form a list. SeeSection 9.1 for a definitionof the media type.¶

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

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

4.1.Request Format

A message in "message/ohttp-req" format protects a binary HTTP requestmessage; seeFigure 3.¶

Request {  Binary HTTP Message (..),}

This plaintext Request structure is encapsulated into a message in"message/ohttp-req" form by generating anEncapsulated Request. AnEncapsulated Request comprises a key identifier; HPKE parameters for the chosenKEM, KDF, and AEAD; the encapsulated KEM shared secret (orenc); and anHPKE-protected binary HTTP request message.¶

An Encapsulated Request is shown inFigure 4.Section 4.3 describesthe 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 (..),}

That is, anEncapsulated Request comprises a Key Identifier, an HPKE KEM ID, anHPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared Secret, and anHPKE-Protected Request. The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKEAEAD ID fields are defined inSection 3.1. The Encapsulated KEM SharedSecret is the output of theEncap() function for the KEM, which isNencbytes in length, as defined inSection 4 of [HPKE].¶

4.2.Response Format

A message in "message/ohttp-res" format protects a binary HTTP responsemessage; seeFigure 5.¶

Response {  Binary HTTP Message (..),}

This plaintext Response structure is encapsulated into a message in"message/ohttp-res" form by generating anEncapsulated Response. AnEncapsulated Response comprises a nonce and the AEAD-protected binary HTTPresponse message.¶

An Encapsulated Response is shown inFigure 6.Section 4.4 describesthe process for constructing and processing an Encapsulated Response.¶

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

That is, anEncapsulated Response contains a Nonce and an AEAD-ProtectedResponse. The Nonce field is eitherNn orNk bytes long, whichever islarger. TheNn andNk values correspond to parameters of the AEAD used inHPKE, which is defined inSection 7.3 of [HPKE] orthe "HPKE AEADIdentifiers" IANAregistry.NnandNk refer to the size of the AEAD nonce and key, respectively, in bytes.¶

4.3.Encapsulation of Requests

Clients encapsulate a request, identified asrequest, using values from akeyconfiguration:¶

• the key identifier from the configuration (key_id) with the correspondingKEM identified bykem_id,¶

• the public key from the configuration (pkR), and¶

• a combination of KDF (identified bykdf_id) and AEAD (identified byaead_id) that the Client selects from those in the key configuration.¶

The Client then constructs anEncapsulated Request,enc_request, from a binary-encoded HTTP request[BINARY] (request) as follows:¶

1. Construct a message header (hdr) by concatenating the values ofkey_id,kem_id,kdf_id, andaead_id as one 8-bit integer and three 16-bitintegers, respectively, each in network byte order.¶

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

3. Create a sending HPKE context by invokingSetupBaseS() (Section 5.1.1 of [HPKE]) with the public key of the receiverpkR andinfo. This yieldsthe contextsctxt and an encapsulation keyenc.¶

4. Encryptrequest by invoking theSeal() method onsctxt (Section 5.2 of [HPKE]) with empty associated dataaad, yielding ciphertextct.¶

5. Concatenate the values ofhdr,enc, andct. This yields an EncapsulatedRequest (enc_request).¶

Note thatenc is of fixed length, so there is no ambiguity in parsing thisstructure.¶

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)

AnOblivious Gateway Resource decrypts an Encapsulated Request by reversing thisprocess. To decapsulate an Encapsulated Request,enc_request:¶

1. Parseenc_request intokey_id,kem_id,kdf_id,aead_id,enc, andct (indicated using the functionparse() in pseudocode). The ObliviousGateway Resource is then able to find the HPKE private key,skR,corresponding tokey_id.¶

   1. Ifkey_id does not identify a key matching the type ofkem_id, theOblivious Gateway Resource returns an error.¶

   2. Ifkdf_id andaead_id identify a combination of KDF and AEAD that theOblivious Gateway Resource is unwilling to use withskR, the ObliviousGateway Resource returns an error.¶

2. Build a sequence of bytes (info) by concatenating the ASCII-encoded string"message/bhttp request"; a zero byte;key_id as an 8-bit integer; pluskem_id,kdf_id, andaead_id as three 16-bit integers.¶

3. Create a receiving HPKE context,rctxt, by invokingSetupBaseR()(Section 5.1.1 of [HPKE]) withskR,enc, andinfo.¶

4. Decryptct by invoking theOpen() method onrctxt (Section 5.2 of [HPKE]), with an empty associated dataaad, yieldingrequest or an erroron failure. If decryption fails, the Oblivious Gateway Resource returns anerror.¶

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 canencapsulate a response.¶

4.4.Encapsulation of Responses

Oblivious Gateway Resources generate anEncapsulated Response (enc_response)from a binary-encoded HTTP response[BINARY] (response). The ObliviousGateway Resource uses the HPKE receiver context (rctxt) as the HPKE context(context) as follows:¶

1. Export a secret (secret) fromcontext, using the string "message/bhttpresponse" as theexporter_context parameter tocontext.Export; seeSection 5.3 of [HPKE]. The length of this secret ismax(Nn, Nk), whereNn andNk are the length of the AEAD key and nonce that are associated withcontext.Note:Section 4.6 discusses how alternative message formats might use adifferentcontext value.¶

2. Generate a random value of lengthmax(Nn, Nk) bytes, calledresponse_nonce.¶

3. Extract a pseudorandom key (prk) using theExtract function provided bythe KDF algorithm associated withcontext. Theikm input to thisfunction issecret; thesalt input is the concatenation ofenc (fromenc_request) andresponse_nonce.¶

4. Use theExpand function provided by the same KDF to create an AEAD key,key, of lengthNk -- the length of the keys used by the AEAD associatedwithcontext. Generatingaead_key uses a label of "key".¶

5. Use the sameExpand function to create a nonce,nonce, of lengthNn --the length of the nonce used by the AEAD. Generatingaead_nonce uses alabel of "nonce".¶

6. Encryptresponse, passing the AEAD function Seal the values ofaead_key,aead_nonce, an emptyaad, and apt input ofresponse. This yieldsct.¶

7. Concatenateresponse_nonce andct, yielding an Encapsulated Response,enc_response. Note thatresponse_nonce is of fixed length, so there is noambiguity in parsing eitherresponse_nonce orct.¶

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 parseenc_response intoresponse_nonce andct. Then, theyfollow the same process to derive values foraead_key andaead_nonce, usingtheir sending HPKE context,sctxt, as the HPKE context,context.¶

The Client uses these values to decryptct using the AEAD functionOpen.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; seeSections9.2 and9.3 for definitions of these media types.¶

Evolution of the format of Encapsulated Requests and Responses is supportedthrough the definition of new formats that are identified by new media types.New media types might be defined to use a similar encapsulation with a differentHTTP message format than in[BINARY]; seeSection 4.6 for guidance onreusing this encapsulation method. Alternatively, a new encapsulation methodmight be defined.¶

4.6.Repurposing the Encapsulation Format

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

Future specifications may repurpose the encapsulation mechanism described inthis 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 usethe "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 fullvalue) for request encryption and the string "application/dns-message response"for response encryption.¶

5.1.Informational Responses

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

In particular, theExpect header field with 100-continue (seeSection 10.1.1 of [HTTP]) cannot be used.ClientsMUST NOT construct a request that includes a100-continue expectation; theOblivious Gateway ResourceMUST generate an errorif a 100-continue expectation is received.¶

5.2.Errors

A server that receives an invalid message for any reasonMUST generate an HTTPresponse with a 4xx status code.¶

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

Errors detected by the Oblivious Gateway Resource after successfully removingencapsulation and errors detected by theTarget ResourceMUST be sent in anEncapsulated Response. This might be because theEncapsulated Request ismalformed or the Target Resource does not produce a response. In either case,the Oblivious Gateway Resource can generate a response with an appropriate errorstatus code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections15.5.1 and15.6.5 of[HTTP], respectively). This response is encapsulated inthe same way as a successful response.¶

Errors in the encapsulation of requests mean that responses cannot beencapsulated. This includes cases where thekey configuration is incorrect oroutdated. The Oblivious Gateway Resource can generate and send a response witha 4xx status code to the Oblivious Relay Resource. This responseMAY beforwarded to theClient or treated by the Oblivious Relay Resource as a failure.If a Client receives a response that is not an Encapsulated Response, this couldindicate that the Client configuration used to construct the request isincorrect or out of date.¶

5.3.Signaling Key Configuration Problems

The problem type[PROBLEM] of"https://iana.org/assignments/http-problem-types#ohttp-key" is defined in thissection. AnOblivious Gateway ResourceMAY use this problem type in a responseto indicate that anEncapsulated Request used an outdated or incorrectkeyconfiguration.¶

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

HTTP/1.1 400 Bad RequestDate: Mon, 07 Feb 2022 00:28:05 GMTContent-Type: application/problem+jsonContent-Length: 106{"type":"https://iana.org/assignments/http-problem-types#ohttp-key","title": "key identifier unknown"}

As this response cannot be encrypted, it might not reach theClient. A Clientcannot rely on theOblivious Gateway Resource using this problem type. A Clientmight also be configured to disregard responses that are not encapsulated on thebasis that they might be subject to observation or modification by an ObliviousRelay Resource. A Client might manage the risk of an outdated key configurationusing a heuristic approach whereby it periodically refreshes its keyconfiguration if it receives a response with an error status code that has notbeen encapsulated.¶

6.1.Client Responsibilities

BecauseClients do not authenticate theTarget Resource when using ObliviousHTTP, ClientsMUST have some mechanism to authorize anOblivious GatewayResource for use with a Target Resource. One possible means of authorization isan allowlist. This ensures that Oblivious Gateway Resources are not misused toforward traffic to arbitrary Target Resources.Section 6.3describes similar responsibilities that apply to Oblivious Gateway Resources.¶

ClientsMUST ensure that thekey configuration they select for generatingEncapsulated Requests is integrity protected and authenticated so that it canbe attributed to the Oblivious Gateway Resource; seeSection 3.¶

Since Clients connect directly to theOblivious Relay Resource instead of theTarget Resource, application configurations wherein Clients make policydecisions about target connections, e.g., to apply certificate pinning, areincompatible with Oblivious HTTP. In such cases, alternative technologies suchas HTTP CONNECT (Section 9.3.6 of [HTTP]) can be used. Applications couldimplement related policies on key configurations and relay connections, thoughthese might not provide the same properties as policies enforced directly ontarget connections. Instead, when this difference is relevant, applications canconnect directly to the target at the cost of either privacy or performance.¶

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

ClientsMUST generate a new HPKE context for every request, using a good sourceof entropy[RANDOM] for generating keys. Key reuse not only risksrequests being linked but also could expose request and response contents to therelay.¶

The request the Client sends to the Oblivious Relay Resource only requiresminimal information; seeSection 5. The request that carries theEncapsulated Request and that is sent to the Oblivious Relay ResourceMUST NOTinclude identifying information unless the Client can trust that thisinformation is removed by the relay. A ClientMAY include information only forthe Oblivious Relay Resource in header fields identified by theConnectionheader field if it trusts the relay to remove these, as required bySection 7.6.1 of [HTTP]. The Client needs to trust that the relay does not replicate thesource addressing information in the request it forwards.¶

Clients rely on the Oblivious Relay Resource to forward Encapsulated Requestsand Responses. However, the relay can only refuse to forward messages; itcannot inspect or modify the contents of Encapsulated Requests or Responses.¶

6.2.Relay Responsibilities

The relay that serves theOblivious Relay Resource has a very simple functionto perform. For each request it receives, it makes a request of theObliviousGateway Resource that includes the same content. When it receives a response,it sends a response to theClient that includes the content of the responsefrom the Oblivious Gateway Resource.¶

When forwarding a request, the relayMUST follow the forwarding rules inSection 7.6 of [HTTP]. A generic HTTP intermediary implementation is suitablefor the purposes of serving an Oblivious Relay Resource, but additional care isneeded to ensure that Client privacy is maintained.¶

Firstly, a generic implementation will forward unknown fields. For ObliviousHTTP, an Oblivious Relay ResourceSHOULD NOT forward unknown fields. ThoughClients are not expected to include fields that might contain identifyinginformation, removing unknown fields removes this privacy risk.¶

Secondly, generic implementations are often configured to augment requests withinformation about the Client, such as the Via field or the Forwarded field[FORWARDED]. A relayMUST NOT add information when forwardingrequests that might be used to identify Clients, except for information thata Client is aware of; seeSection 6.2.1.¶

Finally, a relay can also generate responses, though it is assumed to not beable to examine the content of a request (other than to observe the choice ofkey identifier, KDF, and AEAD); therefore, it is also assumed that it cannotgenerate anEncapsulated Response.¶

6.3.Server Responsibilities

TheOblivious Gateway Resource can be operated by a different entity than theTarget Resource. However, this means that theClient needs to trust theOblivious Gateway Resource not to modify requests or responses. This analysisconcerns itself with a deployment scenario where a single server provides boththe Oblivious Gateway Resource and Target Resource.¶

A server that operates both Oblivious Gateway and Target Resources isresponsible for removing request encryption, generating a response to theEncapsulated Request, and encrypting the response.¶

Servers should account for traffic analysis based on response size or generationtime. Techniques such as padding or timing delays can help protect against suchattacks; seeSection 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 andrelay for managing denial of service; seeSection 6.2.2. Moreover, the ObliviousGateway ResourceSHOULD have some mechanism to ensure that the Oblivious GatewayResource is not misused as a relay for HTTP messages to an arbitrary TargetResource, 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 TargetResources are not on the same origin. If messages are forwarded between theseresources without the protections afforded by HTTPS, they could be inspected ormodified by a network attacker. Note that a request could be forwarded withoutprotection if the two resources share an origin.¶

6.4.Key Management

AnOblivious Gateway Resource needs to have a plan for replacing keys. Thismight include regular replacement of keys, which can be assigned new keyidentifiers. If an Oblivious Gateway Resource receives a request that contains akey identifier that it does not understand or that corresponds to a key that hasbeen 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 correspondsto the key identifier, but theEncapsulated Request cannot be successfullydecrypted using the key.¶

A serverMUST ensure that the HPKE keys it uses are not valid for any otherprotocol that uses HPKE with the "message/bhttp request" label. Designers ofprotocols that reuse this encryption format, especially new versions of thisprotocol, can ensure key diversity by choosing a different label in their use ofHPKE. The "message/bhttp response" label was chosen for symmetry only as itprovides key diversity only within the HPKE context created using the"message/bhttp request" label; seeSection 4.6.¶

6.5.Replay Attacks

A server is responsible for either rejecting replayed requests or ensuring thatthe effect of replays does not adversely affectClients or resources.¶

Encapsulated Requests can be copied and replayed by theOblivious RelayResource. The threat model for Oblivious HTTP allows the possibility that anOblivious Relay Resource might replay requests. Furthermore, if a Client sendsan Encapsulated Request in TLS early data (seeSection 8 of [TLS] and[RFC8470]), a network-based adversary might be able to cause the request tobe replayed. In both cases, the effect of a replay attack and the mitigationsthat might be employed are similar to TLS early data.¶

It is the responsibility of the application that uses Oblivious HTTP to eitherreject replayed requests or ensure that replayed requests have no adverseeffect on their operation. This section describes some approaches that areuniversally applicable and suggestions for more targeted techniques.¶

A Client or Oblivious Relay ResourceMUST NOT automatically attempt to retry afailed request unless it receives a positive signal indicating that the requestwas not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [HTTP/2]), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [HTTP/3]), or a GOAWAY frame with a low enough identifier (in either protocolversion) are all sufficient signals that no processing occurred. HTTP/1.1[HTTP/1.1] provides no equivalent signal. Connection failures or interruptionsare not sufficient signals that no processing occurred.¶

The anti-replay mechanisms described inSection 8 of [TLS] are generallyapplicable to Oblivious HTTP requests. The encapsulated keying material (orenc) can be used in place of a nonce to uniquely identify a request. Thisvalue is a high-entropy value that is freshly generated for every request, sotwo valid requests will have different values with overwhelming probability.¶

The mechanism used in TLS for managing differences in Client and server clockscannot 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 ofreplay also apply, though there is no option to delay the processing of arequest.¶

Limiting requests to those with safe methods might not be satisfactory for someapplications, particularly those that involve the submission of data to aserver. The use of idempotent methods might be of some use in managing replayrisk, though it is important to recognize that different idempotent requestscan be combined to be not idempotent.¶

Even without replay prevention, the server-chosenresponse_nonce fieldensures that responses have unique AEAD keys and nonces even when requests arereplayed.¶

HTTP/1.1 400 Bad RequestDate: Mon, 07 Feb 2022 00:28:05 GMTContent-Type: application/problem+jsonContent-Length: 128{"type":"https://iana.org/assignments/http-problem-types#date","title": "date field in request outside of acceptable range"}

6.6.Forward Secrecy

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

6.7.Post-Compromise Security

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

AClient only needs to retain keying material that might be used to compromisethe 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 frommessages over much longer periods. A server compromise that provided access totheOblivious Gateway Resource secret key could allow an attacker to recover theplaintext of all requests sent toward affected keys and all of the responsesthat were generated.¶

Even if server keys are compromised, an adversary cannot access messagesexchanged by the Client with theOblivious Relay Resource as messages areprotected by TLS. Use of a compromised key also requires that the ObliviousRelay Resource cooperate with the attacker or that the attacker is able tocompromise these TLS connections.¶

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

6.8.Client Clock Exposure

Including aDate field in requests reveals some information about theClientclock. This might be used to fingerprint Clients[UWT] or to identify Clientsthat are vulnerable to attacks that depend on incorrect clocks.¶

Clients can randomize the value that they provide forDate to obscure the truevalue of their clock and reduce the chance of linking requests over time.However, this increases the risk that their request is rejected as outside theacceptable window.¶

6.9.Media Type Security

Thekey configuration media type defined inSection 3.2 represents keyingmaterial. The content of this media type is not active (seeSection 4.6 of [RFC6838]), but it governs how aClient might interact with anOblivious GatewayResource. The security implications of processing it are described inSection 6.1; privacy implications are described inSection 7.¶

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

HTTP messages contain content, which can use any media type. In particular,requests are processed by an ObliviousTarget Resource, which -- as an HTTPresource -- defines how content is processed; seeSection 3.1 of [HTTP]. HTTPclients can also use resource identity and response content to determine howcontent is processed. Consequently, the security considerations ofSection 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 theObliviousGateway Resource and theTarget Resource. However, as the Oblivious GatewayResource performs generic HTTP processing, the use of forwarding cannot becompletely precluded.¶

The scheme specified in theEncapsulated Request determines the securityrequirements for any protocol that is used between the Oblivious Gateway andTarget Resources. Using HTTPS isRECOMMENDED; seeSection 6.3.¶

A Target Resource that is operated on a different server from the ObliviousGateway Resource is an ordinary HTTP resource. A Target Resource can privilegerequests that are forwarded by a given Oblivious Gateway Resource if it truststhe operator of the Oblivious Gateway Resource to only forward requests thatmeet the expectations of the Target Resource. Otherwise, the Target Resourcetreats requests from an Oblivious Gateway Resource no differently than anyother HTTP client.¶

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

An Oblivious Gateway Resource could implement policies that improve the abilityof the Target Resource to implement policy exemptions, such as only forwardingrequests toward specific Target Resources according to an allowlist; seeSection 6.3.¶

8.1.Performance Overhead

Using Oblivious HTTP adds both cryptographic overhead and latency to requestsrelative to a simple HTTP request-response exchange. Deploying relay servicesthat are on path betweenClients and servers avoids adding significantadditional delay due to network topology. A study of a similar system[ODOH-PETS] found that deploying proxies close to servers was most effectivein minimizing additional latency.¶

8.2.Resource Mappings

This protocol assumes a fixed, one-to-one mapping between theOblivious RelayResource and theOblivious Gateway Resource. This means that anyEncapsulatedRequest sent to the Oblivious Relay Resource will always be forwarded to theOblivious Gateway Resource. This constraint was imposed to simplify relayconfiguration and mitigate against the Oblivious Relay Resource being used asa generic relay for unknown Oblivious Gateway Resources. The relay will onlyforward for Oblivious Gateway Resources that it has explicitly configured andallowed.¶

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

8.3.Network Management

Oblivious HTTP might be incompatible with network interception regimes, such asthose that rely on configuringClients with trust anchors and intercepting TLSconnections. While TLS might be intercepted successfully, interceptionmiddlebox devices might not receive updates that would allow Oblivious HTTP tobe correctly identified using the media types defined in Sections9.2and9.3.¶

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

9.1.application/ohttp-keys Media Type

The "application/ohttp-keys" media type identifies akey configuration used byOblivious HTTP.¶

Type name:

application¶

Subtype name:

ohttp-keys¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

"binary"¶

Security considerations:

SeeSection 6.9¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9458¶

Applications that use this media type:

This type identifies a key configuration as used by Oblivious HTTP andapplications that use Oblivious HTTP.¶

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 Authors' 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. Thisis a binary format that is defined inSection 4.3.¶

Type name:

message¶

Subtype name:

ohttp-req¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

"binary"¶

Security considerations:

SeeSection 6.9¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9458¶

Applications that use this media type:

Oblivious HTTP and applications that use Oblivious HTTP use this media type toidentify 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 Authors' 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. Thisis a binary format that is defined inSection 4.4.¶

Type name:

message¶

Subtype name:

ohttp-res¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

"binary"¶

Security considerations:

SeeSection 6.9¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9458¶

Applications that use this media type:

Oblivious HTTP and applications that use Oblivious HTTP use this media type toidentify 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 Authors' 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 has added a new entry in the "HTTP Problem Types" 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 RFC 9458¶

9.5.Registration of "ohttp-key" Problem Type

IANA has added a new entry in the "HTTP Problem Types" 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 RFC 9458¶