idnits 2.17.00 (12 Aug 2021) /tmp/idnits40100/draft-thomson-ohai-ohttp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Npk' is mentioned on line 334, but not defined == Outdated reference: A later version (-01) exists of draft-thomson-http-binary-message-00 == Outdated reference: draft-irtf-cfrg-hpke has been published as RFC 9180 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-07 -- Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALT-SVC'. Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBIS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track C.A. Wood 5 Expires: 28 April 2022 Cloudflare 6 25 October 2021 8 Oblivious HTTP 9 draft-thomson-ohai-ohttp-00 11 Abstract 13 This document describes a system for the forwarding of encrypted HTTP 14 messages. This allows a client to make multiple requests of a server 15 without the server being able to link those requests to the client or 16 to identify the requests as having come from the same client. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Source for this draft and an issue tracker can be found at 23 https://github.com/unicorn-wg/oblivious-http. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 28 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8 64 4.2. Key Configuration Media Type . . . . . . . . . . . . . . 8 65 5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 10 67 5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12 68 6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. Informational Responses . . . . . . . . . . . . . . . . . 14 70 6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15 73 7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18 76 8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19 77 8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20 78 8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20 79 8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21 80 8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 21 81 8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23 82 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 83 10. Operational and Deployment Considerations . . . . . . . . . . 24 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 87 12.2. Informative References . . . . . . . . . . . . . . . . . 25 88 Appendix A. Complete Example of a Request and Response . . . . . 27 89 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction 94 The act of making a request using HTTP reveals information about the 95 client identity to a server. Though the content of requests might 96 reveal information, that is information under the control of the 97 client. In comparison, the source address on the connection reveals 98 information that a client has only limited control over. 100 Even where an IP address is not directly attributed to an individual, 101 the use of an address over time can be used to correlate requests. 102 Servers are able to use this information to assemble profiles of 103 client behavior, from which they can make inferences about the people 104 involved. The use of persistent connections to make multiple 105 requests improves performance, but provides servers with additional 106 certainty about the identity of clients in a similar fashion. 108 Use of an HTTP proxy can provide a degree of protection against 109 servers correlating requests. Systems like virtual private networks 110 or the Tor network [Dingledine2004], provide other options for 111 clients. 113 Though the overhead imposed by these methods varies, the cost for 114 each request is significant. Preventing request linkability requires 115 that each request use a completely new TLS connection to the server. 116 At a minimum, this requires an additional round trip to the server in 117 addition to that required by the request. In addition to having high 118 latency, there are significant secondary costs, both in terms of the 119 number of additional bytes exchanged and the CPU cost of 120 cryptographic computations. 122 This document describes a method of encapsulation for binary HTTP 123 messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). 124 This protects the content of both requests and responses and enables 125 a deployment architecture that can separate the identity of a 126 requester from the request. 128 Though this scheme requires that servers and proxies explicitly 129 support it, this design represents a performance improvement over 130 options that perform just one request in each connection. With 131 limited trust placed in the proxy (see Section 8), clients are 132 assured that requests are not uniquely attributed to them or linked 133 to other requests. 135 2. Conventions and Definitions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 Encapsulated Request: An HTTP request that is encapsulated in an 144 HPKE-encrypted message; see Section 5.1. 146 Encapsulated Response: An HTTP response that is encapsulated in an 147 HPKE-encrypted message; see Section 5.2. 149 Oblivious Proxy Resource: An intermediary that forwards requests and 150 responses between clients and a single oblivious request resource. 152 Oblivious Request Resource: A resource that can receive an 153 encapsulated request, extract the contents of that request, 154 forward it to an oblivious target resource, receive a response, 155 encapsulate that response, then return that response. 157 Oblivious Target Resource: The resource that is the target of an 158 encapsulated request. This resource logically handles only 159 regular HTTP requests and responses and so might be ignorant of 160 the use of oblivious HTTP to reach it. 162 This draft includes pseudocode that uses the functions and 163 conventions defined in [HPKE]. 165 Encoding an integer to a sequence of bytes in network byte order is 166 described using the function encode(n, v), where n is the number of 167 bytes and v is the integer value. The function len() returns the 168 length of a sequence of bytes. 170 Formats are described using notation from Section 1.3 of [QUIC]. 172 3. Overview 174 A client learns the following: 176 * The identity of an oblivious request resource. This might include 177 some information about oblivious target resources that the 178 oblivious request resource supports. 180 * The details of an HPKE public key that the oblivious request 181 resource accepts, including an identifier for that key and the 182 HPKE algorithms that are used with that key. 184 * The identity of an oblivious proxy resource that will forward 185 encapsulated requests and responses to the oblivious request 186 resource. 188 This information allows the client to make a request of an oblivious 189 target resource without that resource having only a limited ability 190 to correlate that request with the client IP or other requests that 191 the client might make to that server. 193 +---------+ +----------+ +----------+ +----------+ 194 | Client | | Proxy | | Request | | Target | 195 | | | Resource | | Resource | | Resource | 196 +----+----+ +----+-----+ +----+-----+ +----+-----+ 197 | | | | 198 | Encapsulated | | | 199 | Request | | | 200 +---------------->| Encapsulated | | 201 | | Request | | 202 | +----------------->| Request | 203 | | +-------------->| 204 | | | | 205 | | | Response | 206 | | Encapsulated |<--------------+ 207 | | Response | | 208 | Encapsulated |<-----------------+ | 209 | Response | | | 210 |<----------------+ | | 211 | | | | 213 Figure 1: Overview of Oblivious HTTP 215 In order to make a request to an oblivious target resource, the 216 following steps occur, as shown in Figure 1: 218 1. The client constructs an HTTP request for an oblivious target 219 resource. 221 2. The client encodes the HTTP request in a binary HTTP message and 222 then encapsulates that message using HPKE and the process from 223 Section 5.1. 225 3. The client sends a POST request to the oblivious proxy resource 226 with the encapsulated request as the content of that message. 228 4. The oblivious proxy resource forwards this request to the 229 oblivious request resource. 231 5. The oblivious request resource receives this request and removes 232 the HPKE protection to obtain an HTTP request. 234 6. The oblivious request resource makes an HTTP request that 235 includes the target URI, method, fields, and content of the 236 request it acquires. 238 7. The oblivious target resource answers this HTTP request with an 239 HTTP response. 241 8. The oblivious request resource encapsulates the HTTP response 242 following the process in Section 5.2 and sends this in response 243 to the request from the oblivious proxy resource. 245 9. The oblivious proxy resource forwards this response to the 246 client. 248 10. The client removes the encapsulation to obtain the response to 249 the original request. 251 3.1. Applicability 253 Oblivious HTTP has limited applicability. Many uses of HTTP benefit 254 from being able to carry state between requests, such as with cookies 255 ([RFC6265]), authentication (Section 11 of [HTTP]), or even 256 alternative services ([RFC7838]). Oblivious HTTP seeks to prevent 257 this sort of linkage, which requires that applications not carry 258 state between requests. 260 Oblivious HTTP is primarily useful where privacy risks associated 261 with possible stateful treatment of requests are sufficiently 262 negative that the cost of deploying this protocol can be justified. 263 Oblivious HTTP is simpler and less costly than more robust systems, 264 like Prio ([PRIO]) or Tor ([Dingledine2004]), which can provide 265 stronger guarantees at higher operational costs. 267 Oblivious HTTP is more costly than a direct connection to a server. 268 Some costs, like those involved with connection setup, can be 269 amortized, but there are several ways in which oblivious HTTP is more 270 expensive than a direct request: 272 * Each oblivious request requires at least two regular HTTP 273 requests, which adds latency. 275 * Each request is expanded in size with additional HTTP fields, 276 encryption-related metadata, and AEAD expansion. 278 * Deriving cryptographic keys and applying them for request and 279 response protection takes non-negligible computational resources. 281 Examples of where preventing the linking of requests might justify 282 these costs include: 284 * DNS queries. DNS queries made to a recursive resolver reveal 285 information about the requester, particularly if linked to other 286 queries. 288 * Telemetry submission. Applications that submit reports about 289 their usage to their developers might use oblivious HTTP for some 290 types of moderately sensitive data. 292 4. Key Configuration 294 A client needs to acquire information about the key configuration of 295 the oblivious request resource in order to send encapsulated 296 requests. 298 In order to ensure that clients do not encapsulate messages that 299 other entities can intercept, the key configuration MUST be 300 authenticated and have integrity protection. 302 This document describes the "application/ohttp-keys" media type; see 303 Section 4.2. This media type might be used, for example with HTTPS, 304 as part of a system for configuring or discovering key 305 configurations. Note however that such a system needs to consider 306 the potential for key configuration to be used to compromise client 307 privacy; see Section 9. 309 Specifying a format for expressing the information a client needs to 310 construct an encapsulated request ensures that different client 311 implementations can be configured in the same way. This also enables 312 advertising key configurations in a consistent format. 314 A client might have multiple key configurations to select from when 315 encapsulating a request. Clients are responsible for selecting a 316 preferred key configuration from those it supports. Clients need to 317 consider both the key encapsulation method (KEM) and the combinations 318 of key derivation function (KDF) and authenticated encryption with 319 associated data (AEAD) in this decision. 321 Evolution of the key configuration format is supported through the 322 definition of new formats that are identified by new media types. 324 4.1. Key Configuration Encoding 326 A single key configuration consists of a key identifier, a public 327 key, an identifier for the KEM that the public key uses, and a set 328 HPKE symmetric algorithms. Each symmetric algorithm consists of an 329 identifier for a KDF and an identifier for an AEAD. 331 Figure 2 shows a single key configuration, KeyConfig, that is 332 expressed using the TLS syntax; see Section 3 of [TLS]. 334 opaque HpkePublicKey[Npk]; 335 uint16 HpkeKemId; 336 uint16 HpkeKdfId; 337 uint16 HpkeAeadId; 339 struct { 340 HpkeKdfId kdf_id; 341 HpkeAeadId aead_id; 342 } HpkeSymmetricAlgorithms; 344 struct { 345 uint8 key_id; 346 HpkeKemId kem_id; 347 HpkePublicKey public_key; 348 HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>; 349 } KeyConfig; 351 Figure 2: A Single Key Configuration 353 The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, 354 and AEAD respectively. The definitions for these identifiers and the 355 semantics of the algorithms they identify can be found in [HPKE]. 356 The Npk parameter corresponding to the HpkeKdfId can be found in 357 [HPKE]. 359 4.2. Key Configuration Media Type 361 The "application/ohttp-keys" format is a media type that identifies a 362 serialized collection of key configurations. The content of this 363 media type comprises one or more key configuration encodings (see 364 Section 4.1) that are concatenated. 366 Type name: application 368 Subtype name: ohttp-keys 370 Required parameters: N/A 371 Optional parameters: None 373 Encoding considerations: only "8bit" or "binary" is permitted 375 Security considerations: see Section 8 377 Interoperability considerations: N/A 379 Published specification: this specification 381 Applications that use this media type: N/A 383 Fragment identifier considerations: N/A 385 Additional information: Magic number(s): N/A 387 Deprecated alias names for this type: N/A 389 File extension(s): N/A 391 Macintosh file type code(s): N/A 393 Person and email address to contact for further information: see Aut 394 hors' Addresses section 396 Intended usage: COMMON 398 Restrictions on usage: N/A 400 Author: see Authors' Addresses section 402 Change controller: IESG 404 5. HPKE Encapsulation 406 HTTP message encapsulation uses HPKE for request and response 407 encryption. An encapsulated HTTP message includes the following 408 values: 410 1. A binary-encoded HTTP message; see [BINARY]. 412 2. Padding of arbitrary length which MUST contain all zeroes. 414 The encoding of an HTTP message is as follows: 416 Plaintext Message { 417 Message Length (i), 418 Message (..), 419 Padding Length (i), 420 Padding (..), 421 } 423 An Encapsulated Request is comprised of a length-prefixed key 424 identifier and a HPKE-protected request message. HPKE protection 425 includes an encapsulated KEM shared secret (or enc), plus the AEAD- 426 protected request message. An Encapsulated Request is shown in 427 Figure 3. Section 5.1 describes the process for constructing and 428 processing an Encapsulated Request. 430 Encapsulated Request { 431 Key Identifier (8), 432 KEM Identifier (16), 433 KDF Identifier (16), 434 AEAD Identifier (16), 435 Encapsulated KEM Shared Secret (8*Nenc), 436 AEAD-Protected Request (..), 437 } 439 Figure 3: Encapsulated Request 441 The Nenc parameter corresponding to the HpkeKdfId can be found in 442 [HPKE]. 444 Responses are bound to responses and so consist only of AEAD- 445 protected content. Section 5.2 describes the process for 446 constructing and processing an Encapsulated Response. 448 Encapsulated Response { 449 Nonce (Nk), 450 AEAD-Protected Response (..), 451 } 453 Figure 4: Encapsulated Response 455 The size of the Nonce field in an Encapsulated Response corresponds 456 to the size of an AEAD key for the corresponding HPKE ciphersuite. 458 5.1. Encapsulation of Requests 460 Clients encapsulate a request request using values from a key 461 configuration: 463 * the key identifier from the configuration, keyID, with the 464 corresponding KEM identified by kemID, 466 * the public key from the configuration, pkR, and 468 * a selected combination of KDF, identified by kdfID, and AEAD, 469 identified by aeadID. 471 The client then constructs an encapsulated request, enc_request, as 472 follows: 474 1. Compute an HPKE context using pkR, yielding context and 475 encapsulation key enc. 477 2. Construct associated data, aad, by concatenating the values of 478 keyID, kemID, kdfID, and aeadID, as one 8-bit integer and three 479 16-bit integers, respectively, each in network byte order. 481 3. Encrypt (seal) request with aad as associated data using context, 482 yielding ciphertext ct. 484 4. Concatenate the values of aad, enc, and ct, yielding an 485 Encapsulated Request enc_request. 487 Note that enc is of fixed-length, so there is no ambiguity in parsing 488 this structure. 490 In pseudocode, this procedure is as follows: 492 enc, context = SetupBaseS(pkR, "request") 493 aad = concat(encode(1, keyID), 494 encode(2, kemID), 495 encode(2, kdfID), 496 encode(2, aeadID)) 497 ct = context.Seal(aad, request) 498 enc_request = concat(aad, enc, ct) 500 Servers decrypt an Encapsulated Request by reversing this process. 501 Given an Encapsulated Request enc_request, a server: 503 1. Parses enc_request into keyID, kemID, kdfID, aeadID, enc, and ct 504 (indicated using the function parse() in pseudocode). The server 505 is then able to find the HPKE private key, skR, corresponding to 506 keyID. 508 a. If keyID does not identify a key matching the type of kemID, 509 the server returns an error. 511 b. If kdfID and aeadID identify a combination of KDF and AEAD 512 that the server is unwilling to use with skR, the server returns 513 an error. 515 2. Compute an HPKE context using skR and the encapsulated key enc, 516 yielding context. 518 3. Construct additional associated data, aad, from keyID, kdfID, and 519 aeadID or as the first five bytes of enc_request. 521 4. Decrypt ct using aad as associated data, yielding request or an 522 error on failure. If decryption fails, the server returns an 523 error. 525 In pseudocode, this procedure is as follows: 527 keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request) 528 aad = concat(encode(1, keyID), 529 encode(2, kemID), 530 encode(2, kdfID), 531 encode(2, aeadID)) 532 context = SetupBaseR(enc, skR, "request") 533 request, error = context.Open(aad, ct) 535 5.2. Encapsulation of Responses 537 Given an HPKE context context, a request message request, and a 538 response response, servers generate an Encapsulated Response 539 enc_response as follows: 541 1. Export a secret secret from context, using the string "response" 542 as context. The length of this secret is max(Nn, Nk), where Nn 543 and Nk are the length of AEAD key and nonce associated with 544 context. 546 2. Generate a random value of length max(Nn, Nk) bytes, called 547 response_nonce. 549 3. Extract a pseudorandom key prk using the Extract function 550 provided by the KDF algorithm associated with context. The ikm 551 input to this function is secret; the salt input is the 552 concatenation of enc (from enc_request) and response_nonce 554 4. Use the Expand function provided by the same KDF to extract an 555 AEAD key key, of length Nk - the length of the keys used by the 556 AEAD associated with context. Generating key uses a label of 557 "key". 559 5. Use the same Expand function to extract a nonce nonce of length 560 Nn - the length of the nonce used by the AEAD. Generating nonce 561 uses a label of "nonce". 563 6. Encrypt response, passing the AEAD function Seal the values of 564 key, nonce, empty aad, and a pt input of request, which yields 565 ct. 567 7. Concatenate response_nonce and ct, yielding an Encapsulated 568 Response enc_response. Note that response_nonce is of fixed- 569 length, so there is no ambiguity in parsing either response_nonce 570 or ct. 572 In pseudocode, this procedure is as follows: 574 secret = context.Export("response", Nk) 575 response_nonce = random(max(Nn, Nk)) 576 salt = concat(enc, response_nonce) 577 prk = Extract(salt, secret) 578 aead_key = Expand(prk, "key", Nk) 579 aead_nonce = Expand(prk, "nonce", Nn) 580 ct = Seal(aead_key, aead_nonce, "", response) 581 enc_response = concat(response_nonce, ct) 583 Clients decrypt an Encapsulated Request by reversing this process. 584 That is, they first parse enc_response into response_nonce and ct. 585 They then follow the same process to derive values for aead_key and 586 aead_nonce. 588 The client uses these values to decrypt ct using the Open function 589 provided by the AEAD. Decrypting might produce an error, as follows: 591 reponse, error = Open(aead_key, aead_nonce, "", ct) 593 6. HTTP Usage 595 A client interacts with the oblivious proxy resource by constructing 596 an encapsulated request. This encapsulated request is included as 597 the content of a POST request to the oblivious proxy resource. This 598 request MUST only contain those fields necessary to carry the 599 encapsulated request: a method of POST, a target URI of the oblivious 600 proxy resource, a header field containing the content type (see 601 (Section 7), and the encapsulated request as the request content. 602 Clients MAY include fields that do not reveal information about the 603 content of the request, such as Alt-Used [ALT-SVC], or information 604 that it trusts the oblivious proxy resource to remove, such as fields 605 that are listed in the Connection header field. 607 The oblivious proxy resource interacts with the oblivious request 608 resource by constructing a request using the same restrictions as the 609 client request, except that the target URI is the oblivious request 610 resource. The content of this request is copied from the client. 611 The oblivious proxy resource MUST NOT add information about the 612 client to this request. 614 When a response is received from the oblivious request resource, the 615 oblivious proxy resource forwards the response according to the rules 616 of an HTTP proxy; see Section 7.6 of [HTTP]. 618 An oblivious request resource, if it receives any response from the 619 oblivious target resource, sends a single 200 response containing the 620 encapsulated response. Like the request from the client, this 621 response MUST only contain those fields necessary to carry the 622 encapsulated response: a 200 status code, a header field indicating 623 the content type, and the encapsulated response as the response 624 content. As with requests, additional fields MAY be used to convey 625 information that does not reveal information about the encapsulated 626 response. 628 An oblivious request resource acts as a gateway for requests to the 629 oblivious target resource (see Section 7.6 of [HTTP]). The one 630 exception is that any information it might forward in a response MUST 631 be encapsulated, unless it is responding to errors it detects before 632 removing encapsulation of the request; see Section 6.2. 634 6.1. Informational Responses 636 This encapsulation does not permit progressive processing of 637 responses. Though the binary HTTP response format does support the 638 inclusion of informational (1xx) status codes, the AEAD encapsulation 639 cannot be removed until the entire message is received. 641 In particular, the Expect header field with 100-continue (see 642 Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct 643 a request that includes a 100-continue expectation; the oblivious 644 request resource MUST generate an error if a 100-continue expectation 645 is received. 647 6.2. Errors 649 A server that receives an invalid message for any reason MUST 650 generate an HTTP response with a 4xx status code. 652 Errors detected by the oblivious proxy resource and errors detected 653 by the oblivious request resource before removing protection 654 (including being unable to remove encapsulation for any reason) 655 result in the status code being sent without protection in response 656 to the POST request made to that resource. 658 Errors detected by the oblivious request resource after successfully 659 removing encapsulation and errors detected by the oblivious target 660 resource MUST be sent in an encapsulated response. 662 7. Media Types 664 Media types are used to identify encapsulated requests and responses. 666 Evolution of the format of encapsulated requests and responses is 667 supported through the definition of new formats that are identified 668 by new media types. 670 7.1. message/ohttp-req Media Type 672 The "message/ohttp-req" identifies an encapsulated binary HTTP 673 request. This is a binary format that is defined in Section 5.1. 675 Type name: message 677 Subtype name: ohttp-req 679 Required parameters: N/A 681 Optional parameters: None 683 Encoding considerations: only "8bit" or "binary" is permitted 685 Security considerations: see Section 8 687 Interoperability considerations: N/A 689 Published specification: this specification 691 Applications that use this media type: N/A 693 Fragment identifier considerations: N/A 695 Additional information: Magic number(s): N/A 697 Deprecated alias names for this type: N/A 699 File extension(s): N/A 700 Macintosh file type code(s): N/A 702 Person and email address to contact for further information: see Aut 703 hors' Addresses section 705 Intended usage: COMMON 707 Restrictions on usage: N/A 709 Author: see Authors' Addresses section 711 Change controller: IESG 713 7.2. message/ohttp-res Media Type 715 The "message/ohttp-res" identifies an encapsulated binary HTTP 716 response. This is a binary format that is defined in Section 5.2. 718 Type name: message 720 Subtype name: ohttp-res 722 Required parameters: N/A 724 Optional parameters: None 726 Encoding considerations: only "8bit" or "binary" is permitted 728 Security considerations: see Section 8 730 Interoperability considerations: N/A 732 Published specification: this specification 734 Applications that use this media type: N/A 736 Fragment identifier considerations: N/A 738 Additional information: Magic number(s): N/A 740 Deprecated alias names for this type: N/A 742 File extension(s): N/A 744 Macintosh file type code(s): N/A 746 Person and email address to contact for further information: see Aut 747 hors' Addresses section 749 Intended usage: COMMON 751 Restrictions on usage: N/A 753 Author: see Authors' Addresses section 755 Change controller: IESG 757 8. Security Considerations 759 In this design, a client wishes to make a request of a server that is 760 authoritative for the oblivious target resource. The client wishes 761 to make this request without linking that request with either: 763 1. The identity at the network and transport layer of the client 764 (that is, the client IP address and TCP or UDP port number the 765 client uses to create a connection). 767 2. Any other request the client might have made in the past or might 768 make in the future. 770 In order to ensure this, the client selects a proxy (that serves the 771 oblivious proxy resource) that it trusts will protect this 772 information by forwarding the encapsulated request and response 773 without passing the server (that serves the oblivious request 774 resource). 776 In this section, a deployment where there are three entities is 777 considered: 779 * A client makes requests and receives responses 781 * A proxy operates the oblivious proxy resource 783 * A server operates both the oblivious request resource and the 784 oblivious target resource 786 To achieve the stated privacy goals, the oblivious proxy resource 787 cannot be operated by the same entity as the oblivious request 788 resource. However, colocation of the oblivious request resource and 789 oblivious target resource simplifies the interactions between those 790 resources without affecting client privacy. 792 As a consequence of this configuration, Oblivious HTTP prevents 793 linkability described above. Informally, this means: 795 1. Requests and responses are known only to clients and targets in 796 possession of the corresponding response encapsulation key and 797 HPKE keying material. In particular, the oblivious proxy knows 798 the origin and destination of an encapsulated request and 799 response, yet does not know the decapsulated contents. Likewise, 800 targets know only the oblivious request origin, i.e., the proxy, 801 and the decapsulated request. Only the client knows both the 802 plaintext request and response. 804 2. Targets cannot link requests from the same client in the absence 805 of unique per-client keys. 807 Traffic analysis that might affect these properties are outside the 808 scope of this document; see Section 8.2.2. 810 A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS]. 812 8.1. Client Responsibilities 814 Clients MUST ensure that the key configuration they select for 815 generating encapsulated requests is integrity protected and 816 authenticated so that it can be attributed to the oblivious request 817 resource; see Section 4. 819 Since clients connect directly to the proxy instead of the target, 820 application configurations wherein clients make policy decisions 821 about target connections, e.g., to apply certificate pinning, are 822 incompatible with Oblivious HTTP. In such cases, alternative 823 technologies such as HTTP CONNECT (Section 9.3.6 of [HTTP]) can be 824 used. Applications could implement related policies on key 825 configurations and proxy connections, though these might not provide 826 the same properties as policies enforced directly on target 827 connections. When this difference is relevant, applications can 828 instead connect directly to the target at the cost of either privacy 829 or performance. 831 Clients MUST NOT include identifying information in the request that 832 is encapsulated. Identifying information includes cookies [COOKIES], 833 authentication credentials or tokens, and any information that might 834 reveal client-specific information such as account credentials. 836 Clients cannot carry connection-level state between requests as they 837 only establish direct connections to the proxy responsible for the 838 oblivious proxy resource. However, clients need to ensure that they 839 construct requests without any information gained from previous 840 requests. Otherwise, the server might be able to use that 841 information to link requests. Cookies [COOKIES] are the most obvious 842 feature that MUST NOT be used by clients. However, clients need to 843 include all information learned from requests, which could include 844 the identity of resources. 846 Clients MUST generate a new HPKE context for every request, using a 847 good source of entropy ([RANDOM]) for generating keys. Key reuse not 848 only risks requests being linked, reuse could expose request and 849 response contents to the proxy. 851 The request the client sends to the oblivious proxy resource only 852 requires minimal information; see Section 6. The request that 853 carries the encapsulated request and is sent to the oblivious proxy 854 resource MUST NOT include identifying information unless the client 855 ensures that this information is removed by the proxy. A client MAY 856 include information only for the oblivious proxy resource in header 857 fields identified by the Connection header field if it trusts the 858 proxy to remove these as required by Section 7.6.1 of [HTTP]. The 859 client needs to trust that the proxy does not replicate the source 860 addressing information in the request it forwards. 862 Clients rely on the oblivious proxy resource to forward encapsulated 863 requests and responses. However, the proxy can only refuse to 864 forward messages, it cannot inspect or modify the contents of 865 encapsulated requests or responses. 867 8.2. Proxy Responsibilities 869 The proxy that serves the oblivious proxy resource has a very simple 870 function to perform. For each request it receives, it makes a 871 request of the oblivious request resource that includes the same 872 content. When it receives a response, it sends a response to the 873 client that includes the content of the response from the oblivious 874 request resource. When generating a request, the proxy MUST follow 875 the forwarding rules in Section 7.6 of [HTTP]. 877 A proxy can also generate responses, though it assumed to not be able 878 to examine the content of a request (other than to observe the choice 879 of key identifier, KDF, and AEAD), so it is also assumed that it 880 cannot generate an encapsulated response. 882 A proxy MUST NOT add information about the client identity when 883 forwarding requests. This includes the Via field, the Forwarded 884 field [FORWARDED], and any similar information. A client does not 885 depend on the proxy using an authenticated and encrypted connection 886 to the oblivious request resource, only that information about the 887 client not be attached to forwarded requests. 889 8.2.1. Denial of Service 891 As there are privacy benefits from having a large rate of requests 892 forwarded by the same proxy (see Section 8.2.2), servers that operate 893 the oblivious request resource might need an arrangement with 894 proxies. This arrangement might be necessary to prevent having the 895 large volume of requests being classified as an attack by the server. 897 If a server accepts a larger volume of requests from a proxy, it 898 needs to trust that the proxy does not allow abusive levels of 899 request volumes from clients. That is, if a server allows requests 900 from the proxy to be exempt from rate limits, the server might want 901 to ensure that the proxy applies a rate limiting policy that is 902 acceptable to the server. 904 Servers that enter into an agreement with a proxy that enables a 905 higher request rate might choose to authenticate the proxy to enable 906 the higher rate. 908 8.2.2. Linkability Through Traffic Analysis 910 As the time at which encapsulated request or response messages are 911 sent can reveal information to a network observer. Though messages 912 exchanged between the oblivious proxy resource and the oblivious 913 request resource might be sent in a single connection, traffic 914 analysis could be used to match messages that are forwarded by the 915 proxy. 917 A proxy could, as part of its function, add delays in order to 918 increase the anonymity set into which each message is attributed. 919 This could latency to the overall time clients take to receive a 920 response, which might not be what some clients want. 922 A proxy can use padding to reduce the effectiveness of traffic 923 analysis. 925 A proxy that forwards large volumes of exchanges can provide better 926 privacy by providing larger sets of messages that need to be matched. 928 8.3. Server Responsibilities 930 A server that operates both oblivious request and oblivious target 931 resources is responsible for removing request encapsulation, 932 generating a response the encapsulated request, and encapsulating the 933 response. 935 Servers should account for traffic analysis based on response size or 936 generation time. Techniques such as padding or timing delays can 937 help protect against such attacks; see Section 8.2.2. 939 If separate entities provide the oblivious request resource and 940 oblivious target resource, these entities might need an arrangement 941 similar to that between server and proxy for managing denial of 942 service; see Section 8.2.1. It is also necessary to provide 943 confidentiality protection for the unprotected requests and 944 responses, plus protections for traffic analysis; see Section 8.2.2. 946 An oblivious request resource needs to have a plan for replacing 947 keys. This might include regular replacement of keys, which can be 948 assigned new key identifiers. If an oblivious request resource 949 receives a request that contains a key identifier that it does not 950 understand or that corresponds to a key that has been replaced, the 951 server can respond with an HTTP 422 (Unprocessable Content) status 952 code. 954 A server can also use a 422 status code if the server has a key that 955 corresponds to the key identifier, but the encapsulated request 956 cannot be successfully decrypted using the key. 958 8.4. Replay Attacks 960 Encapsulated requests can be copied and replayed by the oblivious 961 proxy resource. The design of oblivious HTTP does not assume that 962 the oblivious proxy resource will not replay requests. In addition, 963 if a client sends an encapsulated request in TLS early data (see 964 Section 8 of [TLS] and [RFC8470]), a network-based adversary might be 965 able to cause the request to be replayed. In both cases, the effect 966 of a replay attack and the mitigations that might be employed are 967 similar to TLS early data. 969 A client or oblivious proxy resource MUST NOT automatically attempt 970 to retry a failed request unless it receives a positive signal 971 indicating that the request was not processed or forwarded. The 972 HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [RFC7540]), the 973 HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]), 974 or a GOAWAY frame with a low enough identifier (in either protocol 975 version) are all sufficient signals that no processing occurred. 976 Connection failures or interruptions are not sufficient signals that 977 no processing occurred. 979 The anti-replay mechanisms described in Section 8 of [TLS] are 980 generally applicable to oblivious HTTP requests. Servers can use the 981 encapsulated keying material as a unique key for identifying 982 potential replays. This depends on clients generating a new HPKE 983 context for every request. 985 The mechanism used in TLS for managing differences in client and 986 server clocks cannot be used as it depends on being able to observe 987 previous interactions. Oblivious HTTP explicitly prevents such 988 linkability. Applications can still include an explicit indication 989 of time to limit the span of time over which a server might need to 990 track accepted requests. Clock information could be used for client 991 identification, so reduction in precision or obfuscation might be 992 necessary. 994 The considerations in [RFC8470] as they relate to managing the risk 995 of replay also apply, though there is no option to delay the 996 processing of a request. 998 Limiting requests to those with safe methods might not be 999 satisfactory for some applications, particularly those that involve 1000 the submission of data to a server. The use of idempotent methods 1001 might be of some use in managing replay risk, though it is important 1002 to recognize that different idempotent requests can be combined to be 1003 not idempotent. 1005 Idempotent actions with a narrow scope based on the value of a 1006 protected nonce could enable data submission with limited replay 1007 exposure. A nonce might be added as an explicit part of a request, 1008 or, if the oblivious request and target resources are co-located, the 1009 encapsulated keying material can be used to produce a nonce. 1011 The server-chosen response_nonce field ensures that responses have 1012 unique AEAD keys and nonces even when requests are replayed. 1014 8.5. Post-Compromise Security 1016 This design does not provide post-compromise security for responses. 1017 A client only needs to retain keying material that might be used 1018 compromise the confidentiality and integrity of a response until that 1019 response is consumed, so there is negligible risk associated with a 1020 client compromise. 1022 A server retains a secret key that might be used to remove protection 1023 from messages over much longer periods. A server compromise that 1024 provided access to the oblivious request resource secret key could 1025 allow an attacker to recover the plaintext of all requests sent 1026 toward affected keys and all of the responses that were generated. 1028 Even if server keys are compromised, an adversary cannot access 1029 messages exchanged by the client with the oblivious proxy resource as 1030 messages are protected by TLS. Use of a compromised key also 1031 requires that the oblivious proxy resource cooperate with the 1032 attacker or that the attacker is able to compromise these TLS 1033 connections. 1035 The total number of affected messages affected by server key 1036 compromise can be limited by regular rotation of server keys. 1038 9. Privacy Considerations 1040 One goal of this design is that independent client requests are only 1041 linkable by the chosen key configuration. The oblivious proxy and 1042 request resources can link requests using the same key configuration 1043 by matching KeyConfig.key_id, or, if the oblivious target resource is 1044 willing to use trial decryption, a limited set of key configurations 1045 that share an identifier. An oblivious proxy can link requests using 1046 the public key corresponding to KeyConfig.key_id. 1048 Request resources are capable of linking requests depending on how 1049 KeyConfigs are produced by servers and discovered by clients. 1050 Specifically, servers can maliciously construct key configurations to 1051 track individual clients. A specific method for a client to acquire 1052 key configurations is not included in this specification. Clients 1053 need to consider these tracking vectors when choosing a discovery 1054 method. Applications using this design should provide accommodations 1055 to mitigate tracking using key configurations. 1057 10. Operational and Deployment Considerations 1059 Using Oblivious HTTP adds both cryptographic and latency to requests 1060 relative to a simple HTTP request-response exchange. Deploying proxy 1061 services that are on path between clients and servers avoids adding 1062 significant additional delay due to network topology. A study of a 1063 similar system [ODoH] found that deploying proxies close to servers 1064 was most effective in minimizing additional latency. 1066 Oblivious HTTP might be incompatible with network interception 1067 regimes, such as those that rely on configuring clients with trust 1068 anchors and intercepting TLS connections. While TLS might be 1069 intercepted successfully, interception middleboxes devices might not 1070 receive updates that would allow Oblivious HTTP to be correctly 1071 identified using the media types defined in Section 7. 1073 Oblivious HTTP has a simple key management design that is not 1074 trivially altered to enable interception by intermediaries. Clients 1075 that are configured to enable interception might choose to disable 1076 Oblivious HTTP in order to ensure that content is accessible to 1077 middleboxes. 1079 11. IANA Considerations 1081 Please update the "Media Types" registry at 1082 https://www.iana.org/assignments/media-types 1083 (https://www.iana.org/assignments/media-types) with the registration 1084 information in Section 7 for the media types "message/ohttp-req", 1085 "message/ohttp-res", and "application/ohttp-keys". 1087 12. References 1089 12.1. Normative References 1091 [BINARY] Thomson, M., "Binary Representation of HTTP Messages", 1092 Work in Progress, Internet-Draft, draft-thomson-http- 1093 binary-message-00, 26 October 2021, 1094 . 1097 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1098 "Hybrid Public Key Encryption", Work in Progress, 1099 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 1100 . 1103 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1104 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1105 httpbis-semantics-19, 12 September 2021, 1106 . 1109 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1110 Multiplexed and Secure Transport", RFC 9000, 1111 DOI 10.17487/RFC9000, May 2021, 1112 . 1114 [QUIC-HTTP] 1115 Bishop, M., "Hypertext Transfer Protocol Version 3 1116 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1117 quic-http-34, 2 February 2021, 1118 . 1121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1122 Requirement Levels", BCP 14, RFC 2119, 1123 DOI 10.17487/RFC2119, March 1997, 1124 . 1126 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1127 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1128 DOI 10.17487/RFC7540, May 2015, 1129 . 1131 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1132 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1133 May 2017, . 1135 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1136 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1137 2018, . 1139 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1140 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1141 . 1143 12.2. Informative References 1145 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1146 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1147 April 2016, . 1149 [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1150 DOI 10.17487/RFC6265, April 2011, 1151 . 1153 [Dingledine2004] 1154 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The 1155 Second-Generation Onion Router", August 2004, 1156 . 1159 [FORWARDED] 1160 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1161 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1162 . 1164 [ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T., 1165 Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A. 1166 Wood, "Oblivious DNS over HTTPS (ODoH): A Practical 1167 Privacy Enhancement to DNS", 7 January 2021, 1168 . 1171 [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 1172 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 1173 Internet-Draft, draft-pauly-dprive-oblivious-doh-07, 2 1174 September 2021, . 1177 [OHTTP-ANALYSIS] 1178 Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August 1179 2021, . 1181 [PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, 1182 and Scalable Computation of Aggregate Statistics", 14 1183 March 2017, . 1185 [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1186 "Randomness Requirements for Security", BCP 106, RFC 4086, 1187 DOI 10.17487/RFC4086, June 2005, 1188 . 1190 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1191 DOI 10.17487/RFC6265, April 2011, 1192 . 1194 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1195 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1196 April 2016, . 1198 [X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1199 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1200 2016, . 1202 Appendix A. Complete Example of a Request and Response 1204 A single request and response exchange is shown here. Binary values 1205 (key configuration, secret keys, the content of messages, and 1206 intermediate values) are shown in hexadecimal. The request and 1207 response here are absolutely minimal; the purpose of this example is 1208 to show the cryptographic operations. 1210 The oblivious request resource generates a key pair. In this example 1211 the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 1212 key pair [X25519]. The X25519 secret key is: 1214 cb14d538a70d8a74d47fb7e3ac5052a086da127c678d3585dcad72f98e3bff83 1216 The oblivious request resource constructs a key configuration that 1217 includes the corresponding public key as follows: 1219 01002012a45279412ea6ef11e9f839bb5a422fc1262b5c023d787e4e636e70ae 1220 d3d56e00080001000100010003 1222 This key configuration is somehow obtained by the client. Then when 1223 a client wishes to send an HTTP request of a GET request to 1224 https://example.com, it constructs the following binary HTTP message: 1226 00034745540568747470730b6578616d706c652e636f6d012f 1228 The client then reads the oblivious request resource key 1229 configuration and selects a mutually supported KDF and AEAD. In this 1230 example, the client selects HKDF-SHA256 and AES-128-GCM. The client 1231 then generates an HPKE context that uses the server public key. This 1232 results in the following encapsulated key: 1234 cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 1236 The corresponding private key is: 1238 c20afd33a2f2663faf023acf5d56fc08fddd38aada29b21b3b96e16f4326ccf7 1240 Applying the Seal operation from the HPKE context produces an 1241 encrypted message, allowing the client to construct the following 1242 encapsulated request: 1244 01002000010001cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674 1245 db72730623ca3b68b9e75a0576745da12c4fa5053b7ec06d7f625197564a6087 1246 ec299f8d6fffa2a8addfc1c0f64b4b05 1248 The client then sends this to the oblivious proxy resource in a POST 1249 request, which might look like the following HTTP/1.1 request: 1251 POST /request.example.net/proxy HTTP/1.1 1252 Host: proxy.example.org 1253 Content-Type: message/ohttp-req 1254 Content-Length: 78 1256 1258 The oblivious proxy resource receives this request and forwards it to 1259 the oblivious request resource, which might look like: 1261 POST /oblivious/request HTTP/1.1 1262 Host: example.com 1263 Content-Type: message/ohttp-req 1264 Content-Length: 78 1266 1268 The oblivous request resource receives this request, selects the key 1269 it generated previously using the key identifier from the message, 1270 and decrypts the message. As this request is directed to the same 1271 server, the oblivious request resource does not need to initiate an 1272 HTTP request to the oblivious target resource. The request can be 1273 served directly by the oblivious target resource, which generates a 1274 minimal response (consisting of just a 200 status code) as follows: 1276 0140c8 1278 The response is constructed by extracting a secret from the HPKE 1279 context: 1281 9c0b96b577b9fc7a5beef536e0ff3a64 1283 The key derivation for the encapsulated response uses both the 1284 encapsulated KEM key from the request and a randomly selected nonce. 1285 This produces a salt of: 1287 cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 1288 061d62d5df5832c6c9fa4617ceb848a7 1290 The salt and secret are both passed to the Extract function of the 1291 selected KDF (HKDF-SHA256) to produce a pseudorandom key of: 1293 a0ab55d3b1811694943bb72c386f59bd030e1278692a3db2f30d8aac2f89a5fc 1295 The pseudorandom key is used with the Expand function of the KDF and 1296 an info field of "key" to produce a 16-byte key for the selected AEAD 1297 (AES-128-GCM): 1299 1dae9d7fe263d23e51a768bcaf310aa5 1301 With the same KDF and pseudorandom key, an info field of "nonce" is 1302 used to generate a 12-byte nonce: 1304 e520beec147740e4f8a3b553 1306 The AEAD Seal function is then used to encrypt the response, which is 1307 added to the randomized nonce value to produce the encapsulated 1308 response: 1310 061d62d5df5832c6c9fa4617ceb848a7a6f694da45accc3c32ad576cb204f7cd 1311 3bf23e 1313 The oblivious request resource then constructs a response: 1315 HTTP/1.1 200 OK 1316 Date: Wed, 27 Jan 2021 04:45:07 GMT 1317 Cache-Control: private, no-store 1318 Content-Type: message/ohttp-res 1319 Content-Length: 38 1321 1323 The same response might then be generated by the oblivious proxy 1324 resource which might change as little as the Date header. The client 1325 is then able to use the HPKE context it created and the nonce from 1326 the encapsulated response to construct the AEAD key and nonce and 1327 decrypt the response. 1329 Acknowledgments 1331 This design is based on a design for oblivious DoH, described in 1332 [ODOH]. David Benjamin and Eric Rescorla made technical 1333 contributions. 1335 Authors' Addresses 1337 Martin Thomson 1338 Mozilla 1340 Email: mt@lowentropy.net 1341 Christopher A. Wood 1342 Cloudflare 1344 Email: caw@heapingbits.net