draft-ietf-ohai-ohttp-00.txt   draft-ietf-ohai-ohttp-01.txt 
HTTPBIS M. Thomson Oblivious HTTP Application Intermediation M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track C.A. Wood Intended status: Standards Track C.A. Wood
Expires: 29 May 2022 Cloudflare Expires: 19 August 2022 Cloudflare
25 November 2021 15 February 2022
Oblivious HTTP Oblivious HTTP
draft-ietf-ohai-ohttp-00 draft-ietf-ohai-ohttp-01
Abstract Abstract
This document describes a system for the forwarding of encrypted HTTP This document describes a system for the forwarding of encrypted HTTP
messages. This allows a client to make multiple requests of a server messages. This allows a client to make multiple requests of a server
without the server being able to link those requests to the client or without the server being able to link those requests to the client or
to identify the requests as having come from the same client. to identify the requests as having come from the same client.
Discussion Venues About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://ietf-wg-
ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/.
Discussion of this document takes place on the Oblivious HTTP
Application Intermediation Working Group mailing list
(mailto:ohai@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ohai/.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/unicorn-wg/oblivious-http. https://github.com/ietf-wg-ohai/oblivious-http.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 August 2022.
This Internet-Draft will expire on 29 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7 4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8 4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8
4.2. Key Configuration Media Type . . . . . . . . . . . . . . 8 4.2. Key Configuration Media Type . . . . . . . . . . . . . . 9
5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 9 5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 10
5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 10 5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 11
5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12 5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12
6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Informational Responses . . . . . . . . . . . . . . . . . 14 6.1. Informational Responses . . . . . . . . . . . . . . . . . 15
6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15 7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15
7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16 7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18 8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18
8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19 8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19
8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20 8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20
8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20 8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20
8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21 8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21
8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 21 8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
8.4.1. Use of Date for Anti-Replay . . . . . . . . . . . . . 23
8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23 8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. Operational and Deployment Considerations . . . . . . . . . . 24 10. Operational and Deployment Considerations . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10.1. Performance Overhead . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Resource Mappings . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.3. Network Management . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Complete Example of a Request and Response . . . . . 27 11. Repurposing the Encapsulation Format . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Complete Example of a Request and Response . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The act of making a request using HTTP reveals information about the The act of making a request using HTTP reveals information about the
client identity to a server. Though the content of requests might client identity to a server. Though the content of requests might
reveal information, that is information under the control of the reveal information, that is information under the control of the
client. In comparison, the source address on the connection reveals client. In comparison, the source address on the connection reveals
information that a client has only limited control over. information that a client has only limited control over.
Even where an IP address is not directly attributed to an individual, Even where an IP address is not directly attributed to an individual,
skipping to change at page 5, line 6 skipping to change at page 5, line 10
* The identity of an oblivious request resource. This might include * The identity of an oblivious request resource. This might include
some information about oblivious target resources that the some information about oblivious target resources that the
oblivious request resource supports. oblivious request resource supports.
* The details of an HPKE public key that the oblivious request * The details of an HPKE public key that the oblivious request
resource accepts, including an identifier for that key and the resource accepts, including an identifier for that key and the
HPKE algorithms that are used with that key. HPKE algorithms that are used with that key.
* The identity of an oblivious proxy resource that will forward * The identity of an oblivious proxy resource that will forward
encapsulated requests and responses to the oblivious request encapsulated requests and responses to a single oblivious request
resource. resource. See Section 10.2 for more information about the mapping
between oblivious proxy and oblivious request resources.
This information allows the client to make a request of an oblivious This information allows the client to make a request of an oblivious
target resource without that resource having only a limited ability target resource without that resource having only a limited ability
to correlate that request with the client IP or other requests that to correlate that request with the client IP or other requests that
the client might make to that server. the client might make to that server.
+---------+ +----------+ +----------+ +----------+ +---------+ +----------+ +----------+ +----------+
| Client | | Proxy | | Request | | Target | | Client | | Proxy | | Request | | Target |
| | | Resource | | Resource | | Resource | | | | Resource | | Resource | | Resource |
+----+----+ +----+-----+ +----+-----+ +----+-----+ +----+----+ +----+-----+ +----+-----+ +----+-----+
skipping to change at page 7, line 19 skipping to change at page 7, line 22
these costs include: these costs include:
* DNS queries. DNS queries made to a recursive resolver reveal * DNS queries. DNS queries made to a recursive resolver reveal
information about the requester, particularly if linked to other information about the requester, particularly if linked to other
queries. queries.
* Telemetry submission. Applications that submit reports about * Telemetry submission. Applications that submit reports about
their usage to their developers might use oblivious HTTP for some their usage to their developers might use oblivious HTTP for some
types of moderately sensitive data. types of moderately sensitive data.
These are examples of requests where there is information in a
request that - if it were connected to the identity of the user -
might allow a server to learn something about that user even if the
identity of the user is pseudonymous. Other examples include the
submission of anonymous surveys, making search queries, or requesting
location-specific content (such as retrieving tiles of a map
display).
4. Key Configuration 4. Key Configuration
A client needs to acquire information about the key configuration of A client needs to acquire information about the key configuration of
the oblivious request resource in order to send encapsulated the oblivious request resource in order to send encapsulated
requests. requests.
In order to ensure that clients do not encapsulate messages that In order to ensure that clients do not encapsulate messages that
other entities can intercept, the key configuration MUST be other entities can intercept, the key configuration MUST be
authenticated and have integrity protection. authenticated and have integrity protection.
skipping to change at page 9, line 40 skipping to change at page 10, line 8
Restrictions on usage: N/A Restrictions on usage: N/A
Author: see Authors' Addresses section Author: see Authors' Addresses section
Change controller: IESG Change controller: IESG
5. HPKE Encapsulation 5. HPKE Encapsulation
HTTP message encapsulation uses HPKE for request and response HTTP message encapsulation uses HPKE for request and response
encryption. An encapsulated HTTP message includes the following encryption.
values:
1. A binary-encoded HTTP message; see [BINARY].
2. Padding of arbitrary length which MUST contain all zeroes.
The encoding of an HTTP message is as follows: An encapsulated HTTP request contains a binary-encoded HTTP message
[BINARY] and no other fields; see Figure 3.
Plaintext Message { Request {
Message Length (i), Binary HTTP Message (..),
Message (..),
Padding Length (i),
Padding (..),
} }
Figure 3: Plaintext Request Content
An Encapsulated Request is comprised of a length-prefixed key An Encapsulated Request is comprised of a length-prefixed key
identifier and a HPKE-protected request message. HPKE protection identifier and a HPKE-protected request message. HPKE protection
includes an encapsulated KEM shared secret (or enc), plus the AEAD- includes an encapsulated KEM shared secret (or enc), plus the AEAD-
protected request message. An Encapsulated Request is shown in protected request message. An Encapsulated Request is shown in
Figure 3. Section 5.1 describes the process for constructing and Figure 4. Section 5.1 describes the process for constructing and
processing an Encapsulated Request. processing an Encapsulated Request.
Encapsulated Request { Encapsulated Request {
Key Identifier (8), Key Identifier (8),
KEM Identifier (16), KEM Identifier (16),
KDF Identifier (16), KDF Identifier (16),
AEAD Identifier (16), AEAD Identifier (16),
Encapsulated KEM Shared Secret (8*Nenc), Encapsulated KEM Shared Secret (8*Nenc),
AEAD-Protected Request (..), AEAD-Protected Request (..),
} }
Figure 3: Encapsulated Request Figure 4: Encapsulated Request
The Nenc parameter corresponding to the HpkeKdfId can be found in The Nenc parameter corresponding to the HpkeKdfId can be found in
[HPKE]. Section 7.1 of [HPKE].
An encapsulated HTTP response includes a binary-encoded HTTP message
[BINARY] and no other content; see Figure 5.
Response {
Binary HTTP Message (..),
}
Figure 5: Plaintext Response Content
Responses are bound to responses and so consist only of AEAD- Responses are bound to responses and so consist only of AEAD-
protected content. Section 5.2 describes the process for protected content. Section 5.2 describes the process for
constructing and processing an Encapsulated Response. constructing and processing an Encapsulated Response.
Encapsulated Response { Encapsulated Response {
Nonce (Nk), Nonce (Nk),
AEAD-Protected Response (..), AEAD-Protected Response (..),
} }
Figure 4: Encapsulated Response Figure 6: Encapsulated Response
The size of the Nonce field in an Encapsulated Response corresponds The Nenc and Nk parameters corresponding to the HpkeKdfId can be
to the size of an AEAD key for the corresponding HPKE ciphersuite. found in [HPKE]. Nenc refers to the size of the encapsulated KEM
shared secret, in bytes; Nk refers to the size of the AEAD key for
the HPKE ciphersuite, in bits.
5.1. Encapsulation of Requests 5.1. Encapsulation of Requests
Clients encapsulate a request request using values from a key Clients encapsulate a request request using values from a key
configuration: configuration:
* the key identifier from the configuration, keyID, with the * the key identifier from the configuration, keyID, with the
corresponding KEM identified by kemID, corresponding KEM identified by kemID,
* the public key from the configuration, pkR, and * the public key from the configuration, pkR, and
* a selected combination of KDF, identified by kdfID, and AEAD, * a selected combination of KDF, identified by kdfID, and AEAD,
identified by aeadID. identified by aeadID.
The client then constructs an encapsulated request, enc_request, as The client then constructs an encapsulated request, enc_request, from
follows: a binary encoded HTTP request, request, as follows:
1. Compute an HPKE context using pkR, yielding context and 1. Compute an HPKE context using pkR and a label of "message/bhttp
encapsulation key enc. request", yielding context and encapsulation key enc.
2. Construct associated data, aad, by concatenating the values of 2. Construct associated data, aad, by concatenating the values of
keyID, kemID, kdfID, and aeadID, as one 8-bit integer and three keyID, kemID, kdfID, and aeadID, as one 8-bit integer and three
16-bit integers, respectively, each in network byte order. 16-bit integers, respectively, each in network byte order.
3. Encrypt (seal) request with aad as associated data using context, 3. Encrypt (seal) request with aad as associated data using context,
yielding ciphertext ct. yielding ciphertext ct.
4. Concatenate the values of aad, enc, and ct, yielding an 4. Concatenate the values of aad, enc, and ct, yielding an
Encapsulated Request enc_request. Encapsulated Request enc_request.
Note that enc is of fixed-length, so there is no ambiguity in parsing Note that enc is of fixed-length, so there is no ambiguity in parsing
this structure. this structure.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
enc, context = SetupBaseS(pkR, "request") enc, context = SetupBaseS(pkR, "message/bhttp request")
aad = concat(encode(1, keyID), aad = concat(encode(1, keyID),
encode(2, kemID), encode(2, kemID),
encode(2, kdfID), encode(2, kdfID),
encode(2, aeadID)) encode(2, aeadID))
ct = context.Seal(aad, request) ct = context.Seal(aad, request)
enc_request = concat(aad, enc, ct) enc_request = concat(aad, enc, ct)
Servers decrypt an Encapsulated Request by reversing this process. Servers decrypt an Encapsulated Request by reversing this process.
Given an Encapsulated Request enc_request, a server: Given an Encapsulated Request enc_request, a server:
skipping to change at page 12, line 9 skipping to change at page 12, line 28
is then able to find the HPKE private key, skR, corresponding to is then able to find the HPKE private key, skR, corresponding to
keyID. keyID.
a. If keyID does not identify a key matching the type of kemID, a. If keyID does not identify a key matching the type of kemID,
the server returns an error. the server returns an error.
b. If kdfID and aeadID identify a combination of KDF and AEAD b. If kdfID and aeadID identify a combination of KDF and AEAD
that the server is unwilling to use with skR, the server returns that the server is unwilling to use with skR, the server returns
an error. an error.
2. Compute an HPKE context using skR and the encapsulated key enc, 2. Compute an HPKE context using skR, a label of "message/bhttp
yielding context. request", and the encapsulated key enc, yielding context.
3. Construct additional associated data, aad, from keyID, kemID, 3. Construct additional associated data, aad, from keyID, kemID,
kdfID, and aeadID or as the first seven bytes of enc_request. kdfID, and aeadID or as the first seven bytes of enc_request.
4. Decrypt ct using aad as associated data, yielding request or an 4. Decrypt ct using aad as associated data, yielding request or an
error on failure. If decryption fails, the server returns an error on failure. If decryption fails, the server returns an
error. error.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request) keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request)
aad = concat(encode(1, keyID), aad = concat(encode(1, keyID),
encode(2, kemID), encode(2, kemID),
encode(2, kdfID), encode(2, kdfID),
encode(2, aeadID)) encode(2, aeadID))
context = SetupBaseR(enc, skR, "request") context = SetupBaseR(enc, skR, "message/bhttp request")
request, error = context.Open(aad, ct) request, error = context.Open(aad, ct)
5.2. Encapsulation of Responses 5.2. Encapsulation of Responses
Given an HPKE context context, a request message request, and a Given an HPKE context context, a request message request, and a
response response, servers generate an Encapsulated Response response response, servers generate an Encapsulated Response
enc_response as follows: enc_response as follows:
1. Export a secret secret from context, using the string "response" 1. Export a secret secret from context, using the string "message/
as context. The length of this secret is max(Nn, Nk), where Nn bhttp response" as context. The length of this secret is max(Nn,
and Nk are the length of AEAD key and nonce associated with Nk), where Nn and Nk are the length of AEAD key and nonce
context. associated with context.
2. Generate a random value of length max(Nn, Nk) bytes, called 2. Generate a random value of length max(Nn, Nk) bytes, called
response_nonce. response_nonce.
3. Extract a pseudorandom key prk using the Extract function 3. Extract a pseudorandom key prk using the Extract function
provided by the KDF algorithm associated with context. The ikm provided by the KDF algorithm associated with context. The ikm
input to this function is secret; the salt input is the input to this function is secret; the salt input is the
concatenation of enc (from enc_request) and response_nonce concatenation of enc (from enc_request) and response_nonce
4. Use the Expand function provided by the same KDF to extract an 4. Use the Expand function provided by the same KDF to extract an
skipping to change at page 13, line 20 skipping to change at page 13, line 38
key, nonce, empty aad, and a pt input of request, which yields key, nonce, empty aad, and a pt input of request, which yields
ct. ct.
7. Concatenate response_nonce and ct, yielding an Encapsulated 7. Concatenate response_nonce and ct, yielding an Encapsulated
Response enc_response. Note that response_nonce is of fixed- Response enc_response. Note that response_nonce is of fixed-
length, so there is no ambiguity in parsing either response_nonce length, so there is no ambiguity in parsing either response_nonce
or ct. or ct.
In pseudocode, this procedure is as follows: In pseudocode, this procedure is as follows:
secret = context.Export("response", Nk) secret = context.Export("message/bhttp response", Nk)
response_nonce = random(max(Nn, Nk)) response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce) salt = concat(enc, response_nonce)
prk = Extract(salt, secret) prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk) aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn) aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response) ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct) enc_response = concat(response_nonce, ct)
Clients decrypt an Encapsulated Request by reversing this process. Clients decrypt an Encapsulated Request by reversing this process.
That is, they first parse enc_response into response_nonce and ct. That is, they first parse enc_response into response_nonce and ct.
skipping to change at page 20, line 46 skipping to change at page 21, line 6
request resource might be sent in a single connection, traffic request resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the analysis could be used to match messages that are forwarded by the
proxy. proxy.
A proxy could, as part of its function, add delays in order to A proxy could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed. increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a This could latency to the overall time clients take to receive a
response, which might not be what some clients want. response, which might not be what some clients want.
A proxy can use padding to reduce the effectiveness of traffic A proxy can use padding to reduce the effectiveness of traffic
analysis. analysis. Padding is a capability provided by binary HTTP messages;
see Section 3.8 of [BINARY].
A proxy that forwards large volumes of exchanges can provide better A proxy that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched. privacy by providing larger sets of messages that need to be matched.
8.3. Server Responsibilities 8.3. Server Responsibilities
A server that operates both oblivious request and oblivious target A server that operates both oblivious request and oblivious target
resources is responsible for removing request encapsulation, resources is responsible for removing request encapsulation,
generating a response the encapsulated request, and encapsulating the generating a response the encapsulated request, and encapsulating the
response. response.
skipping to change at page 21, line 35 skipping to change at page 21, line 42
assigned new key identifiers. If an oblivious request resource assigned new key identifiers. If an oblivious request resource
receives a request that contains a key identifier that it does not receives a request that contains a key identifier that it does not
understand or that corresponds to a key that has been replaced, the understand or that corresponds to a key that has been replaced, the
server can respond with an HTTP 422 (Unprocessable Content) status server can respond with an HTTP 422 (Unprocessable Content) status
code. code.
A server can also use a 422 status code if the server has a key that 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 corresponds to the key identifier, but the encapsulated request
cannot be successfully decrypted using the key. cannot be successfully decrypted using the key.
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "message/bhttp request" label.
Designers of protocols that reuse this encapsulation format,
especially new versions of this protocol, can ensure key diversity by
choosing a different label in their use of HPKE. The "message/bhttp
response" label was chosen for symmetry only as it provides key
diversity only within the HPKE context created using the "message/
bhttp request" label; see Section 11.
A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect clients
or resources; see Section 8.4.
8.4. Replay Attacks 8.4. Replay Attacks
Encapsulated requests can be copied and replayed by the oblivious Encapsulated requests can be copied and replayed by the oblivious
proxy resource. The design of oblivious HTTP does not assume that proxy resource. The design of oblivious HTTP does not assume that
the oblivious proxy resource will not replay requests. In addition, the oblivious proxy resource will not replay requests. In addition,
if a client sends an encapsulated request in TLS early data (see if a client sends an encapsulated request in TLS early data (see
Section 8 of [TLS] and [RFC8470]), a network-based adversary might be 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 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 of a replay attack and the mitigations that might be employed are
similar to TLS early data. similar to TLS early data.
skipping to change at page 22, line 16 skipping to change at page 22, line 31
to retry a failed request unless it receives a positive signal to retry a failed request unless it receives a positive signal
indicating that the request was not processed or forwarded. The indicating that the request was not processed or forwarded. The
HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [RFC7540]), the HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [RFC7540]), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]), HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]),
or a GOAWAY frame with a low enough identifier (in either protocol or a GOAWAY frame with a low enough identifier (in either protocol
version) are all sufficient signals that no processing occurred. version) are all sufficient signals that no processing occurred.
Connection failures or interruptions are not sufficient signals that Connection failures or interruptions are not sufficient signals that
no processing occurred. no processing occurred.
The anti-replay mechanisms described in Section 8 of [TLS] are The anti-replay mechanisms described in Section 8 of [TLS] are
generally applicable to oblivious HTTP requests. Servers can use the generally applicable to oblivious HTTP requests. The encapsulated
encapsulated keying material as a unique key for identifying keying material (or enc) can be used in place of a nonce to uniquely
potential replays. This depends on clients generating a new HPKE identify a request. This value is a high-entropy value that is
context for every request. 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 The mechanism used in TLS for managing differences in client and
server clocks cannot be used as it depends on being able to observe server clocks cannot be used as it depends on being able to observe
previous interactions. Oblivious HTTP explicitly prevents such previous interactions. Oblivious HTTP explicitly prevents such
linkability. Applications can still include an explicit indication linkability.
of time to limit the span of time over which a server might need to
track accepted requests. Clock information could be used for client
identification, so reduction in precision or obfuscation might be
necessary.
The considerations in [RFC8470] as they relate to managing the risk The considerations in [RFC8470] as they relate to managing the risk
of replay also apply, though there is no option to delay the of replay also apply, though there is no option to delay the
processing of a request. processing of a request.
Limiting requests to those with safe methods might not be Limiting requests to those with safe methods might not be
satisfactory for some applications, particularly those that involve satisfactory for some applications, particularly those that involve
the submission of data to a server. The use of idempotent methods the submission of data to a server. The use of idempotent methods
might be of some use in managing replay risk, though it is important might be of some use in managing replay risk, though it is important
to recognize that different idempotent requests can be combined to be to recognize that different idempotent requests can be combined to be
not idempotent. not idempotent.
Idempotent actions with a narrow scope based on the value of a Even without replay prevention, the server-chosen response_nonce
protected nonce could enable data submission with limited replay field ensures that responses have unique AEAD keys and nonces even
exposure. A nonce might be added as an explicit part of a request, when requests are replayed.
or, if the oblivious request and target resources are co-located, the
encapsulated keying material can be used to produce a nonce.
The server-chosen response_nonce field ensures that responses have 8.4.1. Use of Date for Anti-Replay
unique AEAD keys and nonces even when requests are replayed.
Clients SHOULD include a Date header field in encapsulated requests.
Though HTTP requests often do not include a Date header field, the
value of this field might be used by a server to limit the amount of
requests it needs to track when preventing replays.
A server can maintain state for requests for a small window of time
over which it wishes to accept requests. The server then rejects
requests if the request is the same as one that was previously
answered within that time window. Servers can reject requests
outside of this window and signal that clients might retry with a
different Date header field; see Section 4 of [REQUEST-DATE].
Servers can identify duplicate requests using the encapsulation (enc)
value.
Servers SHOULD allow for the time it takes requests to arrive from
the client, with a time window that is large enough to allow for
differences in the clock of clients and servers. How large a time
window is needed could depend on the population of clients that the
server needs to serve.
Servers MUST NOT treat the time window as secret information. An
attacker can actively probe the server with specially crafted request
timestamps to determine the time window over which the server will
accept responses.
[REQUEST-DATE] contains further considerations for the use of the
Date request header field. This includes the way in which clients
might correct for clock skew and the privacy considerations arising
from that usage. Servers that reject requests on the basis of the
Date request header field SHOULD implement the feedback mechanism in
Section 4 of [REQUEST-DATE] to support clock correction by clients.
8.5. Post-Compromise Security 8.5. Post-Compromise Security
This design does not provide post-compromise security for responses. This design does not provide post-compromise security for responses.
A client only needs to retain keying material that might be used A client only needs to retain keying material that might be used
compromise the confidentiality and integrity of a response until that compromise the confidentiality and integrity of a response until that
response is consumed, so there is negligible risk associated with a response is consumed, so there is negligible risk associated with a
client compromise. client compromise.
A server retains a secret key that might be used to remove protection A server retains a secret key that might be used to remove protection
from messages over much longer periods. A server compromise that from messages over much longer periods. A server compromise that
provided access to the oblivious request resource secret key could provided access to the oblivious request resource secret key could
allow an attacker to recover the plaintext of all requests sent allow an attacker to recover the plaintext of all requests sent
toward affected keys and all of the responses that were generated. toward affected keys and all of the responses that were generated.
skipping to change at page 23, line 46 skipping to change at page 24, line 38
that share an identifier. An oblivious proxy can link requests using that share an identifier. An oblivious proxy can link requests using
the public key corresponding to KeyConfig.key_id. the public key corresponding to KeyConfig.key_id.
Request resources are capable of linking requests depending on how Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients. KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to Specifically, servers can maliciously construct key configurations to
track individual clients. A specific method for a client to acquire track individual clients. A specific method for a client to acquire
key configurations is not included in this specification. Clients key configurations is not included in this specification. Clients
need to consider these tracking vectors when choosing a discovery need to consider these tracking vectors when choosing a discovery
method. Applications using this design should provide accommodations method. Applications using this design should provide accommodations
to mitigate tracking using key configurations. to mitigate tracking using key configurations. [CONSISTENCY]
provides an analysis of the options for ensuring the key
configurations are consistent between different clients.
10. Operational and Deployment Considerations 10. Operational and Deployment Considerations
This section discusses various operational and deployment
considerations.
10.1. Performance Overhead
Using Oblivious HTTP adds both cryptographic and latency to requests Using Oblivious HTTP adds both cryptographic and latency to requests
relative to a simple HTTP request-response exchange. Deploying proxy relative to a simple HTTP request-response exchange. Deploying proxy
services that are on path between clients and servers avoids adding services that are on path between clients and servers avoids adding
significant additional delay due to network topology. A study of a significant additional delay due to network topology. A study of a
similar system [ODoH] found that deploying proxies close to servers similar system [ODoH] found that deploying proxies close to servers
was most effective in minimizing additional latency. was most effective in minimizing additional latency.
10.2. Resource Mappings
This protocol assumes a fixed, one-to-one mapping between the
Oblivious Proxy Resource and the Oblivious Request Resource. This
means that any encapsulated request sent to the Oblivious Proxy
Resource will always be forwarded to the Oblivious Request Resource.
This constraint was imposed to simplify proxy configuration and
mitigate against the Oblivious Proxy Resource being used as a generic
proxy for unknown Oblivious Request Resources. The proxy will only
forward for Oblivious Request Resources that it has explicitly
configured and allowed.
It is possible for a server to be configured with multiple Oblivious
Proxy Resources, each for a different Oblivious Request Resource as
needed.
10.3. Network Management
Oblivious HTTP might be incompatible with network interception Oblivious HTTP might be incompatible with network interception
regimes, such as those that rely on configuring clients with trust regimes, such as those that rely on configuring clients with trust
anchors and intercepting TLS connections. While TLS might be anchors and intercepting TLS connections. While TLS might be
intercepted successfully, interception middleboxes devices might not intercepted successfully, interception middleboxes devices might not
receive updates that would allow Oblivious HTTP to be correctly receive updates that would allow Oblivious HTTP to be correctly
identified using the media types defined in Section 7. identified using the media types defined in Section 7.
Oblivious HTTP has a simple key management design that is not Oblivious HTTP has a simple key management design that is not
trivially altered to enable interception by intermediaries. Clients trivially altered to enable interception by intermediaries. Clients
that are configured to enable interception might choose to disable that are configured to enable interception might choose to disable
Oblivious HTTP in order to ensure that content is accessible to Oblivious HTTP in order to ensure that content is accessible to
middleboxes. middleboxes.
11. IANA Considerations 11. Repurposing the Encapsulation Format
The encapsulated payload of an OHTTP request and response is a binary
HTTP message [BINARY]. Client and target agree on this encapsulated
payload type by specifying the media type "message/bhttp" in the HPKE
encapsulation info string and HPKE export context string for request
and response encapsulation, respectively.
Future specifications may repurpose the encapsulation mechanism
described in Section 5, provided that the content type of the
encapsulated payload is appropriately reflected in the HPKE info and
context strings. For example, if a future specification were to use
the encapsulation mechanism in this specification for DNS messages,
identified by the "application/dns-message" media type, then the HPKE
info string SHOULD be "application/dns-message request" for request
encapsulation, and the HPKE export context string should be
"application/dns-message response" for response encapsulation.
12. IANA Considerations
Please update the "Media Types" registry at Please update the "Media Types" registry at
https://www.iana.org/assignments/media-types https://www.iana.org/assignments/media-types
(https://www.iana.org/assignments/media-types) with the registration (https://www.iana.org/assignments/media-types) with the registration
information in Section 7 for the media types "message/ohttp-req", information in Section 7 for the media types "message/ohttp-req",
"message/ohttp-res", and "application/ohttp-keys". "message/ohttp-res", and "application/ohttp-keys".
12. References 13. References
12.1. Normative References 13.1. Normative References
[BINARY] Thomson, M., "Binary Representation of HTTP Messages", [BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Work in Progress, Internet-Draft, draft-thomson-http- Messages", Work in Progress, Internet-Draft, draft-ietf-
binary-message-latest, 26 November 2021, httpbis-binary-message-01, 3 February 2022,
<https://datatracker.ietf.org/doc/html/draft-thomson-http- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
binary-message-latest>. binary-message-01>.
[HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
"Hybrid Public Key Encryption", Work in Progress, "Hybrid Public Key Encryption", Work in Progress,
Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
hpke-12>. hpke-12>.
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021, httpbis-semantics-19, 12 September 2021,
skipping to change at page 25, line 23 skipping to change at page 27, line 8
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/rfc/rfc9000>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[REQUEST-DATE]
Thomson, M., "Using The Date Header Field In HTTP
Requests", Work in Progress, Internet-Draft, draft-
thomson-httpapi-date-requests-00, 8 February 2022,
<https://datatracker.ietf.org/doc/html/draft-thomson-
httpapi-date-requests-00>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
skipping to change at page 25, line 45 skipping to change at page 27, line 37
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>. 2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
12.2. Informative References 13.2. Informative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>. April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-wood-key-consistency-01, 19 August
2021, <https://datatracker.ietf.org/doc/html/draft-wood-
key-consistency-01>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[Dingledine2004] [Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", August 2004, Second-Generation Onion Router", August 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor- <https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>. design.html>.
skipping to change at page 26, line 29 skipping to change at page 28, line 29
[ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T., [ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T.,
Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A. Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A.
Wood, "Oblivious DNS over HTTPS (ODoH): A Practical Wood, "Oblivious DNS over HTTPS (ODoH): A Practical
Privacy Enhancement to DNS", 7 January 2021, Privacy Enhancement to DNS", 7 January 2021,
<https://www.petsymposium.org/2021/files/papers/issue4/ <https://www.petsymposium.org/2021/files/papers/issue4/
popets-2021-0085.pdf>. popets-2021-0085.pdf>.
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
Wood, "Oblivious DNS Over HTTPS", Work in Progress, Wood, "Oblivious DNS Over HTTPS", Work in Progress,
Internet-Draft, draft-pauly-dprive-oblivious-doh-07, 2 Internet-Draft, draft-pauly-dprive-oblivious-doh-10, 31
September 2021, <https://datatracker.ietf.org/doc/html/ January 2022, <https://datatracker.ietf.org/doc/html/
draft-pauly-dprive-oblivious-doh-07>. draft-pauly-dprive-oblivious-doh-10>.
[OHTTP-ANALYSIS] [OHTTP-ANALYSIS]
Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August
2021, <https://github.com/cloudflare/ohttp-analysis>. 2021, <https://github.com/cloudflare/ohttp-analysis>.
[PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, [PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
and Scalable Computation of Aggregate Statistics", 14 and Scalable Computation of Aggregate Statistics", 14
March 2017, <https://crypto.stanford.edu/prio/paper.pdf>. March 2017, <https://crypto.stanford.edu/prio/paper.pdf>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
skipping to change at page 27, line 21 skipping to change at page 29, line 21
A single request and response exchange is shown here. Binary values A single request and response exchange is shown here. Binary values
(key configuration, secret keys, the content of messages, and (key configuration, secret keys, the content of messages, and
intermediate values) are shown in hexadecimal. The request and intermediate values) are shown in hexadecimal. The request and
response here are absolutely minimal; the purpose of this example is response here are absolutely minimal; the purpose of this example is
to show the cryptographic operations. to show the cryptographic operations.
The oblivious request resource generates a key pair. In this example The oblivious request resource generates a key pair. In this example
the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519
key pair [X25519]. The X25519 secret key is: key pair [X25519]. The X25519 secret key is:
cb14d538a70d8a74d47fb7e3ac5052a086da127c678d3585dcad72f98e3bff83 b8f3cea0da634e6b8271f5b8f931d266decdd04c8e09b80cb9878ea90086ed4a
The oblivious request resource constructs a key configuration that The oblivious request resource constructs a key configuration that
includes the corresponding public key as follows: includes the corresponding public key as follows:
01002012a45279412ea6ef11e9f839bb5a422fc1262b5c023d787e4e636e70ae 01002076eae6d5a6c1549a3343d31c0b9b9582470c72ca11607d47f005f8c16b
d3d56e00080001000100010003 e3304a00080001000100010003
This key configuration is somehow obtained by the client. Then when This key configuration is somehow obtained by the client. Then when
a client wishes to send an HTTP request of a GET request to a client wishes to send an HTTP request of a GET request to
https://example.com, it constructs the following binary HTTP message: https://example.com, it constructs the following binary HTTP message:
00034745540568747470730b6578616d706c652e636f6d012f 00034745540568747470730b6578616d706c652e636f6d012f
The client then reads the oblivious request resource key The client then reads the oblivious request resource key
configuration and selects a mutually supported KDF and AEAD. In this configuration and selects a mutually supported KDF and AEAD. In this
example, the client selects HKDF-SHA256 and AES-128-GCM. The client example, the client selects HKDF-SHA256 and AES-128-GCM. The client
then generates an HPKE context that uses the server public key. This then generates an HPKE context that uses the server public key. This
results in the following encapsulated key: context is constructed from the following ephemeral public key:
cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 25845c6ed6802abfd09628b5c677842b10dd53a3aad5775aa3c20cbae1c0cb65
The corresponding private key is: The corresponding private key is:
c20afd33a2f2663faf023acf5d56fc08fddd38aada29b21b3b96e16f4326ccf7 88894d1fb4e76e215d9d9c87c44d9e0a6053c1c84c836a4106ea547344504658
Applying the Seal operation from the HPKE context produces an Applying the Seal operation from the HPKE context produces an
encrypted message, allowing the client to construct the following encrypted message, allowing the client to construct the following
encapsulated request: encapsulated request:
01002000010001cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674 010020000100012485c2eee03135aac82e572d51639b2e141102c431d544e346
db72730623ca3b68b9e75a0576745da12c4fa5053b7ec06d7f625197564a6087 0a0784a908b41b676943ae0b3ed8eff581ee8be5f47303a314de092e2e27e3f0
ec299f8d6fffa2a8addfc1c0f64b4b05 2a03b9357de1d414cadacabaa1621cf9
The client then sends this to the oblivious proxy resource in a POST The client then sends this to the oblivious proxy resource in a POST
request, which might look like the following HTTP/1.1 request: request, which might look like the following HTTP/1.1 request:
POST /request.example.net/proxy HTTP/1.1 POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org Host: proxy.example.org
Content-Type: message/ohttp-req Content-Type: message/ohttp-req
Content-Length: 78 Content-Length: 78
<content is the encapsulated request above> <content is the encapsulated request above>
skipping to change at page 28, line 42 skipping to change at page 30, line 42
server, the oblivious request resource does not need to initiate an server, the oblivious request resource does not need to initiate an
HTTP request to the oblivious target resource. The request can be HTTP request to the oblivious target resource. The request can be
served directly by the oblivious target resource, which generates a served directly by the oblivious target resource, which generates a
minimal response (consisting of just a 200 status code) as follows: minimal response (consisting of just a 200 status code) as follows:
0140c8 0140c8
The response is constructed by extracting a secret from the HPKE The response is constructed by extracting a secret from the HPKE
context: context:
9c0b96b577b9fc7a5beef536e0ff3a64 50030a0eacaa9c020e60390c573c4f80
The key derivation for the encapsulated response uses both the The key derivation for the encapsulated response uses both the
encapsulated KEM key from the request and a randomly selected nonce. encapsulated KEM key from the request and a randomly selected nonce.
This produces a salt of: This produces a salt of:
cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 2485c2eee03135aac82e572d51639b2e141102c431d544e3460a0784a908b41b
061d62d5df5832c6c9fa4617ceb848a7 e29f9834fd61ffa27f494dfea94d9ed5
The salt and secret are both passed to the Extract function of the The salt and secret are both passed to the Extract function of the
selected KDF (HKDF-SHA256) to produce a pseudorandom key of: selected KDF (HKDF-SHA256) to produce a pseudorandom key of:
a0ab55d3b1811694943bb72c386f59bd030e1278692a3db2f30d8aac2f89a5fc 4fd8939221446411c785dc9dc51a196df43646a7791919248d0c7624c9410e5b
The pseudorandom key is used with the Expand function of the KDF and 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 an info field of "key" to produce a 16-byte key for the selected AEAD
(AES-128-GCM): (AES-128-GCM):
1dae9d7fe263d23e51a768bcaf310aa5 a0cd40e2e68cd500bfd14275b290f337
With the same KDF and pseudorandom key, an info field of "nonce" is With the same KDF and pseudorandom key, an info field of "nonce" is
used to generate a 12-byte nonce: used to generate a 12-byte nonce:
e520beec147740e4f8a3b553 86883bbe97a380ec2fa656f7
The AEAD Seal function is then used to encrypt the response, which is The AEAD Seal function is then used to encrypt the response, which is
added to the randomized nonce value to produce the encapsulated added to the randomized nonce value to produce the encapsulated
response: response:
061d62d5df5832c6c9fa4617ceb848a7a6f694da45accc3c32ad576cb204f7cd e29f9834fd61ffa27f494dfea94d9ed543d89abe34977e7d6d5e1d8051e7b3ba
3bf23e 4ff234
The oblivious request resource then constructs a response: The oblivious request resource then constructs a response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store Cache-Control: private, no-store
Content-Type: message/ohttp-res Content-Type: message/ohttp-res
Content-Length: 38 Content-Length: 38
<content is the encapsulated response> <content is the encapsulated response>
 End of changes. 61 change blocks. 
104 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/