idnits 2.17.1 draft-thomson-http-oblivious-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 January 2021) is 1183 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) -- No information found for draft-ietf-http-binary-message-latest - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BINARY' == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-07 ** 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-14 -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-04 Summary: 1 error (**), 0 flaws (~~), 4 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: 1 August 2021 Cloudflare 6 28 January 2021 8 Oblivious HTTP 9 draft-thomson-http-oblivious-00 11 Abstract 13 This document describes a system for the forwarding of encrypted HTTP 14 messages. This allows clients to make requests of servers without 15 the server being able to link requests to other requests from the 16 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 1 August 2021. 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 4. Key Configuration . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Key Configuration Encoding . . . . . . . . . . . . . . . 7 67 4.2. Key Configuration Media Type . . . . . . . . . . . . . . 7 68 5. HPKE Encapsulation . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. HPKE Encapsulation of Requests . . . . . . . . . . . . . 9 70 5.2. HPKE Encapsulation of Responses . . . . . . . . . . . . . 11 71 6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.1. Informational Responses . . . . . . . . . . . . . . . . . 13 73 6.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. message/ohttp-req Media Type . . . . . . . . . . . . . . 14 76 7.2. message/ohttp-res Media Type . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.2. Proxy Responsibilities . . . . . . . . . . . . . . . . . 17 80 8.2.1. Denial of Service . . . . . . . . . . . . . . . . . . 18 81 8.2.2. Linkability Through Traffic Analysis . . . . . . . . 18 82 8.3. Server Responsibilities . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 10.2. Informative References . . . . . . . . . . . . . . . . . 20 87 Appendix A. Complete Example of a Request and Response . . . . . 21 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 The act of making a request using HTTP reveals information about the 94 client identity to a server. Though the content of requests might 95 reveal information, that is information under the control of the 96 client. In comparison, the source address on the connection reveals 97 information that a client has only limited control over. 99 Even where an IP address is not directly attributed to an individual, 100 the use of an address over time can be used to correlate requests. 101 Servers are able to use this information to assemble profiles of 102 client behavior, from which they can make inferences about the people 103 involved. The use of persistent connections to make multiple 104 requests improves performance, but provides servers with additional 105 certainty about the identity of clients in a similar fashion. 107 Use of an HTTP proxy can provide a degree of protection against 108 servers correlating requests. Systems like virtual private networks 109 or the Tor network [Dingledine2004], provide other options for 110 clients. 112 Though the overhead imposed by these methods varies, the cost for 113 each request is significant. Preventing request linkability requires 114 that each request use a completely new TLS connection to the server. 115 At a minimum, this requires an additional round trip to the server in 116 addition to that required by the request. In addition to having high 117 latency, there are significant secondary costs, both in terms of the 118 number of additional bytes exchanged and the CPU cost of 119 cryptographic computations. 121 This document describes a method of encapsulation for binary HTTP 122 messages [BINARY] using Hybrid Public Key Encryption (HPKE; [HPKE]). 123 This protects the content of both requests and responses and enables 124 a deployment architecture that can separate the identity of a 125 requester from the request. 127 Though this scheme requires that servers and proxies explicitly 128 support it, this design represents a performance improvement over 129 options that perform just one request in each connection. With 130 limited trust placed in the proxy (see Section 8), clients are 131 assured that requests are not uniquely attributed to them or linked 132 to other requests. 134 2. Conventions and Definitions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 Encapsulated Request: An HTTP request that is encapsulated in an 143 HPKE-encrypted message; see Section 5.1. 145 Encapsulated Response: An HTTP response that is encapsulated in an 146 HPKE-encrypted message; see Section 5.2. 148 Oblivious Proxy Resource: An intermediary that forwards requests and 149 responses between clients and a single oblivious request resource. 151 Oblivious Request Resource: A resource that can receive an 152 encapsulated request, extract the contents of that request, 153 forward it to an oblivious target resource, receive a response, 154 encapsulate that response, then return that response. 156 Oblivious Target Resource: The resource that is the target of an 157 encapsulated request. This resource logically handles only 158 regular HTTP requests and responses and so might be ignorant of 159 the use of oblivious HTTP to reach it. 161 This draft includes pseudocode that uses the functions and 162 conventions defined in [HPKE]. 164 Encoding an integer to a sequence of bytes in network byte order is 165 described using the function "encode(n, v)", where "n" is the number 166 of bytes and "v" is the integer value. The function "len()" returns 167 the length of a sequence of bytes. 169 Formats are described using notation from Section 1.3 of [QUIC]. 171 3. Overview 173 A client learns the following: 175 * The identity of an oblivious request resource. This might include 176 some information about oblivious target resources that the 177 oblivious request resource supports. 179 * The details of an HPKE public key that the oblivious request 180 resource accepts, including an identifier for that key and the 181 HPKE algorithms that are used with that key. 183 * The identity of an oblivious proxy resource that will forward 184 encapsulated requests and responses to the oblivious request 185 resource. 187 This information allows the client to make a request of an oblivious 188 target resource without that resource having only a limited ability 189 to correlate that request with the client IP or other requests that 190 the client might make to that server. 192 +---------+ +----------+ +----------+ +----------+ 193 | Client | | Proxy | | Request | | Target | 194 | | | Resource | | Resource | | Resource | 195 +---------+ +----------+ +----------+ +----------+ 196 | | | | 197 | Encapsulated | | | 198 | Request | | | 199 |----------------->| Encapsulated | | 200 | | Request | | 201 | |------------------>| Request | 202 | | |-------------->| 203 | | | | 204 | | | Response | 205 | | Encapsulated |<--------------| 206 | | Response | | 207 | Encapsulated |<------------------| | 208 | Response | | | 209 |<-----------------| | | 210 | | | | 212 Figure 1: Overview of Oblivious HTTP 214 In order to make a request to an oblivious target resource, the 215 following steps occur, as shown in Figure 1: 217 1. The client constructs an HTTP request for an oblivious target 218 resource. 220 2. The client encodes the HTTP request in a binary HTTP message and 221 then encapsulates that message using HPKE and the process from 222 Section 5.1. 224 3. The client sends a POST request to the oblivious proxy resource 225 with the encapsulated request as the content of that message. 227 4. The oblivious proxy resource forwards this request to the 228 oblivious request resource. 230 5. The oblivious request resource receives this request and removes 231 the HPKE protection to obtain an HTTP request. 233 6. The oblivious request resource makes an HTTP request that 234 includes the target URI, method, fields, and content of the 235 request it acquires. 237 7. The oblivious target resource answers this HTTP request with an 238 HTTP response. 240 8. The oblivious request resource encapsulates the HTTP response 241 following the process in Section 5.2 and sends this in response 242 to the request from the oblivious proxy resource. 244 9. The oblivious proxy resource forwards this response to the 245 client. 247 10. The client removes the encapsulation to obtain the response to 248 the original request. 250 4. Key Configuration 252 A client needs to acquire information about the key configuration of 253 the oblivious request resource in order to send encapsulated 254 requests. 256 In order to ensure that clients do not encapsulate messages that 257 other entities can intercept, the key configuration MUST be 258 authenticated and have integrity protection. One way to ensure 259 integrity for key configuration is for the oblivious request resource 260 to serve content to the client directly, using HTTPS and the 261 "application/ohttp-keys" media type; see Section 4.2. 263 Specifying a format for expressing the information a client needs to 264 construct an encapsulated request ensures that different client 265 implementations can be configured in the same way. This also enables 266 advertising key configurations in a consistent format. 268 A client might have multiple key configurations to select from when 269 encapsulating a request. Clients are responsible for selecting a 270 preferred key configuration from those it supports. Clients need to 271 consider both the key encapsulation method (KEM) and the combinations 272 of key derivation function (KDF) and authenticated encryption with 273 associated data (AEAD) in this decision. 275 Evolution of the key configuration format is supported through the 276 definition of new formats that are identified by new media types. 278 4.1. Key Configuration Encoding 280 A single key configuration consists of a key identifier, a public 281 key, an identifier for the KEM that the public key uses, and a set 282 HPKE symmetric algorithms. Each symmetric algorithm consists of an 283 identifier for a KDF and an identifier for an AEAD. 285 Figure 2 shows a single key configuration, KeyConfig, that is 286 expressed using the TLS syntax; see Section 3 of [TLS]. 288 opaque HpkePublicKey<1..2^16-1>; 289 uint16 HpkeKemId; 290 uint16 HpkeKdfId; 291 uint16 HpkeAeadId; 293 struct { 294 HpkeKdfId kdf_id; 295 HpkeAeadId aead_id; 296 } HpkeSymmetricAlgorithms; 298 struct { 299 uint8 key_id; 300 HpkeKemId kem_id; 301 HpkePublicKey public_key; 302 HpkeSymmetricAlgorithms cipher_suites<4..2^16-4>; 303 } KeyConfig; 305 Figure 2: A Single Key Configuration 307 The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, 308 and AEAD respectively. The definitions for these identifiers and the 309 semantics of the algorithms they identify can be found in [HPKE]. 311 4.2. Key Configuration Media Type 313 The "application/ohttp-keys" format is a media type that identifies a 314 serialized collection of key configurations. The content of this 315 media type comprises one or more key configuration encodings (see 316 Section 4.1) that are concatenated. 318 Type name: application 320 Subtype name: ohttp-keys 322 Required parameters: N/A 324 Optional parameters: None 325 Encoding considerations: only "8bit" or "binary" is permitted 327 Security considerations: see Section 8 329 Interoperability considerations: N/A 331 Published specification: this specification 333 Applications that use this media type: N/A 335 Fragment identifier considerations: N/A 337 Additional information: Magic number(s): N/A 339 Deprecated alias names for this type: N/A 341 File extension(s): N/A 343 Macintosh file type code(s): N/A 345 Person and email address to contact for further information: see Aut 346 hors' Addresses section 348 Intended usage: COMMON 350 Restrictions on usage: N/A 352 Author: see Authors' Addresses section 354 Change controller: IESG 356 5. HPKE Encapsulation 358 HTTP message encapsulation uses HPKE for request and response 359 encryption. An encapsulated HTTP message includes the following 360 values: 362 1. A binary-encoded HTTP message; see [BINARY]. 364 2. Padding of arbitrary length which MUST contain all zeroes. 366 The encoding of an HTTP message is as follows: 368 Plaintext Message { 369 Message Length (i), 370 Message (..), 371 Padding Length (i), 372 Padding (..), 373 } 375 An Encapsulated Request is comprised of a length-prefixed key 376 identifier and a HPKE-protected request message. HPKE protection 377 includes an encapsulated KEM shared secret (or "enc"), plus the AEAD- 378 protected request message. An Encapsulated Request is shown in 379 Figure 3. Section 5.1 describes the process for constructing and 380 processing an Encapsulated Request. 382 Encapsulated Request { 383 Key Identifier (8), 384 KDF Identifier (16), 385 AEAD Identifier (16), 386 Encapsulated KEM Shared Secret (..), 387 AEAD-Protected Request (..), 388 } 390 Figure 3: Encapsulated Request 392 Responses are bound to responses and so consist only of AEAD- 393 protected content. Section 5.2 describes the process for 394 constructing and processing an Encapsulated Response. 396 Encapsulated Response { 397 Nonce (Nk), 398 AEAD-Protected Response (..), 399 } 401 Figure 4: Encapsulated Response 403 The size of the Nonce field in an Encapsulated Response corresponds 404 to the size of an AEAD key for the corresponding HPKE ciphersuite. 406 5.1. HPKE Encapsulation of Requests 408 Clients encapsulate a request "request" using values from a key 409 configuration: 411 * the key identifier from the configuration, "keyID", 413 * the public key from the configuration, "pkR", and 414 * a selected combination of KDF, identified by "kdfID", and AEAD, 415 identified by "aeadID". 417 The client then constructs an encapsulated request, "enc_request", as 418 follows: 420 1. Compute an HPKE context using "pkR", yielding "context" and 421 encapsulation key "enc". 423 2. Construct associated data, "aad", by concatenating the values of 424 "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers 425 respectively, each in network byte order. 427 3. Encrypt (seal) "request" with "aad" as associated data using 428 "context", yielding ciphertext "ct". 430 4. Concatenate the values of "aad", "enc", and "ct", yielding an 431 Encapsulated Request "enc_request". 433 Note that "enc" is of fixed-length, so there is no ambiguity in 434 parsing this structure. 436 In pseudocode, this procedure is as follows: 438 enc, context = SetupBaseS(pkR, "request") 439 aad = concat(encode(1, keyID), 440 encode(2, kdfID), 441 encode(2, aeadID)) 442 ct = context.Seal(aad, request) 443 enc_request = concat(aad, enc, ct) 445 Servers decrypt an Encapsulated Request by reversing this process. 446 Given an Encapsulated Request "enc_request", a server: 448 1. Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and 449 "ct" (indicated using the function "parse()" in pseudocode). The 450 server is then able to find the HPKE private key, "skR", 451 corresponding to "keyID". 453 a. If "keyID" does not identify a key, the server returns an 454 error. 456 b. If "kdfID" and "aeadID" identify a combination of KDF and 457 AEAD that the server is unwilling to use with "skR", the server 458 returns an error. 460 2. Compute an HPKE context using "skR" and the encapsulated key 461 "enc", yielding "context". 463 3. Construct additional associated data, "aad", from "keyID", 464 "kdfID", and "aeadID" or as the first five bytes of 465 "enc_request". 467 4. Decrypt "ct" using "aad" as associated data, yielding "request" 468 or an error on failure. If decryption fails, the server returns 469 an error. 471 In pseudocode, this procedure is as follows: 473 keyID, kdfID, aeadID, enc, ct = parse(enc_request) 474 aad = concat(encode(1, keyID), 475 encode(2, kdfID), 476 encode(2, aeadID)) 477 context = SetupBaseR(enc, skR, "request") 478 request, error = context.Open(aad, ct) 480 5.2. HPKE Encapsulation of Responses 482 Given an HPKE context "context", a request message "request", and a 483 response "response", servers generate an Encapsulated Response 484 "enc_response" as follows: 486 1. Export a secret "secret" from "context", using the string 487 "response" as context. The length of this secret is "max(Nn, 488 Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce 489 associated with "context". 491 2. Generate a random value of length "max(Nn, Nk)" bytes, called 492 "response_nonce". 494 3. Extract a pseudorandom key "prk" using the "Extract" function 495 provided by the KDF algorithm associated with "context". The 496 "ikm" input to this function is "secret"; the "salt" input is the 497 concatenation of "enc" (from "enc_request") and "response_nonce" 499 4. Use the "Expand" function provided by the same KDF to extract an 500 AEAD key "key", of length "Nk" - the length of the keys used by 501 the AEAD associated with "context". Generating "key" uses a 502 label of "key". 504 5. Use the same "Expand" function to extract a nonce "nonce" of 505 length "Nn" - the length of the nonce used by the AEAD. 506 Generating "nonce" uses a label of "nonce". 508 6. Encrypt "response", passing the AEAD function Seal the values of 509 "key", "nonce", empty "aad", and a "pt" input of "request", which 510 yields "ct". 512 7. Concatenate "response_nonce" and "ct", yielding an Encapsulated 513 Response "enc_response". Note that "response_nonce" is of fixed- 514 length, so there is no ambiguity in parsing either 515 "response_nonce" or "ct". 517 In pseudocode, this procedure is as follows: 519 secret = context.Export("response", Nk) 520 response_nonce = random(max(Nn, Nk)) 521 salt = concat(enc, response_nonce) 522 prk = Extract(salt, secret) 523 aead_key = Expand(secret, "key", Nk) 524 aead_nonce = Expand(secret, "nonce", Nn) 525 ct = Seal(aead_key, aead_nonce, "", response) 526 enc_response = concat(response_nonce, ct) 528 Clients decrypt an Encapsulated Request by reversing this process. 529 That is, they first parse "enc_response" into "response_nonce" and 530 "ct". They then follow the same process to derive values for 531 "aead_key" and "aead_nonce". 533 The client uses these values to decrypt "ct" using the Open function 534 provided by the AEAD. Decrypting might produce an error, as follows: 536 reponse, error = Open(aead_key, aead_nonce, "", ct) 538 6. HTTP Usage 540 A client interacts with the oblivious proxy resource by constructing 541 an encapsulated request. This encapsulated request is included as 542 the content of a POST request to the oblivious proxy resource. This 543 request MUST only contain those fields necessary to carry the 544 encapsulated request: a method of POST, a target URI of the oblivious 545 proxy resource, a header field containing the content type (see 546 (Section 7), and the encapsulated request as the request content. 547 Clients MAY include fields that do not reveal information about the 548 content of the request, such as Alt-Used [ALT-SVC], or information 549 that it trusts the oblivious proxy resource to remove, such as fields 550 that are listed in the Connection header field. 552 The oblivious proxy resource interacts with the oblivious request 553 resource by constructing a request using the same restrictions as the 554 client request, except that the target URI is the oblivious request 555 resource. The content of this request is copied from the client. 556 The oblivious proxy resource MUST NOT add information about the 557 client to this request. 559 When a response is received from the oblivious request resource, the 560 oblivious proxy resource forwards the response according to the rules 561 of an HTTP proxy; see Section 7.6 of [HTTP]. 563 An oblivious request resource, if it receives any response from the 564 oblivious target resource, sends a single 200 response containing the 565 encapsulated response. Like the request from the client, this 566 response MUST only contain those fields necessary to carry the 567 encapsulated response: a 200 status code, a header field indicating 568 the content type, and the encapsulated response as the response 569 content. As with requests, additional fields MAY be used to convey 570 information that does not reveal information about the encapsulated 571 response. 573 An oblivious request resource acts as a gateway for requests to the 574 oblivious target resource (see Section 7.6 of [HTTP]). The one 575 exception is that any information it might forward in a response MUST 576 be encapsulated, unless it is responding to errors it detects before 577 removing encapsulation of the request; see Section 6.2. 579 6.1. Informational Responses 581 This encapsulation does not permit progressive processing of 582 responses. Though the binary HTTP response format does support the 583 inclusion of informational (1xx) status codes, the AEAD encapsulation 584 cannot be removed until the entire message is received. 586 In particular, the Expect header field with 100-continue (see 587 Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct 588 a request that includes a 100-continue expectation; the oblivious 589 request resource MUST generate an error if a 100-continue expectation 590 is received. 592 6.2. Errors 594 A server that receives an invalid message for any reason MUST 595 generate an HTTP response with a 4xx status code. 597 Errors detected by the oblivious proxy resource and errors detected 598 by the oblivious request resource before removing protection 599 (including being unable to remove encapsulation for any reason) 600 result in the status code being sent without protection in response 601 to the POST request made to that resource. 603 Errors detected by the oblivious request resource after successfully 604 removing encapsulation and errors detected by the oblivious target 605 resource MUST be sent in an encapsulated response. 607 7. Media Types 609 Media types are used to identify encapsulated requests and responses. 611 Evolution of the format of encapsulated requests and responses is 612 supported through the definition of new formats that are identified 613 by new media types. 615 7.1. message/ohttp-req Media Type 617 The "message/ohttp-req" identifies an encapsulated binary HTTP 618 request. This is a binary format that is defined in Section 5.1. 620 Type name: message 622 Subtype name: ohttp-req 624 Required parameters: N/A 626 Optional parameters: None 628 Encoding considerations: only "8bit" or "binary" is permitted 630 Security considerations: see Section 8 632 Interoperability considerations: N/A 634 Published specification: this specification 636 Applications that use this media type: N/A 638 Fragment identifier considerations: N/A 640 Additional information: Magic number(s): N/A 642 Deprecated alias names for this type: N/A 644 File extension(s): N/A 646 Macintosh file type code(s): N/A 648 Person and email address to contact for further information: see Aut 649 hors' Addresses section 651 Intended usage: COMMON 653 Restrictions on usage: N/A 654 Author: see Authors' Addresses section 656 Change controller: IESG 658 7.2. message/ohttp-res Media Type 660 The "message/ohttp-res" identifies an encapsulated binary HTTP 661 response. This is a binary format that is defined in Section 5.2. 663 Type name: message 665 Subtype name: ohttp-res 667 Required parameters: N/A 669 Optional parameters: None 671 Encoding considerations: only "8bit" or "binary" is permitted 673 Security considerations: see Section 8 675 Interoperability considerations: N/A 677 Published specification: this specification 679 Applications that use this media type: N/A 681 Fragment identifier considerations: N/A 683 Additional information: Magic number(s): N/A 685 Deprecated alias names for this type: N/A 687 File extension(s): N/A 689 Macintosh file type code(s): N/A 691 Person and email address to contact for further information: see Aut 692 hors' Addresses section 694 Intended usage: COMMON 696 Restrictions on usage: N/A 698 Author: see Authors' Addresses section 700 Change controller: IESG 702 8. Security Considerations 704 In this design, a client wishes to make a request of a server that is 705 authoritative for the oblivious target resource. The client wishes 706 to make this request without linking that request with either: 708 1. The identity at the network and transport layer of the client 709 (that is, the client IP address and TCP or UDP port number the 710 client uses to create a connection). 712 2. Any other request the client might have made in the past or might 713 make in the future. 715 In order to ensure this, the client selects a proxy (that serves the 716 oblivious proxy resource) that it trusts will protect this 717 information by forwarding the encapsulated request and response 718 without passing the server (that serves the oblivious request 719 resource). 721 In this section, a deployment where there are three entities is 722 considered: 724 * A client makes requests and receives responses 726 * A proxy operates the oblivious proxy resource 728 * A server operates both the oblivious request resource and the 729 oblivious target resource 731 To achieve the stated privacy goals, the oblivious proxy resource 732 cannot be operated by the same entity as the oblivious request 733 resource. However, colocation of the oblivious request resource and 734 oblivious target resource simplifies the interactions between those 735 resources without affecting client privacy. 737 8.1. Client 739 Clients MUST ensure that the key configuration they select for 740 generating encapsulated requests is integrity protected and 741 authenticated so that it can be attributed to the oblivious request 742 resource; see Section 4. 744 Clients MUST NOT include identifying information in the request that 745 is encapsulated. 747 Clients cannot carry connection-level state between requests as they 748 only establish direct connections to the proxy responsible for the 749 oblivious proxy resource. However, clients need to ensure that they 750 construct requests without any information gained from previous 751 requests. Otherwise, the server might be able to use that 752 information to link requests. Cookies [COOKIES] are the most obvious 753 feature that MUST NOT be used by clients. However, clients need to 754 include all information learned from requests, which could include 755 the identity of resources. 757 Clients MUST generate a new HPKE context for every request, using a 758 good source of entropy ([RANDOM]) for generating keys. Key reuse not 759 only risks requests being linked, reuse could expose request and 760 response contents to the proxy. 762 The request the client sends to the oblivious proxy resource only 763 requires minimal information; see Section 6. The request that 764 carries the encapsulated request and is sent to the oblivious proxy 765 resource MUST NOT include identifying information unless the client 766 ensures that this information is removed by the proxy. A client MAY 767 include information only for the oblivious proxy resource in header 768 fields identified by the Connection header field if it trusts the 769 proxy to remove these as required by Section 7.6.1 of [HTTP]. The 770 client needs to trust that the proxy does not replicate the source 771 addressing information in the request it forwards. 773 Clients rely on the oblivious proxy resource to forward encapsulated 774 requests and responses. However, the proxy can only refuse to 775 forward messages, it cannot inspect or modify the contents of 776 encapsulated requests or responses. 778 8.2. Proxy Responsibilities 780 The proxy that serves the oblivious proxy resource has a very simple 781 function to perform. For each request it receives, it makes a 782 request of the oblivious request resource that includes the same 783 content. When it receives a response, it sends a response to the 784 client that includes the content of the response from the oblivious 785 request resource. When generating a request, the proxy MUST follow 786 the forwarding rules in Section 7.6 of [HTTP]. 788 A proxy can also generate responses, though it assumed to not be able 789 to examine the content of a request (other than to observe the choice 790 of key identifier, KDF, and AEAD), so it is also assumed that it 791 cannot generate an encapsulated response. 793 A proxy MUST NOT add information about the client identity when 794 forwarding requests. This includes the Via field, the Forwarded 795 field [FORWARDED], and any similar information. 797 8.2.1. Denial of Service 799 As there are privacy benefits from having a large rate of requests 800 forwarded by the same proxy (see Section 8.2.2), servers that operate 801 the oblivious request resource might need an arrangement with 802 proxies. This arrangement might be necessary to prevent having the 803 large volume of requests being classified as an attack by the server. 805 If a server does accept a large volume of requests from a proxy, it 806 needs to trust that the proxy does not allow abusive levels of 807 request volumes from clients. That is, if a server allows requests 808 from the proxy to be exempt from rate limits, the server might want 809 to ensure that the proxy applies similar rate limiting when receiving 810 requests from clients. 812 Servers that enter into an agreement with a proxy that enables a 813 higher request rate might choose to authenticate the proxy to enable 814 the higher rate. 816 8.2.2. Linkability Through Traffic Analysis 818 As the time at which encapsulated request or response messages are 819 sent can reveal information to a network observer. Though messages 820 exchanged between the oblivious proxy resource and the oblivious 821 request resource might be sent in a single connection, traffic 822 analysis could be used to match messages that are forwarded by the 823 proxy. 825 A proxy could, as part of its function, add delays in order to 826 increase the anonymity set into which each message is attributed. 827 This could latency to the overall time clients take to receive a 828 response, which might not what some clients want. 830 A proxy can use padding to reduce the effectiveness of traffic 831 analysis. 833 A proxy that forwards large volumes of exchanges can provide better 834 privacy by providing larger sets of messages that need to be matched. 836 8.3. Server Responsibilities 838 A server that operates both oblivious request and oblivious target 839 resources is responsible for removing request encapsulation, 840 generating a response the encapsulated request, and encapsulating the 841 response. 843 Servers should account for traffic analysis based on response size or 844 generation time. Techniques such as padding or timing delays can 845 help protect against such attacks; see Section 8.2.2. 847 If separate entities provide the oblivious request resource and 848 oblivious target resource, these entities might need an arrangement 849 similar to that between server and proxy for managing denial of 850 service; see Section 8.2.1. It is also necessary to provide 851 confidentiality protection for the unprotected requests and 852 responses, plus protections for traffic analysis; see Section 8.2.2. 854 An oblivious request resource needs to have a plan for replacing 855 keys. This might include regular replacement of keys, which can be 856 assigned new key identifiers. If an oblivious request resource 857 receives a request that contains a key identifier that it does not 858 understand or that corresponds to a key that has been replaced, the 859 server can respond with an HTTP 422 (Unprocessable Content) status 860 code. 862 A server can also use a 422 status code if the server has a key that 863 corresponds to the key identifier, but the encapsulated request 864 cannot be successfully decrypted using the key. 866 9. IANA Considerations 868 Please update the "Media Types" registry at 869 https://www.iana.org/assignments/media-types 870 (https://www.iana.org/assignments/media-types) with the registration 871 information in Section 7 for the media types "message/ohttp-req", 872 "message/ohttp-res", and "application/ohttp-keys". 874 10. References 876 10.1. Normative References 878 [BINARY] Thomson, M., "Binary Representation of HTTP Messages", 879 Work in Progress, Internet-Draft, draft-ietf-http-binary- 880 message-latest, 28 January 2021, 881 . 884 [HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 885 Public Key Encryption", Work in Progress, Internet-Draft, 886 draft-irtf-cfrg-hpke-07, 16 December 2020, 887 . 890 [HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP 891 Semantics", Work in Progress, Internet-Draft, draft-ietf- 892 httpbis-semantics-14, 12 January 2021, 893 . 896 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 897 and Secure Transport", Work in Progress, Internet-Draft, 898 draft-ietf-quic-transport-34, 14 January 2021, 899 . 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, 904 DOI 10.17487/RFC2119, March 1997, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 912 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 913 . 915 10.2. Informative References 917 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 918 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 919 April 2016, . 921 [COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, 922 DOI 10.17487/RFC6265, April 2011, 923 . 925 [Dingledine2004] 926 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The 927 Second-Generation Onion Router", August 2004, 928 . 931 [FORWARDED] 932 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 933 RFC 7239, DOI 10.17487/RFC7239, June 2014, 934 . 936 [ODOH] Kinnear, E., McManus, P., Pauly, T., and C. Wood, 937 "Oblivious DNS Over HTTPS", Work in Progress, Internet- 938 Draft, draft-pauly-dprive-oblivious-doh-04, 26 January 939 2021, . 942 [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, 943 "Randomness Requirements for Security", BCP 106, RFC 4086, 944 DOI 10.17487/RFC4086, June 2005, 945 . 947 [X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 948 for Security", RFC 7748, DOI 10.17487/RFC7748, January 949 2016, . 951 Appendix A. Complete Example of a Request and Response 953 A single request and response exchange is shown here. Binary values 954 (key configuration, secret keys, the content of messages, and 955 intermediate values) are shown in hexadecimal. The request and 956 response here are absolutely minimal; the purpose of this example is 957 to show the cryptographic operations. 959 The oblivious request resource generates a key pair. In this example 960 the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 961 key pair [X25519]. The X25519 secret key is: 963 15ce887006e079dcc7d67e73e5c13e31a55083f816eca9ebcf523b90ea2ab7b0 965 The oblivious request resource constructs a key configuration that 966 includes the corresponding public key as follows: 968 0100200020f21c612398e4384c21b7f2a759133c6c2d1b9ce6d033613dfad2c7 969 3d4826214900080001000100010003 971 This key configuration is somehow obtained by the client. Then when 972 a client wishes to send an HTTP request of a GET request to 973 "https://example.com", it constructs the following binary HTTP 974 message: 976 00034745540568747470730b6578616d706c652e636f6d012f 978 The client then reads the oblivious request resource key 979 configuration and selects a mutually supported KDF and AEAD. In this 980 example, the client selects HKDF-SHA256 and AES-128-GCM. The client 981 then generates an HPKE context that uses the server public key. This 982 results in the following encapsulated key: 984 a7e0dffe93bc9ed807b51588f10669cd2f09ceb7f6a71153658275993eb88276 986 The corresponding private key is: 988 3b04f76e7ea1313484dd73c343adb94c23671f98cb66fc7ecc6127f38e1d4431 990 Applying the Seal operation from the HPKE context produces an 991 encrypted message, allowing the client to construct the following 992 encapsulated request: 994 0100010001a7e0dffe93bc9ed807b51588f10669cd2f09ceb7f6a71153658275 995 993eb88276b497362592977a4abc7857cf9892377af698ca0ee31fe72d21ca12 996 6ff2074eb9292ce7a83fc53158ff 998 The client then sends this to the oblivious proxy resource in a POST 999 request, which might look like the following HTTP/1.1 request: 1001 POST /request.example.net/proxy HTTP/1.1 1002 Host: proxy.example.org 1003 Content-Type: message/ohttp-req 1004 Content-Length: 78 1006 1008 The oblivious proxy resource receives this request and forwards it to 1009 the oblivious request resource, which might look like: 1011 POST /oblivious/request HTTP/1.1 1012 Host: example.com 1013 Content-Type: message/ohttp-req 1014 Content-Length: 78 1016 1018 The oblivous request resource receives this request, selects the key 1019 it generated previously using the key identifier from the message, 1020 and decrypts the message. As this request is directed to the same 1021 server, the oblivious request resource does not need to initiate an 1022 HTTP request to the oblivious target resource. The request can be 1023 served directly by the oblivious target resource, which generates a 1024 minimal response (consisting of just a 200 status code) as follows: 1026 0140c8 1028 The response is constructed by extracting a secret from the HPKE 1029 context: 1031 861c67eefd91906068ee3208a9102274 1032 The key derivation for the encapsulated response uses both the 1033 encapsulated KEM key from the request and a randomly selected nonce. 1034 This produces a salt of: 1036 a7e0dffe93bc9ed807b51588f10669cd2f09ceb7f6a71153658275993eb88276 1037 55645b6626d6e8b1163d739c6cd3d94a 1039 The salt and secret are both passed to the Extract function of the 1040 selected KDF (HKDF-SHA256) to produce a pseudorandom key of: 1042 ac29e0e1df48de4b349bb97db74da7f6732557a2fa6d12019ddadd8bf1e9cd99 1044 The pseudorandom key is used with the Expand function of the KDF and 1045 an info field of "key" to produce a 16-byte key for the selected AEAD 1046 (AES-128-GCM): 1048 0d81ce961eb6e61d510e18053418f316 1050 With the same KDF and pseudorandom key, an info field of "nonce" is 1051 used to generate a 12-byte nonce: 1053 ba2d3637b5f041cc15ef73b2 1055 The AEAD Seal function is then used to encrypt the response, which is 1056 added to the randomized nonce value to produce the encapsulated 1057 response: 1059 55645b6626d6e8b1163d739c6cd3d94ac7e0cfd48adf8057517241ee220d20bc 1060 e00a4a 1062 The oblivious request resource then constructs a response: 1064 HTTP/1.1 200 OK 1065 Date: Wed, 27 Jan 2021 04:45:07 GMT 1066 Cache-Control: private, no-store 1067 Content-Type: message/ohttp-res 1068 Content-Length: 38 1070 1072 The same response might then be generated by the oblivious proxy 1073 resource which might change as little as the Date header. The client 1074 is then able to use the HPKE context it created and the nonce from 1075 the encapsulated response to construct the AEAD key and nonce and 1076 decrypt the response. 1078 Acknowledgments 1080 This design is based on a design for oblivious DoH, described in 1081 [ODOH]. Eric Rescorla helped unify the structure of the key format. 1083 Authors' Addresses 1085 Martin Thomson 1086 Mozilla 1088 Email: mt@lowentropy.net 1090 Christopher A. Wood 1091 Cloudflare 1093 Email: caw@heapingbits.net