idnits 2.17.00 (12 Aug 2021) /tmp/idnits40869/draft-thomson-http-oblivious-02.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 (24 August 2021) is 263 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 338, 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') == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-18 -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-06 -- 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 (~~), 6 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: 25 February 2022 Cloudflare 6 24 August 2021 8 Oblivious HTTP 9 draft-thomson-http-oblivious-02 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 Discussion of this document takes place on the HTTP Working Group 23 mailing list (http@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/http/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/unicorn-wg/oblivious-http. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 25 February 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8 68 4.2. Key Configuration Media Type . . . . . . . . . . . . . . 8 69 5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 10 71 5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12 72 6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Informational Responses . . . . . . . . . . . . . . . . . 14 74 6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15 77 7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18 80 8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19 81 8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20 82 8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20 83 8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21 84 8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 21 85 8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23 86 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 87 10. Operational and Deployment Considerations . . . . . . . . . . 23 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 91 12.2. Informative References . . . . . . . . . . . . . . . . . 25 92 Appendix A. Complete Example of a Request and Response . . . . . 27 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 The act of making a request using HTTP reveals information about the 99 client identity to a server. Though the content of requests might 100 reveal information, that is information under the control of the 101 client. In comparison, the source address on the connection reveals 102 information that a client has only limited control over. 104 Even where an IP address is not directly attributed to an individual, 105 the use of an address over time can be used to correlate requests. 106 Servers are able to use this information to assemble profiles of 107 client behavior, from which they can make inferences about the people 108 involved. The use of persistent connections to make multiple 109 requests improves performance, but provides servers with additional 110 certainty about the identity of clients in a similar fashion. 112 Use of an HTTP proxy can provide a degree of protection against 113 servers correlating requests. Systems like virtual private networks 114 or the Tor network [Dingledine2004], provide other options for 115 clients. 117 Though the overhead imposed by these methods varies, the cost for 118 each request is significant. Preventing request linkability requires 119 that each request use a completely new TLS connection to the server. 120 At a minimum, this requires an additional round trip to the server in 121 addition to that required by the request. In addition to having high 122 latency, there are significant secondary costs, both in terms of the 123 number of additional bytes exchanged and the CPU cost of 124 cryptographic computations. 126 This document describes a method of encapsulation for binary HTTP 127 messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). 128 This protects the content of both requests and responses and enables 129 a deployment architecture that can separate the identity of a 130 requester from the request. 132 Though this scheme requires that servers and proxies explicitly 133 support it, this design represents a performance improvement over 134 options that perform just one request in each connection. With 135 limited trust placed in the proxy (see Section 8), clients are 136 assured that requests are not uniquely attributed to them or linked 137 to other requests. 139 2. Conventions and Definitions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Encapsulated Request: An HTTP request that is encapsulated in an 148 HPKE-encrypted message; see Section 5.1. 150 Encapsulated Response: An HTTP response that is encapsulated in an 151 HPKE-encrypted message; see Section 5.2. 153 Oblivious Proxy Resource: An intermediary that forwards requests and 154 responses between clients and a single oblivious request resource. 156 Oblivious Request Resource: A resource that can receive an 157 encapsulated request, extract the contents of that request, 158 forward it to an oblivious target resource, receive a response, 159 encapsulate that response, then return that response. 161 Oblivious Target Resource: The resource that is the target of an 162 encapsulated request. This resource logically handles only 163 regular HTTP requests and responses and so might be ignorant of 164 the use of oblivious HTTP to reach it. 166 This draft includes pseudocode that uses the functions and 167 conventions defined in [HPKE]. 169 Encoding an integer to a sequence of bytes in network byte order is 170 described using the function "encode(n, v)", where "n" is the number 171 of bytes and "v" is the integer value. The function "len()" returns 172 the length of a sequence of bytes. 174 Formats are described using notation from Section 1.3 of [QUIC]. 176 3. Overview 178 A client learns the following: 180 * The identity of an oblivious request resource. This might include 181 some information about oblivious target resources that the 182 oblivious request resource supports. 184 * The details of an HPKE public key that the oblivious request 185 resource accepts, including an identifier for that key and the 186 HPKE algorithms that are used with that key. 188 * The identity of an oblivious proxy resource that will forward 189 encapsulated requests and responses to the oblivious request 190 resource. 192 This information allows the client to make a request of an oblivious 193 target resource without that resource having only a limited ability 194 to correlate that request with the client IP or other requests that 195 the client might make to that server. 197 +---------+ +----------+ +----------+ +----------+ 198 | Client | | Proxy | | Request | | Target | 199 | | | Resource | | Resource | | Resource | 200 +---------+ +----------+ +----------+ +----------+ 201 | | | | 202 | Encapsulated | | | 203 | Request | | | 204 |---------------->| Encapsulated | | 205 | | Request | | 206 | |----------------->| Request | 207 | | |-------------->| 208 | | | | 209 | | | Response | 210 | | Encapsulated |<--------------| 211 | | Response | | 212 | Encapsulated |<-----------------| | 213 | Response | | | 214 |<----------------| | | 215 | | | | 217 Figure 1: Overview of Oblivious HTTP 219 In order to make a request to an oblivious target resource, the 220 following steps occur, as shown in Figure 1: 222 1. The client constructs an HTTP request for an oblivious target 223 resource. 225 2. The client encodes the HTTP request in a binary HTTP message and 226 then encapsulates that message using HPKE and the process from 227 Section 5.1. 229 3. The client sends a POST request to the oblivious proxy resource 230 with the encapsulated request as the content of that message. 232 4. The oblivious proxy resource forwards this request to the 233 oblivious request resource. 235 5. The oblivious request resource receives this request and removes 236 the HPKE protection to obtain an HTTP request. 238 6. The oblivious request resource makes an HTTP request that 239 includes the target URI, method, fields, and content of the 240 request it acquires. 242 7. The oblivious target resource answers this HTTP request with an 243 HTTP response. 245 8. The oblivious request resource encapsulates the HTTP response 246 following the process in Section 5.2 and sends this in response 247 to the request from the oblivious proxy resource. 249 9. The oblivious proxy resource forwards this response to the 250 client. 252 10. The client removes the encapsulation to obtain the response to 253 the original request. 255 3.1. Applicability 257 Oblivious HTTP has limited applicability. Many uses of HTTP benefit 258 from being able to carry state between requests, such as with cookies 259 ([RFC6265]), authentication (Section 11 of [HTTP]), or even 260 alternative services ([RFC7838]). Oblivious HTTP seeks to prevent 261 this sort of linkage, which requires that applications not carry 262 state between requests. 264 Oblivious HTTP is primarily useful where privacy risks associated 265 with possible stateful treatment of requests are sufficiently 266 negative that the cost of deploying this protocol can be justified. 267 Oblivious HTTP is simpler and less costly than more robust systems, 268 like Prio ([PRIO]) or Tor ([Dingledine2004]), which can provide 269 stronger guarantees at higher operational costs. 271 Oblivious HTTP is more costly than a direct connection to a server. 272 Some costs, like those involved with connection setup, can be 273 amortized, but there are several ways in which oblivious HTTP is more 274 expensive than a direct request: 276 * Each oblivious request requires at least two regular HTTP 277 requests, which adds latency. 279 * Each request is expanded in size with additional HTTP fields, 280 encryption-related metadata, and AEAD expansion. 282 * Deriving cryptographic keys and applying them for request and 283 response protection takes non-negligible computational resources. 285 Examples of where preventing the linking of requests might justify 286 these costs include: 288 * DNS queries. DNS queries made to a recursive resolver reveal 289 information about the requester, particularly if linked to other 290 queries. 292 * Telemetry submission. Applications that submit reports about 293 their usage to their developers might use oblivious HTTP for some 294 types of moderately sensitive data. 296 4. Key Configuration 298 A client needs to acquire information about the key configuration of 299 the oblivious request resource in order to send encapsulated 300 requests. 302 In order to ensure that clients do not encapsulate messages that 303 other entities can intercept, the key configuration MUST be 304 authenticated and have integrity protection. 306 This document describes the "application/ohttp-keys" media type; see 307 Section 4.2. This media type might be used, for example with HTTPS, 308 as part of a system for configuring or discovering key 309 configurations. Note however that such a system needs to consider 310 the potential for key configuration to be used to compromise client 311 privacy; see Section 9. 313 Specifying a format for expressing the information a client needs to 314 construct an encapsulated request ensures that different client 315 implementations can be configured in the same way. This also enables 316 advertising key configurations in a consistent format. 318 A client might have multiple key configurations to select from when 319 encapsulating a request. Clients are responsible for selecting a 320 preferred key configuration from those it supports. Clients need to 321 consider both the key encapsulation method (KEM) and the combinations 322 of key derivation function (KDF) and authenticated encryption with 323 associated data (AEAD) in this decision. 325 Evolution of the key configuration format is supported through the 326 definition of new formats that are identified by new media types. 328 4.1. Key Configuration Encoding 330 A single key configuration consists of a key identifier, a public 331 key, an identifier for the KEM that the public key uses, and a set 332 HPKE symmetric algorithms. Each symmetric algorithm consists of an 333 identifier for a KDF and an identifier for an AEAD. 335 Figure 2 shows a single key configuration, KeyConfig, that is 336 expressed using the TLS syntax; see Section 3 of [TLS]. 338 opaque HpkePublicKey[Npk]; 339 uint16 HpkeKemId; 340 uint16 HpkeKdfId; 341 uint16 HpkeAeadId; 343 struct { 344 HpkeKdfId kdf_id; 345 HpkeAeadId aead_id; 346 } HpkeSymmetricAlgorithms; 348 struct { 349 uint8 key_id; 350 HpkeKemId kem_id; 351 HpkePublicKey public_key; 352 HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>; 353 } KeyConfig; 355 Figure 2: A Single Key Configuration 357 The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, 358 and AEAD respectively. The definitions for these identifiers and the 359 semantics of the algorithms they identify can be found in [HPKE]. 360 The Npk parameter corresponding to the HpkeKdfId can be found in 361 [HPKE]. 363 4.2. Key Configuration Media Type 365 The "application/ohttp-keys" format is a media type that identifies a 366 serialized collection of key configurations. The content of this 367 media type comprises one or more key configuration encodings (see 368 Section 4.1) that are concatenated. 370 Type name: application 372 Subtype name: ohttp-keys 374 Required parameters: N/A 375 Optional parameters: None 377 Encoding considerations: only "8bit" or "binary" is permitted 379 Security considerations: see Section 8 381 Interoperability considerations: N/A 383 Published specification: this specification 385 Applications that use this media type: N/A 387 Fragment identifier considerations: N/A 389 Additional information: Magic number(s): N/A 391 Deprecated alias names for this type: N/A 393 File extension(s): N/A 395 Macintosh file type code(s): N/A 397 Person and email address to contact for further information: see Aut 398 hors' Addresses section 400 Intended usage: COMMON 402 Restrictions on usage: N/A 404 Author: see Authors' Addresses section 406 Change controller: IESG 408 5. HPKE Encapsulation 410 HTTP message encapsulation uses HPKE for request and response 411 encryption. An encapsulated HTTP message includes the following 412 values: 414 1. A binary-encoded HTTP message; see [BINARY]. 416 2. Padding of arbitrary length which MUST contain all zeroes. 418 The encoding of an HTTP message is as follows: 420 Plaintext Message { 421 Message Length (i), 422 Message (..), 423 Padding Length (i), 424 Padding (..), 425 } 427 An Encapsulated Request is comprised of a length-prefixed key 428 identifier and a HPKE-protected request message. HPKE protection 429 includes an encapsulated KEM shared secret (or "enc"), plus the AEAD- 430 protected request message. An Encapsulated Request is shown in 431 Figure 3. Section 5.1 describes the process for constructing and 432 processing an Encapsulated Request. 434 Encapsulated Request { 435 Key Identifier (8), 436 KEM Identifier (16), 437 KDF Identifier (16), 438 AEAD Identifier (16), 439 Encapsulated KEM Shared Secret (8*Nenc), 440 AEAD-Protected Request (..), 441 } 443 Figure 3: Encapsulated Request 445 The Nenc parameter corresponding to the HpkeKdfId can be found in 446 [HPKE]. 448 Responses are bound to responses and so consist only of AEAD- 449 protected content. Section 5.2 describes the process for 450 constructing and processing an Encapsulated Response. 452 Encapsulated Response { 453 Nonce (Nk), 454 AEAD-Protected Response (..), 455 } 457 Figure 4: Encapsulated Response 459 The size of the Nonce field in an Encapsulated Response corresponds 460 to the size of an AEAD key for the corresponding HPKE ciphersuite. 462 5.1. Encapsulation of Requests 464 Clients encapsulate a request "request" using values from a key 465 configuration: 467 * the key identifier from the configuration, "keyID", with the 468 corresponding KEM identified by "kemID", 470 * the public key from the configuration, "pkR", and 472 * a selected combination of KDF, identified by "kdfID", and AEAD, 473 identified by "aeadID". 475 The client then constructs an encapsulated request, "enc_request", as 476 follows: 478 1. Compute an HPKE context using "pkR", yielding "context" and 479 encapsulation key "enc". 481 2. Construct associated data, "aad", by concatenating the values of 482 "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and 483 three 16-bit integers, respectively, each in network byte order. 485 3. Encrypt (seal) "request" with "aad" as associated data using 486 "context", yielding ciphertext "ct". 488 4. Concatenate the values of "aad", "enc", and "ct", yielding an 489 Encapsulated Request "enc_request". 491 Note that "enc" is of fixed-length, so there is no ambiguity in 492 parsing this structure. 494 In pseudocode, this procedure is as follows: 496 enc, context = SetupBaseS(pkR, "request") 497 aad = concat(encode(1, keyID), 498 encode(2, kemID), 499 encode(2, kdfID), 500 encode(2, aeadID)) 501 ct = context.Seal(aad, request) 502 enc_request = concat(aad, enc, ct) 504 Servers decrypt an Encapsulated Request by reversing this process. 505 Given an Encapsulated Request "enc_request", a server: 507 1. Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", 508 "enc", and "ct" (indicated using the function "parse()" in 509 pseudocode). The server is then able to find the HPKE private 510 key, "skR", corresponding to "keyID". 512 a. If "keyID" does not identify a key matching the type of 513 "kemID", the server returns an error. 515 b. If "kdfID" and "aeadID" identify a combination of KDF and 516 AEAD that the server is unwilling to use with "skR", the server 517 returns an error. 519 2. Compute an HPKE context using "skR" and the encapsulated key 520 "enc", yielding "context". 522 3. Construct additional associated data, "aad", from "keyID", 523 "kdfID", and "aeadID" or as the first five bytes of 524 "enc_request". 526 4. Decrypt "ct" using "aad" as associated data, yielding "request" 527 or an error on failure. If decryption fails, the server returns 528 an error. 530 In pseudocode, this procedure is as follows: 532 keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request) 533 aad = concat(encode(1, keyID), 534 encode(2, kemID), 535 encode(2, kdfID), 536 encode(2, aeadID)) 537 context = SetupBaseR(enc, skR, "request") 538 request, error = context.Open(aad, ct) 540 5.2. Encapsulation of Responses 542 Given an HPKE context "context", a request message "request", and a 543 response "response", servers generate an Encapsulated Response 544 "enc_response" as follows: 546 1. Export a secret "secret" from "context", using the string 547 "response" as context. The length of this secret is "max(Nn, 548 Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce 549 associated with "context". 551 2. Generate a random value of length "max(Nn, Nk)" bytes, called 552 "response_nonce". 554 3. Extract a pseudorandom key "prk" using the "Extract" function 555 provided by the KDF algorithm associated with "context". The 556 "ikm" input to this function is "secret"; the "salt" input is the 557 concatenation of "enc" (from "enc_request") and "response_nonce" 559 4. Use the "Expand" function provided by the same KDF to extract an 560 AEAD key "key", of length "Nk" - the length of the keys used by 561 the AEAD associated with "context". Generating "key" uses a 562 label of "key". 564 5. Use the same "Expand" function to extract a nonce "nonce" of 565 length "Nn" - the length of the nonce used by the AEAD. 566 Generating "nonce" uses a label of "nonce". 568 6. Encrypt "response", passing the AEAD function Seal the values of 569 "key", "nonce", empty "aad", and a "pt" input of "request", which 570 yields "ct". 572 7. Concatenate "response_nonce" and "ct", yielding an Encapsulated 573 Response "enc_response". Note that "response_nonce" is of fixed- 574 length, so there is no ambiguity in parsing either 575 "response_nonce" or "ct". 577 In pseudocode, this procedure is as follows: 579 secret = context.Export("response", Nk) 580 response_nonce = random(max(Nn, Nk)) 581 salt = concat(enc, response_nonce) 582 prk = Extract(salt, secret) 583 aead_key = Expand(prk, "key", Nk) 584 aead_nonce = Expand(prk, "nonce", Nn) 585 ct = Seal(aead_key, aead_nonce, "", response) 586 enc_response = concat(response_nonce, ct) 588 Clients decrypt an Encapsulated Request by reversing this process. 589 That is, they first parse "enc_response" into "response_nonce" and 590 "ct". They then follow the same process to derive values for 591 "aead_key" and "aead_nonce". 593 The client uses these values to decrypt "ct" using the Open function 594 provided by the AEAD. Decrypting might produce an error, as follows: 596 reponse, error = Open(aead_key, aead_nonce, "", ct) 598 6. HTTP Usage 600 A client interacts with the oblivious proxy resource by constructing 601 an encapsulated request. This encapsulated request is included as 602 the content of a POST request to the oblivious proxy resource. This 603 request MUST only contain those fields necessary to carry the 604 encapsulated request: a method of POST, a target URI of the oblivious 605 proxy resource, a header field containing the content type (see 606 (Section 7), and the encapsulated request as the request content. 607 Clients MAY include fields that do not reveal information about the 608 content of the request, such as Alt-Used [ALT-SVC], or information 609 that it trusts the oblivious proxy resource to remove, such as fields 610 that are listed in the Connection header field. 612 The oblivious proxy resource interacts with the oblivious request 613 resource by constructing a request using the same restrictions as the 614 client request, except that the target URI is the oblivious request 615 resource. The content of this request is copied from the client. 616 The oblivious proxy resource MUST NOT add information about the 617 client to this request. 619 When a response is received from the oblivious request resource, the 620 oblivious proxy resource forwards the response according to the rules 621 of an HTTP proxy; see Section 7.6 of [HTTP]. 623 An oblivious request resource, if it receives any response from the 624 oblivious target resource, sends a single 200 response containing the 625 encapsulated response. Like the request from the client, this 626 response MUST only contain those fields necessary to carry the 627 encapsulated response: a 200 status code, a header field indicating 628 the content type, and the encapsulated response as the response 629 content. As with requests, additional fields MAY be used to convey 630 information that does not reveal information about the encapsulated 631 response. 633 An oblivious request resource acts as a gateway for requests to the 634 oblivious target resource (see Section 7.6 of [HTTP]). The one 635 exception is that any information it might forward in a response MUST 636 be encapsulated, unless it is responding to errors it detects before 637 removing encapsulation of the request; see Section 6.2. 639 6.1. Informational Responses 641 This encapsulation does not permit progressive processing of 642 responses. Though the binary HTTP response format does support the 643 inclusion of informational (1xx) status codes, the AEAD encapsulation 644 cannot be removed until the entire message is received. 646 In particular, the Expect header field with 100-continue (see 647 Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct 648 a request that includes a 100-continue expectation; the oblivious 649 request resource MUST generate an error if a 100-continue expectation 650 is received. 652 6.2. Errors 654 A server that receives an invalid message for any reason MUST 655 generate an HTTP response with a 4xx status code. 657 Errors detected by the oblivious proxy resource and errors detected 658 by the oblivious request resource before removing protection 659 (including being unable to remove encapsulation for any reason) 660 result in the status code being sent without protection in response 661 to the POST request made to that resource. 663 Errors detected by the oblivious request resource after successfully 664 removing encapsulation and errors detected by the oblivious target 665 resource MUST be sent in an encapsulated response. 667 7. Media Types 669 Media types are used to identify encapsulated requests and responses. 671 Evolution of the format of encapsulated requests and responses is 672 supported through the definition of new formats that are identified 673 by new media types. 675 7.1. message/ohttp-req Media Type 677 The "message/ohttp-req" identifies an encapsulated binary HTTP 678 request. This is a binary format that is defined in Section 5.1. 680 Type name: message 682 Subtype name: ohttp-req 684 Required parameters: N/A 686 Optional parameters: None 688 Encoding considerations: only "8bit" or "binary" is permitted 690 Security considerations: see Section 8 692 Interoperability considerations: N/A 694 Published specification: this specification 696 Applications that use this media type: N/A 698 Fragment identifier considerations: N/A 700 Additional information: Magic number(s): N/A 702 Deprecated alias names for this type: N/A 704 File extension(s): N/A 705 Macintosh file type code(s): N/A 707 Person and email address to contact for further information: see Aut 708 hors' Addresses section 710 Intended usage: COMMON 712 Restrictions on usage: N/A 714 Author: see Authors' Addresses section 716 Change controller: IESG 718 7.2. message/ohttp-res Media Type 720 The "message/ohttp-res" identifies an encapsulated binary HTTP 721 response. This is a binary format that is defined in Section 5.2. 723 Type name: message 725 Subtype name: ohttp-res 727 Required parameters: N/A 729 Optional parameters: None 731 Encoding considerations: only "8bit" or "binary" is permitted 733 Security considerations: see Section 8 735 Interoperability considerations: N/A 737 Published specification: this specification 739 Applications that use this media type: N/A 741 Fragment identifier considerations: N/A 743 Additional information: Magic number(s): N/A 745 Deprecated alias names for this type: N/A 747 File extension(s): N/A 749 Macintosh file type code(s): N/A 751 Person and email address to contact for further information: see Aut 752 hors' Addresses section 754 Intended usage: COMMON 756 Restrictions on usage: N/A 758 Author: see Authors' Addresses section 760 Change controller: IESG 762 8. Security Considerations 764 In this design, a client wishes to make a request of a server that is 765 authoritative for the oblivious target resource. The client wishes 766 to make this request without linking that request with either: 768 1. The identity at the network and transport layer of the client 769 (that is, the client IP address and TCP or UDP port number the 770 client uses to create a connection). 772 2. Any other request the client might have made in the past or might 773 make in the future. 775 In order to ensure this, the client selects a proxy (that serves the 776 oblivious proxy resource) that it trusts will protect this 777 information by forwarding the encapsulated request and response 778 without passing the server (that serves the oblivious request 779 resource). 781 In this section, a deployment where there are three entities is 782 considered: 784 * A client makes requests and receives responses 786 * A proxy operates the oblivious proxy resource 788 * A server operates both the oblivious request resource and the 789 oblivious target resource 791 To achieve the stated privacy goals, the oblivious proxy resource 792 cannot be operated by the same entity as the oblivious request 793 resource. However, colocation of the oblivious request resource and 794 oblivious target resource simplifies the interactions between those 795 resources without affecting client privacy. 797 As a consequence of this configuration, Oblivious HTTP prevents 798 linkability described above. Informally, this means: 800 1. Requests and responses are known only to clients and targets in 801 possession of the corresponding response encapsulation key and 802 HPKE keying material. In particular, the oblivious proxy knows 803 the origin and destination of an encapsulated request and 804 response, yet does not know the decapsulated contents. Likewise, 805 targets know only the oblivious request origin, i.e., the proxy, 806 and the decapsulated request. Only the client knows both the 807 plaintext request and response. 809 2. Targets cannot link requests from the same client in the absence 810 of unique per-client keys. 812 Traffic analysis that might affect these properties are outside the 813 scope of this document; see Section 8.2.2. 815 A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS]. 817 8.1. Client Responsibilities 819 Clients MUST ensure that the key configuration they select for 820 generating encapsulated requests is integrity protected and 821 authenticated so that it can be attributed to the oblivious request 822 resource; see Section 4. 824 Since clients connect directly to the proxy instead of the target, 825 application configurations wherein clients make policy decisions 826 about target connections, e.g., to apply certificate pinning, are 827 incompatible with Oblivious HTTP. In such cases, alternative 828 technologies such as HTTP CONNECT (Section 9.3.6 of [HTTP]) can be 829 used. Applications could implement related policies on key 830 configurations and proxy connections, though these might not provide 831 the same properties as policies enforced directly on target 832 connections. When this difference is relevant, applications can 833 instead connect directly to the target at the cost of either privacy 834 or performance. 836 Clients MUST NOT include identifying information in the request that 837 is encapsulated. Identifying information includes cookies [COOKIES], 838 authentication credentials or tokens, and any information that might 839 reveal client-specific information such as account credentials. 841 Clients cannot carry connection-level state between requests as they 842 only establish direct connections to the proxy responsible for the 843 oblivious proxy resource. However, clients need to ensure that they 844 construct requests without any information gained from previous 845 requests. Otherwise, the server might be able to use that 846 information to link requests. Cookies [COOKIES] are the most obvious 847 feature that MUST NOT be used by clients. However, clients need to 848 include all information learned from requests, which could include 849 the identity of resources. 851 Clients MUST generate a new HPKE context for every request, using a 852 good source of entropy ([RANDOM]) for generating keys. Key reuse not 853 only risks requests being linked, reuse could expose request and 854 response contents to the proxy. 856 The request the client sends to the oblivious proxy resource only 857 requires minimal information; see Section 6. The request that 858 carries the encapsulated request and is sent to the oblivious proxy 859 resource MUST NOT include identifying information unless the client 860 ensures that this information is removed by the proxy. A client MAY 861 include information only for the oblivious proxy resource in header 862 fields identified by the Connection header field if it trusts the 863 proxy to remove these as required by Section 7.6.1 of [HTTP]. The 864 client needs to trust that the proxy does not replicate the source 865 addressing information in the request it forwards. 867 Clients rely on the oblivious proxy resource to forward encapsulated 868 requests and responses. However, the proxy can only refuse to 869 forward messages, it cannot inspect or modify the contents of 870 encapsulated requests or responses. 872 8.2. Proxy Responsibilities 874 The proxy that serves the oblivious proxy resource has a very simple 875 function to perform. For each request it receives, it makes a 876 request of the oblivious request resource that includes the same 877 content. When it receives a response, it sends a response to the 878 client that includes the content of the response from the oblivious 879 request resource. When generating a request, the proxy MUST follow 880 the forwarding rules in Section 7.6 of [HTTP]. 882 A proxy can also generate responses, though it assumed to not be able 883 to examine the content of a request (other than to observe the choice 884 of key identifier, KDF, and AEAD), so it is also assumed that it 885 cannot generate an encapsulated response. 887 A proxy MUST NOT add information about the client identity when 888 forwarding requests. This includes the Via field, the Forwarded 889 field [FORWARDED], and any similar information. A client does not 890 depend on the proxy using an authenticated and encrypted connection 891 to the oblivious request resource, only that information about the 892 client not be attached to forwarded requests. 894 8.2.1. Denial of Service 896 As there are privacy benefits from having a large rate of requests 897 forwarded by the same proxy (see Section 8.2.2), servers that operate 898 the oblivious request resource might need an arrangement with 899 proxies. This arrangement might be necessary to prevent having the 900 large volume of requests being classified as an attack by the server. 902 If a server accepts a larger volume of requests from a proxy, it 903 needs to trust that the proxy does not allow abusive levels of 904 request volumes from clients. That is, if a server allows requests 905 from the proxy to be exempt from rate limits, the server might want 906 to ensure that the proxy applies a rate limiting policy that is 907 acceptable to the server. 909 Servers that enter into an agreement with a proxy that enables a 910 higher request rate might choose to authenticate the proxy to enable 911 the higher rate. 913 8.2.2. Linkability Through Traffic Analysis 915 As the time at which encapsulated request or response messages are 916 sent can reveal information to a network observer. Though messages 917 exchanged between the oblivious proxy resource and the oblivious 918 request resource might be sent in a single connection, traffic 919 analysis could be used to match messages that are forwarded by the 920 proxy. 922 A proxy could, as part of its function, add delays in order to 923 increase the anonymity set into which each message is attributed. 924 This could latency to the overall time clients take to receive a 925 response, which might not be what some clients want. 927 A proxy can use padding to reduce the effectiveness of traffic 928 analysis. 930 A proxy that forwards large volumes of exchanges can provide better 931 privacy by providing larger sets of messages that need to be matched. 933 8.3. Server Responsibilities 935 A server that operates both oblivious request and oblivious target 936 resources is responsible for removing request encapsulation, 937 generating a response the encapsulated request, and encapsulating the 938 response. 940 Servers should account for traffic analysis based on response size or 941 generation time. Techniques such as padding or timing delays can 942 help protect against such attacks; see Section 8.2.2. 944 If separate entities provide the oblivious request resource and 945 oblivious target resource, these entities might need an arrangement 946 similar to that between server and proxy for managing denial of 947 service; see Section 8.2.1. It is also necessary to provide 948 confidentiality protection for the unprotected requests and 949 responses, plus protections for traffic analysis; see Section 8.2.2. 951 An oblivious request resource needs to have a plan for replacing 952 keys. This might include regular replacement of keys, which can be 953 assigned new key identifiers. If an oblivious request resource 954 receives a request that contains a key identifier that it does not 955 understand or that corresponds to a key that has been replaced, the 956 server can respond with an HTTP 422 (Unprocessable Content) status 957 code. 959 A server can also use a 422 status code if the server has a key that 960 corresponds to the key identifier, but the encapsulated request 961 cannot be successfully decrypted using the key. 963 8.4. Replay Attacks 965 Encapsulated requests can be copied and replayed by the oblivious 966 proxy resource. The design of oblivious HTTP does not assume that 967 the oblivious proxy resource will not replay requests. In addition, 968 if a client sends an encapsulated request in TLS early data (see 969 Section 8 of [TLS] and [RFC8470]), a network-based adversary might be 970 able to cause the request to be replayed. In both cases, the effect 971 of a replay attack and the mitigations that might be employed are 972 similar to TLS early data. 974 A client or oblivious proxy resource MUST NOT automatically attempt 975 to retry a failed request unless it receives a positive signal 976 indicating that the request was not processed or forwarded. The 977 HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [RFC7540]), the 978 HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]), 979 or a GOAWAY frame with a low enough identifier (in either protocol 980 version) are all sufficient signals that no processing occurred. 981 Connection failures or interruptions are not sufficient signals that 982 no processing occurred. 984 The anti-replay mechanisms described in Section 8 of [TLS] are 985 generally applicable to oblivious HTTP requests. Servers can use the 986 encapsulated keying material as a unique key for identifying 987 potential replays. This depends on clients generating a new HPKE 988 context for every request. 990 The mechanism used in TLS for managing differences in client and 991 server clocks cannot be used as it depends on being able to observe 992 previous interactions. Oblivious HTTP explicitly prevents such 993 linkability. Applications can still include an explicit indication 994 of time to limit the span of time over which a server might need to 995 track accepted requests. Clock information could be used for client 996 identification, so reduction in precision or obfuscation might be 997 necessary. 999 The considerations in [RFC8470] as they relate to managing the risk 1000 of replay also apply, though there is no option to delay the 1001 processing of a request. 1003 Limiting requests to those with safe methods might not be 1004 satisfactory for some applications, particularly those that involve 1005 the submission of data to a server. The use of idempotent methods 1006 might be of some use in managing replay risk, though it is important 1007 to recognize that different idempotent requests can be combined to be 1008 not idempotent. 1010 Idempotent actions with a narrow scope based on the value of a 1011 protected nonce could enable data submission with limited replay 1012 exposure. A nonce might be added as an explicit part of a request, 1013 or, if the oblivious request and target resources are co-located, the 1014 encapsulated keying material can be used to produce a nonce. 1016 The server-chosen "response_nonce" field ensures that responses have 1017 unique AEAD keys and nonces even when requests are replayed. 1019 8.5. Post-Compromise Security 1021 This design does not provide post-compromise security for responses. 1022 A client only needs to retain keying material that might be used 1023 compromise the confidentiality and integrity of a response until that 1024 response is consumed, so there is negligible risk associated with a 1025 client compromise. 1027 A server retains a secret key that might be used to remove protection 1028 from messages over much longer periods. A server compromise that 1029 provided access to the oblivious request resource secret key could 1030 allow an attacker to recover the plaintext of all requests sent 1031 toward affected keys and all of the responses that were generated. 1032 Accessing requests and responses also requires access to requests and 1033 responses, which implies either compromise of TLS connections or 1034 collusion with the oblivious proxy resource. 1036 The total number of affected messages affected by server key 1037 compromise can be limited by regular rotation of server keys. 1039 9. Privacy Considerations 1041 One goal of this design is that independent client requests are only 1042 linkable by the chosen key configuration. The oblivious proxy and 1043 request resources can link requests using the same key configuration 1044 by matching KeyConfig.key_id, or, if the oblivious target resource is 1045 willing to use trial decryption, a limited set of key configurations 1046 that share an identifier. An oblivious proxy can link requests using 1047 the public key corresponding to KeyConfig.key_id. 1049 Request resources are capable of linking requests depending on how 1050 KeyConfigs are produced by servers and discovered by clients. 1051 Specifically, servers can maliciously construct key configurations to 1052 track individual clients. A specific method for a client to acquire 1053 key configurations is not included in this specification. Clients 1054 need to consider these tracking vectors when choosing a discovery 1055 method. Applications using this design should provide accommodations 1056 to mitigate tracking use key configurations. 1058 10. Operational and Deployment Considerations 1060 Using Oblivious HTTP adds both cryptographic and latency to requests 1061 relative to a simple HTTP request-response exchange. Deploying proxy 1062 services that are on path between clients and servers avoids adding 1063 significant additional delay due to network topology. A study of a 1064 similar system [ODoH] found that deploying proxies close to servers 1065 was most effective in minimizing additional latency. 1067 Oblivious HTTP might be incompatible with network interception 1068 regimes, such as those that rely on configuring clients with trust 1069 anchors and intercepting TLS connections. While TLS might be 1070 intercepted successfully, interception middleboxes devices might not 1071 receive updates that would allow Oblivious HTTP to be correctly 1072 identified using the media types defined in Section 7. 1074 Oblivious HTTP has a simple key management design that is not 1075 trivially altered to enable interception by intermediaries. Clients 1076 that are configured to enable interception might choose to disable 1077 Oblivious HTTP in order to ensure that content is accessible to 1078 middleboxes. 1080 11. IANA Considerations 1082 Please update the "Media Types" registry at 1083 https://www.iana.org/assignments/media-types 1084 (https://www.iana.org/assignments/media-types) with the registration 1085 information in Section 7 for the media types "message/ohttp-req", 1086 "message/ohttp-res", and "application/ohttp-keys". 1088 12. References 1090 12.1. Normative References 1092 [BINARY] Thomson, M., "Binary Representation of HTTP Messages", 1093 Work in Progress, Internet-Draft, draft-thomson-http- 1094 binary-message-00, 24 August 2021, 1095 . 1098 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1099 "Hybrid Public Key Encryption", Work in Progress, 1100 Internet-Draft, draft-irtf-cfrg-hpke-11, 2 August 2021, 1101 . 1104 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1105 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1106 httpbis-semantics-18, 18 August 2021, 1107 . 1110 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1111 Multiplexed and Secure Transport", RFC 9000, 1112 DOI 10.17487/RFC9000, May 2021, 1113 . 1115 [QUIC-HTTP] 1116 Bishop, M., "Hypertext Transfer Protocol Version 3 1117 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1118 quic-http-34, 2 February 2021, 1119 . 1122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1123 Requirement Levels", BCP 14, RFC 2119, 1124 DOI 10.17487/RFC2119, March 1997, 1125 . 1127 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1128 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1129 DOI 10.17487/RFC7540, May 2015, 1130 . 1132 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1133 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1134 May 2017, . 1136 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1137 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1138 2018, . 1140 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1141 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1142 . 1144 12.2. Informative References 1146 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1147 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1148 April 2016, . 1150 [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1151 DOI 10.17487/RFC6265, April 2011, 1152 . 1154 [Dingledine2004] 1155 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The 1156 Second-Generation Onion Router", August 2004, 1157 . 1160 [FORWARDED] 1161 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1162 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1163 . 1165 [ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T., 1166 Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A. 1167 Wood, "Oblivious DNS over HTTPS (ODoH): A Practical 1168 Privacy Enhancement to DNS", 7 January 2021, 1169 . 1172 [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 1173 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 1174 Internet-Draft, draft-pauly-dprive-oblivious-doh-06, 8 1175 March 2021, . 1178 [OHTTP-ANALYSIS] 1179 Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August 1180 2021, . 1182 [PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, 1183 and Scalable Computation of Aggregate Statistics", 14 1184 March 2017, . 1186 [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1187 "Randomness Requirements for Security", BCP 106, RFC 4086, 1188 DOI 10.17487/RFC4086, June 2005, 1189 . 1191 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1192 DOI 10.17487/RFC6265, April 2011, 1193 . 1195 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1196 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1197 April 2016, . 1199 [X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1200 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1201 2016, . 1203 Appendix A. Complete Example of a Request and Response 1205 A single request and response exchange is shown here. Binary values 1206 (key configuration, secret keys, the content of messages, and 1207 intermediate values) are shown in hexadecimal. The request and 1208 response here are absolutely minimal; the purpose of this example is 1209 to show the cryptographic operations. 1211 The oblivious request resource generates a key pair. In this example 1212 the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 1213 key pair [X25519]. The X25519 secret key is: 1215 cb14d538a70d8a74d47fb7e3ac5052a086da127c678d3585dcad72f98e3bff83 1217 The oblivious request resource constructs a key configuration that 1218 includes the corresponding public key as follows: 1220 01002012a45279412ea6ef11e9f839bb5a422fc1262b5c023d787e4e636e70ae 1221 d3d56e00080001000100010003 1223 This key configuration is somehow obtained by the client. Then when 1224 a client wishes to send an HTTP request of a GET request to 1225 "https://example.com", it constructs the following binary HTTP 1226 message: 1228 00034745540568747470730b6578616d706c652e636f6d012f 1230 The client then reads the oblivious request resource key 1231 configuration and selects a mutually supported KDF and AEAD. In this 1232 example, the client selects HKDF-SHA256 and AES-128-GCM. The client 1233 then generates an HPKE context that uses the server public key. This 1234 results in the following encapsulated key: 1236 cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 1238 The corresponding private key is: 1240 c20afd33a2f2663faf023acf5d56fc08fddd38aada29b21b3b96e16f4326ccf7 1242 Applying the Seal operation from the HPKE context produces an 1243 encrypted message, allowing the client to construct the following 1244 encapsulated request: 1246 01002000010001cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674 1247 db72730623ca3b68b9e75a0576745da12c4fa5053b7ec06d7f625197564a6087 1248 ec299f8d6fffa2a8addfc1c0f64b4b05 1249 The client then sends this to the oblivious proxy resource in a POST 1250 request, which might look like the following HTTP/1.1 request: 1252 POST /request.example.net/proxy HTTP/1.1 1253 Host: proxy.example.org 1254 Content-Type: message/ohttp-req 1255 Content-Length: 78 1257 1259 The oblivious proxy resource receives this request and forwards it to 1260 the oblivious request resource, which might look like: 1262 POST /oblivious/request HTTP/1.1 1263 Host: example.com 1264 Content-Type: message/ohttp-req 1265 Content-Length: 78 1267 1269 The oblivous request resource receives this request, selects the key 1270 it generated previously using the key identifier from the message, 1271 and decrypts the message. As this request is directed to the same 1272 server, the oblivious request resource does not need to initiate an 1273 HTTP request to the oblivious target resource. The request can be 1274 served directly by the oblivious target resource, which generates a 1275 minimal response (consisting of just a 200 status code) as follows: 1277 0140c8 1279 The response is constructed by extracting a secret from the HPKE 1280 context: 1282 9c0b96b577b9fc7a5beef536e0ff3a64 1284 The key derivation for the encapsulated response uses both the 1285 encapsulated KEM key from the request and a randomly selected nonce. 1286 This produces a salt of: 1288 cd7786fd75143f12e03398dbe2bcfa8e01a8132e7b66050674db72730623ca3b 1289 061d62d5df5832c6c9fa4617ceb848a7 1291 The salt and secret are both passed to the Extract function of the 1292 selected KDF (HKDF-SHA256) to produce a pseudorandom key of: 1294 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