idnits 2.17.1 draft-ietf-ohai-ohttp-01.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 (15 February 2022) is 802 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 358, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-binary-message-01 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'HPKE') -- Possible downref: Normative reference to a draft: ref. 'HTTP' ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-03) exists of draft-wood-key-consistency-01 == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-10 -- Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'ALT-SVC'. Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Oblivious HTTP Application Intermediation M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track C.A. Wood 5 Expires: 19 August 2022 Cloudflare 6 15 February 2022 8 Oblivious HTTP 9 draft-ietf-ohai-ohttp-01 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 About This Document 20 This note is to be removed before publishing as an RFC. 22 The latest revision of this draft can be found at https://ietf-wg- 23 ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html. Status 24 information for this document may be found at 25 https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/. 27 Discussion of this document takes place on the Oblivious HTTP 28 Application Intermediation Working Group mailing list 29 (mailto:ohai@ietf.org), which is archived at 30 https://mailarchive.ietf.org/arch/browse/ohai/. 32 Source for this draft and an issue tracker can be found at 33 https://github.com/ietf-wg-ohai/oblivious-http. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 19 August 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 8 73 4.2. Key Configuration Media Type . . . . . . . . . . . . . . 9 74 5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Encapsulation of Requests . . . . . . . . . . . . . . . . 11 76 5.2. Encapsulation of Responses . . . . . . . . . . . . . . . 12 77 6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Informational Responses . . . . . . . . . . . . . . . . . 15 79 6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 15 82 7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 16 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8.1. Client Responsibilities . . . . . . . . . . . . . . . . . 18 85 8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 19 86 8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 20 87 8.2.2. Linkability Through Traffic Analysis . . . . . . . . 20 88 8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 21 89 8.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 90 8.4.1. Use of Date for Anti-Replay . . . . . . . . . . . . . 23 91 8.5. Post-Compromise Security . . . . . . . . . . . . . . . . 23 92 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 93 10. Operational and Deployment Considerations . . . . . . . . . . 24 94 10.1. Performance Overhead . . . . . . . . . . . . . . . . . . 25 95 10.2. Resource Mappings . . . . . . . . . . . . . . . . . . . 25 96 10.3. Network Management . . . . . . . . . . . . . . . . . . . 25 98 11. Repurposing the Encapsulation Format . . . . . . . . . . . . 25 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 102 13.2. Informative References . . . . . . . . . . . . . . . . . 27 103 Appendix A. Complete Example of a Request and Response . . . . . 29 104 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 107 1. Introduction 109 The act of making a request using HTTP reveals information about the 110 client identity to a server. Though the content of requests might 111 reveal information, that is information under the control of the 112 client. In comparison, the source address on the connection reveals 113 information that a client has only limited control over. 115 Even where an IP address is not directly attributed to an individual, 116 the use of an address over time can be used to correlate requests. 117 Servers are able to use this information to assemble profiles of 118 client behavior, from which they can make inferences about the people 119 involved. The use of persistent connections to make multiple 120 requests improves performance, but provides servers with additional 121 certainty about the identity of clients in a similar fashion. 123 Use of an HTTP proxy can provide a degree of protection against 124 servers correlating requests. Systems like virtual private networks 125 or the Tor network [Dingledine2004], provide other options for 126 clients. 128 Though the overhead imposed by these methods varies, the cost for 129 each request is significant. Preventing request linkability requires 130 that each request use a completely new TLS connection to the server. 131 At a minimum, this requires an additional round trip to the server in 132 addition to that required by the request. In addition to having high 133 latency, there are significant secondary costs, both in terms of the 134 number of additional bytes exchanged and the CPU cost of 135 cryptographic computations. 137 This document describes a method of encapsulation for binary HTTP 138 messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). 139 This protects the content of both requests and responses and enables 140 a deployment architecture that can separate the identity of a 141 requester from the request. 143 Though this scheme requires that servers and proxies explicitly 144 support it, this design represents a performance improvement over 145 options that perform just one request in each connection. With 146 limited trust placed in the proxy (see Section 8), clients are 147 assured that requests are not uniquely attributed to them or linked 148 to other requests. 150 2. Conventions and Definitions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 Encapsulated Request: An HTTP request that is encapsulated in an 159 HPKE-encrypted message; see Section 5.1. 161 Encapsulated Response: An HTTP response that is encapsulated in an 162 HPKE-encrypted message; see Section 5.2. 164 Oblivious Proxy Resource: An intermediary that forwards requests and 165 responses between clients and a single oblivious request resource. 167 Oblivious Request Resource: A resource that can receive an 168 encapsulated request, extract the contents of that request, 169 forward it to an oblivious target resource, receive a response, 170 encapsulate that response, then return that response. 172 Oblivious Target Resource: The resource that is the target of an 173 encapsulated request. This resource logically handles only 174 regular HTTP requests and responses and so might be ignorant of 175 the use of oblivious HTTP to reach it. 177 This draft includes pseudocode that uses the functions and 178 conventions defined in [HPKE]. 180 Encoding an integer to a sequence of bytes in network byte order is 181 described using the function encode(n, v), where n is the number of 182 bytes and v is the integer value. The function len() returns the 183 length of a sequence of bytes. 185 Formats are described using notation from Section 1.3 of [QUIC]. 187 3. Overview 189 A client learns the following: 191 * The identity of an oblivious request resource. This might include 192 some information about oblivious target resources that the 193 oblivious request resource supports. 195 * The details of an HPKE public key that the oblivious request 196 resource accepts, including an identifier for that key and the 197 HPKE algorithms that are used with that key. 199 * The identity of an oblivious proxy resource that will forward 200 encapsulated requests and responses to a single oblivious request 201 resource. See Section 10.2 for more information about the mapping 202 between oblivious proxy and oblivious request resources. 204 This information allows the client to make a request of an oblivious 205 target resource without that resource having only a limited ability 206 to correlate that request with the client IP or other requests that 207 the client might make to that server. 209 +---------+ +----------+ +----------+ +----------+ 210 | Client | | Proxy | | Request | | Target | 211 | | | Resource | | Resource | | Resource | 212 +----+----+ +----+-----+ +----+-----+ +----+-----+ 213 | | | | 214 | Encapsulated | | | 215 | Request | | | 216 +---------------->| Encapsulated | | 217 | | Request | | 218 | +----------------->| Request | 219 | | +-------------->| 220 | | | | 221 | | | Response | 222 | | Encapsulated |<--------------+ 223 | | Response | | 224 | Encapsulated |<-----------------+ | 225 | Response | | | 226 |<----------------+ | | 227 | | | | 229 Figure 1: Overview of Oblivious HTTP 231 In order to make a request to an oblivious target resource, the 232 following steps occur, as shown in Figure 1: 234 1. The client constructs an HTTP request for an oblivious target 235 resource. 237 2. The client encodes the HTTP request in a binary HTTP message and 238 then encapsulates that message using HPKE and the process from 239 Section 5.1. 241 3. The client sends a POST request to the oblivious proxy resource 242 with the encapsulated request as the content of that message. 244 4. The oblivious proxy resource forwards this request to the 245 oblivious request resource. 247 5. The oblivious request resource receives this request and removes 248 the HPKE protection to obtain an HTTP request. 250 6. The oblivious request resource makes an HTTP request that 251 includes the target URI, method, fields, and content of the 252 request it acquires. 254 7. The oblivious target resource answers this HTTP request with an 255 HTTP response. 257 8. The oblivious request resource encapsulates the HTTP response 258 following the process in Section 5.2 and sends this in response 259 to the request from the oblivious proxy resource. 261 9. The oblivious proxy resource forwards this response to the 262 client. 264 10. The client removes the encapsulation to obtain the response to 265 the original request. 267 3.1. Applicability 269 Oblivious HTTP has limited applicability. Many uses of HTTP benefit 270 from being able to carry state between requests, such as with cookies 271 ([RFC6265]), authentication (Section 11 of [HTTP]), or even 272 alternative services ([RFC7838]). Oblivious HTTP seeks to prevent 273 this sort of linkage, which requires that applications not carry 274 state between requests. 276 Oblivious HTTP is primarily useful where privacy risks associated 277 with possible stateful treatment of requests are sufficiently 278 negative that the cost of deploying this protocol can be justified. 279 Oblivious HTTP is simpler and less costly than more robust systems, 280 like Prio ([PRIO]) or Tor ([Dingledine2004]), which can provide 281 stronger guarantees at higher operational costs. 283 Oblivious HTTP is more costly than a direct connection to a server. 284 Some costs, like those involved with connection setup, can be 285 amortized, but there are several ways in which oblivious HTTP is more 286 expensive than a direct request: 288 * Each oblivious request requires at least two regular HTTP 289 requests, which adds latency. 291 * Each request is expanded in size with additional HTTP fields, 292 encryption-related metadata, and AEAD expansion. 294 * Deriving cryptographic keys and applying them for request and 295 response protection takes non-negligible computational resources. 297 Examples of where preventing the linking of requests might justify 298 these costs include: 300 * DNS queries. DNS queries made to a recursive resolver reveal 301 information about the requester, particularly if linked to other 302 queries. 304 * Telemetry submission. Applications that submit reports about 305 their usage to their developers might use oblivious HTTP for some 306 types of moderately sensitive data. 308 These are examples of requests where there is information in a 309 request that - if it were connected to the identity of the user - 310 might allow a server to learn something about that user even if the 311 identity of the user is pseudonymous. Other examples include the 312 submission of anonymous surveys, making search queries, or requesting 313 location-specific content (such as retrieving tiles of a map 314 display). 316 4. Key Configuration 318 A client needs to acquire information about the key configuration of 319 the oblivious request resource in order to send encapsulated 320 requests. 322 In order to ensure that clients do not encapsulate messages that 323 other entities can intercept, the key configuration MUST be 324 authenticated and have integrity protection. 326 This document describes the "application/ohttp-keys" media type; see 327 Section 4.2. This media type might be used, for example with HTTPS, 328 as part of a system for configuring or discovering key 329 configurations. Note however that such a system needs to consider 330 the potential for key configuration to be used to compromise client 331 privacy; see Section 9. 333 Specifying a format for expressing the information a client needs to 334 construct an encapsulated request ensures that different client 335 implementations can be configured in the same way. This also enables 336 advertising key configurations in a consistent format. 338 A client might have multiple key configurations to select from when 339 encapsulating a request. Clients are responsible for selecting a 340 preferred key configuration from those it supports. Clients need to 341 consider both the key encapsulation method (KEM) and the combinations 342 of key derivation function (KDF) and authenticated encryption with 343 associated data (AEAD) in this decision. 345 Evolution of the key configuration format is supported through the 346 definition of new formats that are identified by new media types. 348 4.1. Key Configuration Encoding 350 A single key configuration consists of a key identifier, a public 351 key, an identifier for the KEM that the public key uses, and a set 352 HPKE symmetric algorithms. Each symmetric algorithm consists of an 353 identifier for a KDF and an identifier for an AEAD. 355 Figure 2 shows a single key configuration, KeyConfig, that is 356 expressed using the TLS syntax; see Section 3 of [TLS]. 358 opaque HpkePublicKey[Npk]; 359 uint16 HpkeKemId; 360 uint16 HpkeKdfId; 361 uint16 HpkeAeadId; 363 struct { 364 HpkeKdfId kdf_id; 365 HpkeAeadId aead_id; 366 } HpkeSymmetricAlgorithms; 368 struct { 369 uint8 key_id; 370 HpkeKemId kem_id; 371 HpkePublicKey public_key; 372 HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>; 373 } KeyConfig; 375 Figure 2: A Single Key Configuration 377 The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, 378 and AEAD respectively. The definitions for these identifiers and the 379 semantics of the algorithms they identify can be found in [HPKE]. 380 The Npk parameter corresponding to the HpkeKdfId can be found in 381 [HPKE]. 383 4.2. Key Configuration Media Type 385 The "application/ohttp-keys" format is a media type that identifies a 386 serialized collection of key configurations. The content of this 387 media type comprises one or more key configuration encodings (see 388 Section 4.1) that are concatenated. 390 Type name: application 392 Subtype name: ohttp-keys 394 Required parameters: N/A 396 Optional parameters: None 398 Encoding considerations: only "8bit" or "binary" is permitted 400 Security considerations: see Section 8 402 Interoperability considerations: N/A 404 Published specification: this specification 406 Applications that use this media type: N/A 408 Fragment identifier considerations: N/A 410 Additional information: Magic number(s): N/A 412 Deprecated alias names for this type: N/A 414 File extension(s): N/A 416 Macintosh file type code(s): N/A 418 Person and email address to contact for further information: see Aut 419 hors' Addresses section 421 Intended usage: COMMON 423 Restrictions on usage: N/A 425 Author: see Authors' Addresses section 427 Change controller: IESG 429 5. HPKE Encapsulation 431 HTTP message encapsulation uses HPKE for request and response 432 encryption. 434 An encapsulated HTTP request contains a binary-encoded HTTP message 435 [BINARY] and no other fields; see Figure 3. 437 Request { 438 Binary HTTP Message (..), 439 } 441 Figure 3: Plaintext Request Content 443 An Encapsulated Request is comprised of a length-prefixed key 444 identifier and a HPKE-protected request message. HPKE protection 445 includes an encapsulated KEM shared secret (or enc), plus the AEAD- 446 protected request message. An Encapsulated Request is shown in 447 Figure 4. Section 5.1 describes the process for constructing and 448 processing an Encapsulated Request. 450 Encapsulated Request { 451 Key Identifier (8), 452 KEM Identifier (16), 453 KDF Identifier (16), 454 AEAD Identifier (16), 455 Encapsulated KEM Shared Secret (8*Nenc), 456 AEAD-Protected Request (..), 457 } 459 Figure 4: Encapsulated Request 461 The Nenc parameter corresponding to the HpkeKdfId can be found in 462 Section 7.1 of [HPKE]. 464 An encapsulated HTTP response includes a binary-encoded HTTP message 465 [BINARY] and no other content; see Figure 5. 467 Response { 468 Binary HTTP Message (..), 469 } 471 Figure 5: Plaintext Response Content 473 Responses are bound to responses and so consist only of AEAD- 474 protected content. Section 5.2 describes the process for 475 constructing and processing an Encapsulated Response. 477 Encapsulated Response { 478 Nonce (Nk), 479 AEAD-Protected Response (..), 480 } 482 Figure 6: Encapsulated Response 484 The Nenc and Nk parameters corresponding to the HpkeKdfId can be 485 found in [HPKE]. Nenc refers to the size of the encapsulated KEM 486 shared secret, in bytes; Nk refers to the size of the AEAD key for 487 the HPKE ciphersuite, in bits. 489 5.1. Encapsulation of Requests 491 Clients encapsulate a request request using values from a key 492 configuration: 494 * the key identifier from the configuration, keyID, with the 495 corresponding KEM identified by kemID, 497 * the public key from the configuration, pkR, and 499 * a selected combination of KDF, identified by kdfID, and AEAD, 500 identified by aeadID. 502 The client then constructs an encapsulated request, enc_request, from 503 a binary encoded HTTP request, request, as follows: 505 1. Compute an HPKE context using pkR and a label of "message/bhttp 506 request", yielding context and encapsulation key enc. 508 2. Construct associated data, aad, by concatenating the values of 509 keyID, kemID, kdfID, and aeadID, as one 8-bit integer and three 510 16-bit integers, respectively, each in network byte order. 512 3. Encrypt (seal) request with aad as associated data using context, 513 yielding ciphertext ct. 515 4. Concatenate the values of aad, enc, and ct, yielding an 516 Encapsulated Request enc_request. 518 Note that enc is of fixed-length, so there is no ambiguity in parsing 519 this structure. 521 In pseudocode, this procedure is as follows: 523 enc, context = SetupBaseS(pkR, "message/bhttp request") 524 aad = concat(encode(1, keyID), 525 encode(2, kemID), 526 encode(2, kdfID), 527 encode(2, aeadID)) 528 ct = context.Seal(aad, request) 529 enc_request = concat(aad, enc, ct) 531 Servers decrypt an Encapsulated Request by reversing this process. 532 Given an Encapsulated Request enc_request, a server: 534 1. Parses enc_request into keyID, kemID, kdfID, aeadID, enc, and ct 535 (indicated using the function parse() in pseudocode). The server 536 is then able to find the HPKE private key, skR, corresponding to 537 keyID. 539 a. If keyID does not identify a key matching the type of kemID, 540 the server returns an error. 542 b. If kdfID and aeadID identify a combination of KDF and AEAD 543 that the server is unwilling to use with skR, the server returns 544 an error. 546 2. Compute an HPKE context using skR, a label of "message/bhttp 547 request", and the encapsulated key enc, yielding context. 549 3. Construct additional associated data, aad, from keyID, kemID, 550 kdfID, and aeadID or as the first seven bytes of enc_request. 552 4. Decrypt ct using aad as associated data, yielding request or an 553 error on failure. If decryption fails, the server returns an 554 error. 556 In pseudocode, this procedure is as follows: 558 keyID, kemID, kdfID, aeadID, enc, ct = parse(enc_request) 559 aad = concat(encode(1, keyID), 560 encode(2, kemID), 561 encode(2, kdfID), 562 encode(2, aeadID)) 563 context = SetupBaseR(enc, skR, "message/bhttp request") 564 request, error = context.Open(aad, ct) 566 5.2. Encapsulation of Responses 568 Given an HPKE context context, a request message request, and a 569 response response, servers generate an Encapsulated Response 570 enc_response as follows: 572 1. Export a secret secret from context, using the string "message/ 573 bhttp response" as context. The length of this secret is max(Nn, 574 Nk), where Nn and Nk are the length of AEAD key and nonce 575 associated with context. 577 2. Generate a random value of length max(Nn, Nk) bytes, called 578 response_nonce. 580 3. Extract a pseudorandom key prk using the Extract function 581 provided by the KDF algorithm associated with context. The ikm 582 input to this function is secret; the salt input is the 583 concatenation of enc (from enc_request) and response_nonce 585 4. Use the Expand function provided by the same KDF to extract an 586 AEAD key key, of length Nk - the length of the keys used by the 587 AEAD associated with context. Generating key uses a label of 588 "key". 590 5. Use the same Expand function to extract a nonce nonce of length 591 Nn - the length of the nonce used by the AEAD. Generating nonce 592 uses a label of "nonce". 594 6. Encrypt response, passing the AEAD function Seal the values of 595 key, nonce, empty aad, and a pt input of request, which yields 596 ct. 598 7. Concatenate response_nonce and ct, yielding an Encapsulated 599 Response enc_response. Note that response_nonce is of fixed- 600 length, so there is no ambiguity in parsing either response_nonce 601 or ct. 603 In pseudocode, this procedure is as follows: 605 secret = context.Export("message/bhttp response", Nk) 606 response_nonce = random(max(Nn, Nk)) 607 salt = concat(enc, response_nonce) 608 prk = Extract(salt, secret) 609 aead_key = Expand(prk, "key", Nk) 610 aead_nonce = Expand(prk, "nonce", Nn) 611 ct = Seal(aead_key, aead_nonce, "", response) 612 enc_response = concat(response_nonce, ct) 614 Clients decrypt an Encapsulated Request by reversing this process. 615 That is, they first parse enc_response into response_nonce and ct. 616 They then follow the same process to derive values for aead_key and 617 aead_nonce. 619 The client uses these values to decrypt ct using the Open function 620 provided by the AEAD. Decrypting might produce an error, as follows: 622 reponse, error = Open(aead_key, aead_nonce, "", ct) 624 6. HTTP Usage 626 A client interacts with the oblivious proxy resource by constructing 627 an encapsulated request. This encapsulated request is included as 628 the content of a POST request to the oblivious proxy resource. This 629 request MUST only contain those fields necessary to carry the 630 encapsulated request: a method of POST, a target URI of the oblivious 631 proxy resource, a header field containing the content type (see 632 (Section 7), and the encapsulated request as the request content. 633 Clients MAY include fields that do not reveal information about the 634 content of the request, such as Alt-Used [ALT-SVC], or information 635 that it trusts the oblivious proxy resource to remove, such as fields 636 that are listed in the Connection header field. 638 The oblivious proxy resource interacts with the oblivious request 639 resource by constructing a request using the same restrictions as the 640 client request, except that the target URI is the oblivious request 641 resource. The content of this request is copied from the client. 642 The oblivious proxy resource MUST NOT add information about the 643 client to this request. 645 When a response is received from the oblivious request resource, the 646 oblivious proxy resource forwards the response according to the rules 647 of an HTTP proxy; see Section 7.6 of [HTTP]. 649 An oblivious request resource, if it receives any response from the 650 oblivious target resource, sends a single 200 response containing the 651 encapsulated response. Like the request from the client, this 652 response MUST only contain those fields necessary to carry the 653 encapsulated response: a 200 status code, a header field indicating 654 the content type, and the encapsulated response as the response 655 content. As with requests, additional fields MAY be used to convey 656 information that does not reveal information about the encapsulated 657 response. 659 An oblivious request resource acts as a gateway for requests to the 660 oblivious target resource (see Section 7.6 of [HTTP]). The one 661 exception is that any information it might forward in a response MUST 662 be encapsulated, unless it is responding to errors it detects before 663 removing encapsulation of the request; see Section 6.2. 665 6.1. Informational Responses 667 This encapsulation does not permit progressive processing of 668 responses. Though the binary HTTP response format does support the 669 inclusion of informational (1xx) status codes, the AEAD encapsulation 670 cannot be removed until the entire message is received. 672 In particular, the Expect header field with 100-continue (see 673 Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct 674 a request that includes a 100-continue expectation; the oblivious 675 request resource MUST generate an error if a 100-continue expectation 676 is received. 678 6.2. Errors 680 A server that receives an invalid message for any reason MUST 681 generate an HTTP response with a 4xx status code. 683 Errors detected by the oblivious proxy resource and errors detected 684 by the oblivious request resource before removing protection 685 (including being unable to remove encapsulation for any reason) 686 result in the status code being sent without protection in response 687 to the POST request made to that resource. 689 Errors detected by the oblivious request resource after successfully 690 removing encapsulation and errors detected by the oblivious target 691 resource MUST be sent in an encapsulated response. 693 7. Media Types 695 Media types are used to identify encapsulated requests and responses. 697 Evolution of the format of encapsulated requests and responses is 698 supported through the definition of new formats that are identified 699 by new media types. 701 7.1. message/ohttp-req Media Type 703 The "message/ohttp-req" identifies an encapsulated binary HTTP 704 request. This is a binary format that is defined in Section 5.1. 706 Type name: message 708 Subtype name: ohttp-req 710 Required parameters: N/A 712 Optional parameters: None 713 Encoding considerations: only "8bit" or "binary" is permitted 715 Security considerations: see Section 8 717 Interoperability considerations: N/A 719 Published specification: this specification 721 Applications that use this media type: N/A 723 Fragment identifier considerations: N/A 725 Additional information: Magic number(s): N/A 727 Deprecated alias names for this type: N/A 729 File extension(s): N/A 731 Macintosh file type code(s): N/A 733 Person and email address to contact for further information: see Aut 734 hors' Addresses section 736 Intended usage: COMMON 738 Restrictions on usage: N/A 740 Author: see Authors' Addresses section 742 Change controller: IESG 744 7.2. message/ohttp-res Media Type 746 The "message/ohttp-res" identifies an encapsulated binary HTTP 747 response. This is a binary format that is defined in Section 5.2. 749 Type name: message 751 Subtype name: ohttp-res 753 Required parameters: N/A 755 Optional parameters: None 757 Encoding considerations: only "8bit" or "binary" is permitted 759 Security considerations: see Section 8 760 Interoperability considerations: N/A 762 Published specification: this specification 764 Applications that use this media type: N/A 766 Fragment identifier considerations: N/A 768 Additional information: Magic number(s): N/A 770 Deprecated alias names for this type: N/A 772 File extension(s): N/A 774 Macintosh file type code(s): N/A 776 Person and email address to contact for further information: see Aut 777 hors' Addresses section 779 Intended usage: COMMON 781 Restrictions on usage: N/A 783 Author: see Authors' Addresses section 785 Change controller: IESG 787 8. Security Considerations 789 In this design, a client wishes to make a request of a server that is 790 authoritative for the oblivious target resource. The client wishes 791 to make this request without linking that request with either: 793 1. The identity at the network and transport layer of the client 794 (that is, the client IP address and TCP or UDP port number the 795 client uses to create a connection). 797 2. Any other request the client might have made in the past or might 798 make in the future. 800 In order to ensure this, the client selects a proxy (that serves the 801 oblivious proxy resource) that it trusts will protect this 802 information by forwarding the encapsulated request and response 803 without passing the server (that serves the oblivious request 804 resource). 806 In this section, a deployment where there are three entities is 807 considered: 809 * A client makes requests and receives responses 811 * A proxy operates the oblivious proxy resource 813 * A server operates both the oblivious request resource and the 814 oblivious target resource 816 To achieve the stated privacy goals, the oblivious proxy resource 817 cannot be operated by the same entity as the oblivious request 818 resource. However, colocation of the oblivious request resource and 819 oblivious target resource simplifies the interactions between those 820 resources without affecting client privacy. 822 As a consequence of this configuration, Oblivious HTTP prevents 823 linkability described above. Informally, this means: 825 1. Requests and responses are known only to clients and targets in 826 possession of the corresponding response encapsulation key and 827 HPKE keying material. In particular, the oblivious proxy knows 828 the origin and destination of an encapsulated request and 829 response, yet does not know the decapsulated contents. Likewise, 830 targets know only the oblivious request origin, i.e., the proxy, 831 and the decapsulated request. Only the client knows both the 832 plaintext request and response. 834 2. Targets cannot link requests from the same client in the absence 835 of unique per-client keys. 837 Traffic analysis that might affect these properties are outside the 838 scope of this document; see Section 8.2.2. 840 A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS]. 842 8.1. Client Responsibilities 844 Clients MUST ensure that the key configuration they select for 845 generating encapsulated requests is integrity protected and 846 authenticated so that it can be attributed to the oblivious request 847 resource; see Section 4. 849 Since clients connect directly to the proxy instead of the target, 850 application configurations wherein clients make policy decisions 851 about target connections, e.g., to apply certificate pinning, are 852 incompatible with Oblivious HTTP. In such cases, alternative 853 technologies such as HTTP CONNECT (Section 9.3.6 of [HTTP]) can be 854 used. Applications could implement related policies on key 855 configurations and proxy connections, though these might not provide 856 the same properties as policies enforced directly on target 857 connections. When this difference is relevant, applications can 858 instead connect directly to the target at the cost of either privacy 859 or performance. 861 Clients MUST NOT include identifying information in the request that 862 is encapsulated. Identifying information includes cookies [COOKIES], 863 authentication credentials or tokens, and any information that might 864 reveal client-specific information such as account credentials. 866 Clients cannot carry connection-level state between requests as they 867 only establish direct connections to the proxy responsible for the 868 oblivious proxy resource. However, clients need to ensure that they 869 construct requests without any information gained from previous 870 requests. Otherwise, the server might be able to use that 871 information to link requests. Cookies [COOKIES] are the most obvious 872 feature that MUST NOT be used by clients. However, clients need to 873 include all information learned from requests, which could include 874 the identity of resources. 876 Clients MUST generate a new HPKE context for every request, using a 877 good source of entropy ([RANDOM]) for generating keys. Key reuse not 878 only risks requests being linked, reuse could expose request and 879 response contents to the proxy. 881 The request the client sends to the oblivious proxy resource only 882 requires minimal information; see Section 6. The request that 883 carries the encapsulated request and is sent to the oblivious proxy 884 resource MUST NOT include identifying information unless the client 885 ensures that this information is removed by the proxy. A client MAY 886 include information only for the oblivious proxy resource in header 887 fields identified by the Connection header field if it trusts the 888 proxy to remove these as required by Section 7.6.1 of [HTTP]. The 889 client needs to trust that the proxy does not replicate the source 890 addressing information in the request it forwards. 892 Clients rely on the oblivious proxy resource to forward encapsulated 893 requests and responses. However, the proxy can only refuse to 894 forward messages, it cannot inspect or modify the contents of 895 encapsulated requests or responses. 897 8.2. Proxy Responsibilities 899 The proxy that serves the oblivious proxy resource has a very simple 900 function to perform. For each request it receives, it makes a 901 request of the oblivious request resource that includes the same 902 content. When it receives a response, it sends a response to the 903 client that includes the content of the response from the oblivious 904 request resource. When generating a request, the proxy MUST follow 905 the forwarding rules in Section 7.6 of [HTTP]. 907 A proxy can also generate responses, though it assumed to not be able 908 to examine the content of a request (other than to observe the choice 909 of key identifier, KDF, and AEAD), so it is also assumed that it 910 cannot generate an encapsulated response. 912 A proxy MUST NOT add information about the client identity when 913 forwarding requests. This includes the Via field, the Forwarded 914 field [FORWARDED], and any similar information. A client does not 915 depend on the proxy using an authenticated and encrypted connection 916 to the oblivious request resource, only that information about the 917 client not be attached to forwarded requests. 919 8.2.1. Denial of Service 921 As there are privacy benefits from having a large rate of requests 922 forwarded by the same proxy (see Section 8.2.2), servers that operate 923 the oblivious request resource might need an arrangement with 924 proxies. This arrangement might be necessary to prevent having the 925 large volume of requests being classified as an attack by the server. 927 If a server accepts a larger volume of requests from a proxy, it 928 needs to trust that the proxy does not allow abusive levels of 929 request volumes from clients. That is, if a server allows requests 930 from the proxy to be exempt from rate limits, the server might want 931 to ensure that the proxy applies a rate limiting policy that is 932 acceptable to the server. 934 Servers that enter into an agreement with a proxy that enables a 935 higher request rate might choose to authenticate the proxy to enable 936 the higher rate. 938 8.2.2. Linkability Through Traffic Analysis 940 As the time at which encapsulated request or response messages are 941 sent can reveal information to a network observer. Though messages 942 exchanged between the oblivious proxy resource and the oblivious 943 request resource might be sent in a single connection, traffic 944 analysis could be used to match messages that are forwarded by the 945 proxy. 947 A proxy could, as part of its function, add delays in order to 948 increase the anonymity set into which each message is attributed. 949 This could latency to the overall time clients take to receive a 950 response, which might not be what some clients want. 952 A proxy can use padding to reduce the effectiveness of traffic 953 analysis. Padding is a capability provided by binary HTTP messages; 954 see Section 3.8 of [BINARY]. 956 A proxy that forwards large volumes of exchanges can provide better 957 privacy by providing larger sets of messages that need to be matched. 959 8.3. Server Responsibilities 961 A server that operates both oblivious request and oblivious target 962 resources is responsible for removing request encapsulation, 963 generating a response the encapsulated request, and encapsulating the 964 response. 966 Servers should account for traffic analysis based on response size or 967 generation time. Techniques such as padding or timing delays can 968 help protect against such attacks; see Section 8.2.2. 970 If separate entities provide the oblivious request resource and 971 oblivious target resource, these entities might need an arrangement 972 similar to that between server and proxy for managing denial of 973 service; see Section 8.2.1. It is also necessary to provide 974 confidentiality protection for the unprotected requests and 975 responses, plus protections for traffic analysis; see Section 8.2.2. 977 An oblivious request resource needs to have a plan for replacing 978 keys. This might include regular replacement of keys, which can be 979 assigned new key identifiers. If an oblivious request resource 980 receives a request that contains a key identifier that it does not 981 understand or that corresponds to a key that has been replaced, the 982 server can respond with an HTTP 422 (Unprocessable Content) status 983 code. 985 A server can also use a 422 status code if the server has a key that 986 corresponds to the key identifier, but the encapsulated request 987 cannot be successfully decrypted using the key. 989 A server MUST ensure that the HPKE keys it uses are not valid for any 990 other protocol that uses HPKE with the "message/bhttp request" label. 991 Designers of protocols that reuse this encapsulation format, 992 especially new versions of this protocol, can ensure key diversity by 993 choosing a different label in their use of HPKE. The "message/bhttp 994 response" label was chosen for symmetry only as it provides key 995 diversity only within the HPKE context created using the "message/ 996 bhttp request" label; see Section 11. 998 A server is responsible for either rejecting replayed requests or 999 ensuring that the effect of replays does not adversely affect clients 1000 or resources; see Section 8.4. 1002 8.4. Replay Attacks 1004 Encapsulated requests can be copied and replayed by the oblivious 1005 proxy resource. The design of oblivious HTTP does not assume that 1006 the oblivious proxy resource will not replay requests. In addition, 1007 if a client sends an encapsulated request in TLS early data (see 1008 Section 8 of [TLS] and [RFC8470]), a network-based adversary might be 1009 able to cause the request to be replayed. In both cases, the effect 1010 of a replay attack and the mitigations that might be employed are 1011 similar to TLS early data. 1013 A client or oblivious proxy resource MUST NOT automatically attempt 1014 to retry a failed request unless it receives a positive signal 1015 indicating that the request was not processed or forwarded. The 1016 HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [RFC7540]), the 1017 HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [QUIC-HTTP]), 1018 or a GOAWAY frame with a low enough identifier (in either protocol 1019 version) are all sufficient signals that no processing occurred. 1020 Connection failures or interruptions are not sufficient signals that 1021 no processing occurred. 1023 The anti-replay mechanisms described in Section 8 of [TLS] are 1024 generally applicable to oblivious HTTP requests. The encapsulated 1025 keying material (or enc) can be used in place of a nonce to uniquely 1026 identify a request. This value is a high-entropy value that is 1027 freshly generated for every request, so two valid requests will have 1028 different values with overwhelming probability. 1030 The mechanism used in TLS for managing differences in client and 1031 server clocks cannot be used as it depends on being able to observe 1032 previous interactions. Oblivious HTTP explicitly prevents such 1033 linkability. 1035 The considerations in [RFC8470] as they relate to managing the risk 1036 of replay also apply, though there is no option to delay the 1037 processing of a request. 1039 Limiting requests to those with safe methods might not be 1040 satisfactory for some applications, particularly those that involve 1041 the submission of data to a server. The use of idempotent methods 1042 might be of some use in managing replay risk, though it is important 1043 to recognize that different idempotent requests can be combined to be 1044 not idempotent. 1046 Even without replay prevention, the server-chosen response_nonce 1047 field ensures that responses have unique AEAD keys and nonces even 1048 when requests are replayed. 1050 8.4.1. Use of Date for Anti-Replay 1052 Clients SHOULD include a Date header field in encapsulated requests. 1053 Though HTTP requests often do not include a Date header field, the 1054 value of this field might be used by a server to limit the amount of 1055 requests it needs to track when preventing replays. 1057 A server can maintain state for requests for a small window of time 1058 over which it wishes to accept requests. The server then rejects 1059 requests if the request is the same as one that was previously 1060 answered within that time window. Servers can reject requests 1061 outside of this window and signal that clients might retry with a 1062 different Date header field; see Section 4 of [REQUEST-DATE]. 1063 Servers can identify duplicate requests using the encapsulation (enc) 1064 value. 1066 Servers SHOULD allow for the time it takes requests to arrive from 1067 the client, with a time window that is large enough to allow for 1068 differences in the clock of clients and servers. How large a time 1069 window is needed could depend on the population of clients that the 1070 server needs to serve. 1072 Servers MUST NOT treat the time window as secret information. An 1073 attacker can actively probe the server with specially crafted request 1074 timestamps to determine the time window over which the server will 1075 accept responses. 1077 [REQUEST-DATE] contains further considerations for the use of the 1078 Date request header field. This includes the way in which clients 1079 might correct for clock skew and the privacy considerations arising 1080 from that usage. Servers that reject requests on the basis of the 1081 Date request header field SHOULD implement the feedback mechanism in 1082 Section 4 of [REQUEST-DATE] to support clock correction by clients. 1084 8.5. Post-Compromise Security 1086 This design does not provide post-compromise security for responses. 1088 A client only needs to retain keying material that might be used 1089 compromise the confidentiality and integrity of a response until that 1090 response is consumed, so there is negligible risk associated with a 1091 client compromise. 1093 A server retains a secret key that might be used to remove protection 1094 from messages over much longer periods. A server compromise that 1095 provided access to the oblivious request resource secret key could 1096 allow an attacker to recover the plaintext of all requests sent 1097 toward affected keys and all of the responses that were generated. 1099 Even if server keys are compromised, an adversary cannot access 1100 messages exchanged by the client with the oblivious proxy resource as 1101 messages are protected by TLS. Use of a compromised key also 1102 requires that the oblivious proxy resource cooperate with the 1103 attacker or that the attacker is able to compromise these TLS 1104 connections. 1106 The total number of affected messages affected by server key 1107 compromise can be limited by regular rotation of server keys. 1109 9. Privacy Considerations 1111 One goal of this design is that independent client requests are only 1112 linkable by the chosen key configuration. The oblivious proxy and 1113 request resources can link requests using the same key configuration 1114 by matching KeyConfig.key_id, or, if the oblivious target resource is 1115 willing to use trial decryption, a limited set of key configurations 1116 that share an identifier. An oblivious proxy can link requests using 1117 the public key corresponding to KeyConfig.key_id. 1119 Request resources are capable of linking requests depending on how 1120 KeyConfigs are produced by servers and discovered by clients. 1121 Specifically, servers can maliciously construct key configurations to 1122 track individual clients. A specific method for a client to acquire 1123 key configurations is not included in this specification. Clients 1124 need to consider these tracking vectors when choosing a discovery 1125 method. Applications using this design should provide accommodations 1126 to mitigate tracking using key configurations. [CONSISTENCY] 1127 provides an analysis of the options for ensuring the key 1128 configurations are consistent between different clients. 1130 10. Operational and Deployment Considerations 1132 This section discusses various operational and deployment 1133 considerations. 1135 10.1. Performance Overhead 1137 Using Oblivious HTTP adds both cryptographic and latency to requests 1138 relative to a simple HTTP request-response exchange. Deploying proxy 1139 services that are on path between clients and servers avoids adding 1140 significant additional delay due to network topology. A study of a 1141 similar system [ODoH] found that deploying proxies close to servers 1142 was most effective in minimizing additional latency. 1144 10.2. Resource Mappings 1146 This protocol assumes a fixed, one-to-one mapping between the 1147 Oblivious Proxy Resource and the Oblivious Request Resource. This 1148 means that any encapsulated request sent to the Oblivious Proxy 1149 Resource will always be forwarded to the Oblivious Request Resource. 1150 This constraint was imposed to simplify proxy configuration and 1151 mitigate against the Oblivious Proxy Resource being used as a generic 1152 proxy for unknown Oblivious Request Resources. The proxy will only 1153 forward for Oblivious Request Resources that it has explicitly 1154 configured and allowed. 1156 It is possible for a server to be configured with multiple Oblivious 1157 Proxy Resources, each for a different Oblivious Request Resource as 1158 needed. 1160 10.3. Network Management 1162 Oblivious HTTP might be incompatible with network interception 1163 regimes, such as those that rely on configuring clients with trust 1164 anchors and intercepting TLS connections. While TLS might be 1165 intercepted successfully, interception middleboxes devices might not 1166 receive updates that would allow Oblivious HTTP to be correctly 1167 identified using the media types defined in Section 7. 1169 Oblivious HTTP has a simple key management design that is not 1170 trivially altered to enable interception by intermediaries. Clients 1171 that are configured to enable interception might choose to disable 1172 Oblivious HTTP in order to ensure that content is accessible to 1173 middleboxes. 1175 11. Repurposing the Encapsulation Format 1177 The encapsulated payload of an OHTTP request and response is a binary 1178 HTTP message [BINARY]. Client and target agree on this encapsulated 1179 payload type by specifying the media type "message/bhttp" in the HPKE 1180 encapsulation info string and HPKE export context string for request 1181 and response encapsulation, respectively. 1183 Future specifications may repurpose the encapsulation mechanism 1184 described in Section 5, provided that the content type of the 1185 encapsulated payload is appropriately reflected in the HPKE info and 1186 context strings. For example, if a future specification were to use 1187 the encapsulation mechanism in this specification for DNS messages, 1188 identified by the "application/dns-message" media type, then the HPKE 1189 info string SHOULD be "application/dns-message request" for request 1190 encapsulation, and the HPKE export context string should be 1191 "application/dns-message response" for response encapsulation. 1193 12. IANA Considerations 1195 Please update the "Media Types" registry at 1196 https://www.iana.org/assignments/media-types 1197 (https://www.iana.org/assignments/media-types) with the registration 1198 information in Section 7 for the media types "message/ohttp-req", 1199 "message/ohttp-res", and "application/ohttp-keys". 1201 13. References 1203 13.1. Normative References 1205 [BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP 1206 Messages", Work in Progress, Internet-Draft, draft-ietf- 1207 httpbis-binary-message-01, 3 February 2022, 1208 . 1211 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 1212 "Hybrid Public Key Encryption", Work in Progress, 1213 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 1214 . 1217 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1218 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1219 httpbis-semantics-19, 12 September 2021, 1220 . 1223 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1224 Multiplexed and Secure Transport", RFC 9000, 1225 DOI 10.17487/RFC9000, May 2021, 1226 . 1228 [QUIC-HTTP] 1229 Bishop, M., "Hypertext Transfer Protocol Version 3 1230 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1231 quic-http-34, 2 February 2021, 1232 . 1235 [REQUEST-DATE] 1236 Thomson, M., "Using The Date Header Field In HTTP 1237 Requests", Work in Progress, Internet-Draft, draft- 1238 thomson-httpapi-date-requests-00, 8 February 2022, 1239 . 1242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1243 Requirement Levels", BCP 14, RFC 2119, 1244 DOI 10.17487/RFC2119, March 1997, 1245 . 1247 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1248 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1249 DOI 10.17487/RFC7540, May 2015, 1250 . 1252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1254 May 2017, . 1256 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 1257 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 1258 2018, . 1260 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1261 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1262 . 1264 13.2. Informative References 1266 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1267 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1268 April 2016, . 1270 [CONSISTENCY] 1271 Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, 1272 "Key Consistency and Discovery", Work in Progress, 1273 Internet-Draft, draft-wood-key-consistency-01, 19 August 1274 2021, . 1277 [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1278 DOI 10.17487/RFC6265, April 2011, 1279 . 1281 [Dingledine2004] 1282 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The 1283 Second-Generation Onion Router", August 2004, 1284 . 1287 [FORWARDED] 1288 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1289 RFC 7239, DOI 10.17487/RFC7239, June 2014, 1290 . 1292 [ODoH] Singanamalla, S., Chunhapanya, S., Vavrusa, M., Verma, T., 1293 Wu, P., Fayed, M., Heimerl, K., Sullivan, N., and C. A. 1294 Wood, "Oblivious DNS over HTTPS (ODoH): A Practical 1295 Privacy Enhancement to DNS", 7 January 2021, 1296 . 1299 [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 1300 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 1301 Internet-Draft, draft-pauly-dprive-oblivious-doh-10, 31 1302 January 2022, . 1305 [OHTTP-ANALYSIS] 1306 Hoyland, J., "Tamarin Model of Oblivious HTTP", 23 August 1307 2021, . 1309 [PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust, 1310 and Scalable Computation of Aggregate Statistics", 14 1311 March 2017, . 1313 [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1314 "Randomness Requirements for Security", BCP 106, RFC 4086, 1315 DOI 10.17487/RFC4086, June 2005, 1316 . 1318 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1319 DOI 10.17487/RFC6265, April 2011, 1320 . 1322 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1323 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1324 April 2016, . 1326 [X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1327 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1328 2016, . 1330 Appendix A. Complete Example of a Request and Response 1332 A single request and response exchange is shown here. Binary values 1333 (key configuration, secret keys, the content of messages, and 1334 intermediate values) are shown in hexadecimal. The request and 1335 response here are absolutely minimal; the purpose of this example is 1336 to show the cryptographic operations. 1338 The oblivious request resource generates a key pair. In this example 1339 the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 1340 key pair [X25519]. The X25519 secret key is: 1342 b8f3cea0da634e6b8271f5b8f931d266decdd04c8e09b80cb9878ea90086ed4a 1344 The oblivious request resource constructs a key configuration that 1345 includes the corresponding public key as follows: 1347 01002076eae6d5a6c1549a3343d31c0b9b9582470c72ca11607d47f005f8c16b 1348 e3304a00080001000100010003 1350 This key configuration is somehow obtained by the client. Then when 1351 a client wishes to send an HTTP request of a GET request to 1352 https://example.com, it constructs the following binary HTTP message: 1354 00034745540568747470730b6578616d706c652e636f6d012f 1356 The client then reads the oblivious request resource key 1357 configuration and selects a mutually supported KDF and AEAD. In this 1358 example, the client selects HKDF-SHA256 and AES-128-GCM. The client 1359 then generates an HPKE context that uses the server public key. This 1360 context is constructed from the following ephemeral public key: 1362 25845c6ed6802abfd09628b5c677842b10dd53a3aad5775aa3c20cbae1c0cb65 1364 The corresponding private key is: 1366 88894d1fb4e76e215d9d9c87c44d9e0a6053c1c84c836a4106ea547344504658 1368 Applying the Seal operation from the HPKE context produces an 1369 encrypted message, allowing the client to construct the following 1370 encapsulated request: 1372 010020000100012485c2eee03135aac82e572d51639b2e141102c431d544e346 1373 0a0784a908b41b676943ae0b3ed8eff581ee8be5f47303a314de092e2e27e3f0 1374 2a03b9357de1d414cadacabaa1621cf9 1376 The client then sends this to the oblivious proxy resource in a POST 1377 request, which might look like the following HTTP/1.1 request: 1379 POST /request.example.net/proxy HTTP/1.1 1380 Host: proxy.example.org 1381 Content-Type: message/ohttp-req 1382 Content-Length: 78 1384 1386 The oblivious proxy resource receives this request and forwards it to 1387 the oblivious request resource, which might look like: 1389 POST /oblivious/request HTTP/1.1 1390 Host: example.com 1391 Content-Type: message/ohttp-req 1392 Content-Length: 78 1394 1396 The oblivous request resource receives this request, selects the key 1397 it generated previously using the key identifier from the message, 1398 and decrypts the message. As this request is directed to the same 1399 server, the oblivious request resource does not need to initiate an 1400 HTTP request to the oblivious target resource. The request can be 1401 served directly by the oblivious target resource, which generates a 1402 minimal response (consisting of just a 200 status code) as follows: 1404 0140c8 1406 The response is constructed by extracting a secret from the HPKE 1407 context: 1409 50030a0eacaa9c020e60390c573c4f80 1411 The key derivation for the encapsulated response uses both the 1412 encapsulated KEM key from the request and a randomly selected nonce. 1413 This produces a salt of: 1415 2485c2eee03135aac82e572d51639b2e141102c431d544e3460a0784a908b41b 1416 e29f9834fd61ffa27f494dfea94d9ed5 1418 The salt and secret are both passed to the Extract function of the 1419 selected KDF (HKDF-SHA256) to produce a pseudorandom key of: 1421 4fd8939221446411c785dc9dc51a196df43646a7791919248d0c7624c9410e5b 1423 The pseudorandom key is used with the Expand function of the KDF and 1424 an info field of "key" to produce a 16-byte key for the selected AEAD 1425 (AES-128-GCM): 1427 a0cd40e2e68cd500bfd14275b290f337 1429 With the same KDF and pseudorandom key, an info field of "nonce" is 1430 used to generate a 12-byte nonce: 1432 86883bbe97a380ec2fa656f7 1434 The AEAD Seal function is then used to encrypt the response, which is 1435 added to the randomized nonce value to produce the encapsulated 1436 response: 1438 e29f9834fd61ffa27f494dfea94d9ed543d89abe34977e7d6d5e1d8051e7b3ba 1439 4ff234 1441 The oblivious request resource then constructs a response: 1443 HTTP/1.1 200 OK 1444 Date: Wed, 27 Jan 2021 04:45:07 GMT 1445 Cache-Control: private, no-store 1446 Content-Type: message/ohttp-res 1447 Content-Length: 38 1449 1451 The same response might then be generated by the oblivious proxy 1452 resource which might change as little as the Date header. The client 1453 is then able to use the HPKE context it created and the nonce from 1454 the encapsulated response to construct the AEAD key and nonce and 1455 decrypt the response. 1457 Acknowledgments 1459 This design is based on a design for oblivious DoH, described in 1460 [ODOH]. David Benjamin and Eric Rescorla made technical 1461 contributions. 1463 Authors' Addresses 1465 Martin Thomson 1466 Mozilla 1468 Email: mt@lowentropy.net 1469 Christopher A. Wood 1470 Cloudflare 1472 Email: caw@heapingbits.net