idnits 2.17.1 draft-pauly-dprive-oblivious-doh-08.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 (3 December 2021) is 874 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft Apple Inc. 4 Intended status: Experimental P. McManus 5 Expires: 6 June 2022 Fastly 6 T. Pauly 7 Apple Inc. 8 T. Verma 9 C.A. Wood 10 Cloudflare 11 3 December 2021 13 Oblivious DNS Over HTTPS 14 draft-pauly-dprive-oblivious-doh-08 16 Abstract 18 This document describes an extension to DNS Over HTTPS (DoH) that 19 allows hiding client IP addresses via proxying encrypted DNS 20 transactions. This improves privacy of DNS operations by not 21 allowing any one server entity to be aware of both the client IP 22 address and the content of DNS queries and answers. 24 This experimental extension is developed outside the IETF and is 25 published here to guide implementation, ensure interoperability among 26 implementations, and enable wide-scale experimentation. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 6 June 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 4 65 4. HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. HTTP Request . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. HTTP Request Example . . . . . . . . . . . . . . . . . . 6 68 4.3. HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. HTTP Response Example . . . . . . . . . . . . . . . . . . 7 70 4.5. HTTP Metadata . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Configuration and Public Key Format . . . . . . . . . . . . . 8 72 6. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Message Format . . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Encryption and Decryption Routines . . . . . . . . . . . 11 75 7. Oblivious Client Behavior . . . . . . . . . . . . . . . . . . 12 76 8. Oblivious Target Behavior . . . . . . . . . . . . . . . . . . 13 77 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 14 78 10. Experiment Overview . . . . . . . . . . . . . . . . . . . . . 14 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 11.1. Denial of Service . . . . . . . . . . . . . . . . . . . 16 81 11.2. Proxy Policies . . . . . . . . . . . . . . . . . . . . . 16 82 11.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16 83 11.4. General Proxy Services . . . . . . . . . . . . . . . . . 17 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 12.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 17 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 14.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 95 messages to be transmitted in encrypted HTTP messages. This provides 96 improved confidentiality and authentication for DNS interactions in 97 various circumstances. 99 While DoH can prevent eavesdroppers from directly reading the 100 contents of DNS exchanges, clients cannot send DNS queries and 101 receive answers from servers without revealing their local IP 102 address, and thus information about the identity or location of the 103 client. 105 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 106 increase privacy by ensuring no single DNS server is aware of both 107 the client IP address and the message contents. 109 This document defines Oblivious DoH, an experimental extension to DoH 110 that permits proxied resolution, in which DNS messages are encrypted 111 so that no DoH server can independently read both the client IP 112 address and the DNS message contents. 114 As with DoH, DNS messages exchanged over Oblivious DoH are fully- 115 formed DNS messages. Clients that want to receive answers that are 116 relevant to the network they are on without revealing their exact IP 117 address can thus use the EDNS Client Subnet option [RFC7871], 118 Section 7.1.2 to provide a hint to the Oblivious DoH server. 120 This mechanism is intended to be used as one mechanism for resolving 121 privacy-sensitive content in the broader context of DNS privacy. 123 This experimental extension is developed outside the IETF and is 124 published here to guide implementation, ensure interoperability among 125 implementations, and enable wide-scale experimentation. See 126 Section 10 for more details about the experiment. 128 1.1. Specification of Requirements 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Terminology 138 This document defines the following terms: 140 Oblivious Server: A DoH server that acts as either an Oblivious 141 Proxy or Oblivious Target. 143 Oblivious Proxy: An Oblivious Server that proxies encrypted DNS 144 queries and responses between a Client and an Oblivious Target. 146 Oblivious Target: An Oblivious Server that receives and decrypts 147 encrypted Client DNS queries from an Oblivious Proxy, and returns 148 encrypted DNS responses via that same Proxy. In order to provide 149 DNS responses, the Target can be a DNS resolver, be co-located 150 with a resolver, or forward to a resolver. 152 Throughout the rest of this document, we use the terms Proxy and 153 Target to refer to an Oblivious Proxy and Oblivious Target, 154 respectively. 156 3. Deployment Requirements 158 Oblivious DoH requires, at a minimum: 160 * Two Oblivious Servers, where one can act as a Proxy, and the other 161 can act as a Target. 163 * Public keys for encrypting DNS queries that are passed from a 164 Client through a Proxy to a Target (Section 5). These keys 165 guarantee that only the intended Target can decrypt Client 166 queries. 168 The mechanism for discovering and provisioning the DoH URI Templates 169 and public keys is out of scope of this document. 171 4. HTTP Exchange 173 Unlike direct resolution, oblivious hostname resolution over DoH 174 involves three parties: 176 1. The Client, which generates queries. 178 2. The Proxy, which receives encrypted queries from the Client and 179 passes them on to a Target. 181 3. The Target, which receives proxied queries from the Client via 182 the Proxy and produces proxied answers. 184 --- [ Request encrypted with Target public key ] --> 185 +---------+ +-----------+ +-----------+ 186 | Client +-------------> Oblivious +-------------> Oblivious | 187 | <-------------+ Proxy <-------------+ Target | 188 +---------+ +-----------+ +-----------+ 189 <-- [ Response encrypted with symmetric key ] --- 191 Figure 1: Obvlivious DoH Exchange 193 4.1. HTTP Request 195 Oblivious DoH queries are created by the Client, and sent to the 196 Proxy as an HTTP request using the POST method. Requests to the 197 Proxy indicate which DoH server to use as a Target by specifying two 198 variables: "targethost", which indicates the host name of the Target 199 server, and "targetpath", which indicates the path on which the 200 Target's DoH server is running. See Section 4.2 for an example 201 request. 203 Oblivious DoH messages have no cache value since both requests and 204 responses are encrypted using ephemeral key material. Clients SHOULD 205 indicate this using the "Cache-Control" header with "no-cache" and 206 "no-store" specified [RFC7234]. 208 Clients MUST set the HTTP Content-Type header to "application/ 209 oblivious-dns-message" to indicate that this request is an Oblivious 210 DoH query intended for proxying. Clients also SHOULD set this same 211 value for the HTTP Accept header. 213 Proxies MUST check that Client requests are correctly encoded, and 214 MUST return a 4xx (Client Error) if the check fails, along with the 215 Proxy-Status response header with an "error" parameter of type 216 "http_request_error" [I-D.ietf-httpbis-proxy-status]. A correctly 217 encoded request has the HTTP Content-Type header "application/ 218 oblivious-dns-message", uses the HTTP POST method, and contains 219 "targethost" and "targetpath" variables. 221 The "targethost" and "targetpath" variables are used to construct the 222 request to forward to the Target. The Proxy is expected to send the 223 Client's request using the URI constructed as "https://targethost/ 224 targetpath". 226 Note that "targethost" MAY contain a port. Proxies MAY choose to not 227 forward connections to non-standard ports. In such cases, Proxies 228 MUST return a 4xx (Client Error) response to the Client request, 229 along with Proxy-Status response header with an "error" parameter of 230 type "http_request_error". 232 If the Proxy cannot establish a connection to the Target, it MUST 233 return a 502 (Bad Gateway) response to the Client request, along with 234 Proxy-Status response header with an "error" parameter whose type 235 indicates the reason. For example, if DNS resolution fails, the 236 error type might be "dns_timeout", whereas if the TLS connection 237 failed the error type might be "tls_protocol_error". 239 Upon receipt of requests from a Proxy, Targets MUST validate that the 240 request has the HTTP Content-Type header "application/oblivious-dns- 241 message" and uses the HTTP POST method. Targets MUST return 4xx 242 (Client Error) if this check fails. 244 4.2. HTTP Request Example 246 The following example shows how a Client requests that a Proxy, 247 "dnsproxy.example", forwards an encrypted message to 248 "dnstarget.example". The URI template for the Proxy is 249 "https://dnsproxy.example/dns-query{?targethost,targetpath}". The 250 URI template for the Target is "https://dnstarget.example/dns-query". 252 :method = POST 253 :scheme = https 254 :authority = dnsproxy.example 255 :path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query 256 accept = application/oblivious-dns-message 257 cache-control = no-cache, no-store 258 content-type = application/oblivious-dns-message 259 content-length = 106 261 263 The Proxy then sends the following request on to the Target: 265 :method = POST 266 :scheme = https 267 :authority = dnstarget.example 268 :path = /dns-query 269 accept = application/oblivious-dns-message 270 cache-control = no-cache, no-store 271 content-type = application/oblivious-dns-message 272 content-length = 106 274 276 4.3. HTTP Response 278 The response to an Oblivious DoH query is generated by the Target. 279 It MUST set the Content-Type HTTP header to "application/oblivious- 280 dns-message" for all successful responses. The body of the response 281 contains an encrypted DNS message; see Section 6. 283 The response from a Target MUST set the Content-Type HTTP header to 284 "application/oblivious-dns-message" which MUST be forwarded by the 285 Proxy to the Client. A Client MUST only consider a response which 286 contains the Content-Type header in the response before processing 287 the payload. A response without the appropriate header MUST be 288 treated as an error and be handled appropriately. All other aspects 289 of the HTTP response and error handling are inherited from standard 290 DoH. 292 Proxies MUST forward any Target responses with 2xx, 3xx, 4xx, or 5xx 293 status codes unmodified to the Client. Note that if a Client 294 receives a 3xx status code and chooses to follow a redirect, the 295 subsequent request MUST also be performed through a Proxy in order to 296 avoid directly exposing requests to the Target. Target responses 297 with 1xx status codes MUST NOT be forwarded to the Client. If a 298 Proxy receives a successful response from a Target without the 299 "application/oblivious-dns-message" HTTP Content-Type header, it MUST 300 return a 502 (Bad Gateway) response to the Client request, along with 301 Proxy-Status response header with an "error" parameter of type 302 "http_protocol_error". 304 Requests that cannot be processed by the Target result in 4xx (Client 305 Error) responses. If the Target and Client keys do not match, it is 306 an authorization failure (HTTP status code 401; see Section 3.1 of 307 [RFC7235]). Otherwise, if the Client's request is invalid, such as 308 in the case of decryption failure, wrong message type, or 309 deserialization failure, this is a bad request (HTTP status code 400; 310 see Section 6.5.1 of [RFC7231]). 312 Even in case of DNS responses indicating failure, such as SERVFAIL or 313 NXDOMAIN, a successful HTTP response with a 2xx status code is used 314 as long as the DNS response is valid. This is similar to how DoH 315 [RFC8484] handles HTTP response codes. 317 In case of server error, the usual HTTP status code 500 (see 318 Section 6.6.1 of [RFC7231]) applies. 320 4.4. HTTP Response Example 322 The following example shows a 2xx (Successful) response that can be 323 sent from a Target to a Client via a Proxy. 325 :status = 200 326 content-type = application/oblivious-dns-message 327 content-length = 154 329 331 4.5. HTTP Metadata 333 Proxies forward requests and responses between Clients and Targets as 334 specified in Section 4.1. Metadata sent with these messages could 335 inadvertently weaken or remove Oblivious DoH privacy properties. 336 Proxies MUST NOT send any Client-identifying information about 337 Clients to Targets, such as "Forwarded" HTTP headers [RFC7239]. 338 Additionally, Clients MUST NOT include any private state in requests 339 to Proxies, such as HTTP cookies. See Section 11.3 for related 340 discussion about Client authentication information. 342 5. Configuration and Public Key Format 344 In order to use a DoH server as a Target, the Client needs to know a 345 public key to use for encrypting its queries. The mechanism for 346 discovering this configuration is out of scope of this document. 348 Servers ought to rotate public keys regularly. It is RECOMMENDED 349 that servers rotate keys every day. Shorter rotation windows reduce 350 the anonymity set of Clients that might use the public key, whereas 351 longer rotation windows widen the timeframe of possible compromise. 353 An Oblivious DNS public key configuration is a structure encoded, 354 using TLS-style encoding [RFC8446], as follows: 356 struct { 357 uint16 kem_id; 358 uint16 kdf_id; 359 uint16 aead_id; 360 opaque public_key<1..2^16-1>; 361 } ObliviousDoHConfigContents; 363 struct { 364 uint16 version; 365 uint16 length; 366 select (ObliviousDoHConfig.version) { 367 case 0x0001: ObliviousDoHConfigContents contents; 368 } 369 } ObliviousDoHConfig; 371 ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; 373 The ObliviousDoHConfigs structure contains one or more 374 ObliviousDoHConfig structures in decreasing order of preference. 375 This allows a server to support multiple versions of Oblivious DoH 376 and multiple sets of Oblivious DoH parameters. 378 An ObliviousDoHConfig contains a versioned representation of an 379 Oblivious DoH configuration, with the following fields. 381 version The version of Oblivious DoH for which this configuration is 382 used. Clients MUST ignore any ObliviousDoHConfig structure with a 383 version they do not support. The version of Oblivious DoH 384 specified in this document is 0x0001. 386 length The length, in bytes, of the next field. 388 contents An opaque byte string whose contents depend on the version. 389 For this specification, the contents are an 390 ObliviousDoHConfigContents structure. 392 An ObliviousDoHConfigContents contains the information needed to 393 encrypt a message under ObliviousDoHConfigContents.public_key such 394 that only the owner of the corresponding private key can decrypt the 395 message. The values for ObliviousDoHConfigContents.kem_id, 396 ObliviousDoHConfigContents.kdf_id, and 397 ObliviousDoHConfigContents.aead_id are described in 398 [I-D.irtf-cfrg-hpke] Section 7. The fields in this structure are as 399 follows: 401 kem_id The HPKE KEM identifier corresponding to public_key. Clients 402 MUST ignore any ObliviousDoHConfig structure with a key using a 403 KEM they do not support. 405 kdf_id The HPKE KDF identifier corresponding to public_key. Clients 406 MUST ignore any ObliviousDoHConfig structure with a key using a 407 KDF they do not support. 409 aead_id The HPKE AEAD identifier corresponding to public_key. 410 Clients MUST ignore any ObliviousDoHConfig structure with a key 411 using an AEAD they do not support. 413 public_key The HPKE public key used by the Client to encrypt 414 Oblivious DoH queries. 416 6. Protocol Encoding 418 This section includes encoding and wire format details for Oblivious 419 DoH, as well as routines for encrypting and decrypting encoded 420 values. 422 6.1. Message Format 424 There are two types of Oblivious DoH messages: Queries (0x01) and 425 Responses (0x02). Both messages carry the following information: 427 1. A DNS message, which is either a Query or Response, depending on 428 context. 430 2. Padding of arbitrary length which MUST contain all zeros. 432 They are encoded using the following structure: 434 struct { 435 opaque dns_message<1..2^16-1>; 436 opaque padding<0..2^16-1>; 437 } ObliviousDoHMessagePlaintext; 439 Both Query and Response messages use the ObliviousDoHMessagePlaintext 440 format. 442 ObliviousDoHMessagePlaintext ObliviousDoHQuery; 443 ObliviousDoHMessagePlaintext ObliviousDoHResponse; 445 An encrypted ObliviousDoHMessagePlaintext is carried in a 446 ObliviousDoHMessage message, encoded as follows: 448 struct { 449 uint8 message_type; 450 opaque key_id<0..2^16-1>; 451 opaque encrypted_message<1..2^16-1>; 452 } ObliviousDoHMessage; 454 The ObliviousDoHMessage structure contains the following fields: 456 message_type A one-byte identifier for the type of message. Query 457 messages use message_type 0x01, and Response messages use 458 message_type 0x02. 460 key_id The identifier of the corresponding 461 ObliviousDoHConfigContents key. This is computed as 462 Expand(Extract("", config), "odoh key id", Nh), where config is 463 the ObliviousDoHConfigContents structure and Extract, Expand, and 464 Nh are as specified by the HPKE cipher suite KDF corresponding to 465 config.kdf_id. 467 encrypted_message An encrypted message for the Oblivious Target (for 468 Query messages) or Client (for Response messages). 469 Implementations MAY enforce limits on the size of this field 470 depending on the size of plaintext DNS messages. (DNS queries, 471 for example, will not reach the size limit of 2^16-1 in practice.) 473 The contents of ObliviousDoHMessage.encrypted_message depend on 474 ObliviousDoHMessage.message_type. In particular, 475 ObliviousDoHMessage.encrypted_message is an encryption of a 476 ObliviousDoHQuery if the message is a Query, and ObliviousDoHResponse 477 if the message is a Response. 479 6.2. Encryption and Decryption Routines 481 Clients use the following utility functions for encrypting a Query 482 and decrypting a Response as described in Section 7. 484 encrypt_query_body: Encrypt an Oblivious DoH query. 486 def encrypt_query_body(pkR, key_id, Q_plain): 487 enc, context = SetupBaseS(pkR, "odoh query") 488 aad = 0x01 || len(key_id) || key_id 489 ct = context.Seal(aad, Q_plain) 490 Q_encrypted = enc || ct 491 return Q_encrypted 493 decrypt_response_body: Decrypt an Oblivious DoH response. 495 def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce): 496 aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce) 497 aad = 0x02 || len(resp_nonce) || resp_nonce 498 R_plain, error = Open(key, nonce, aad, R_encrypted) 499 return R_plain, error 501 The derive_secrets function is described below. 503 Targets use the following utility functions in processing queries and 504 producing responses as described in Section 8. 506 setup_query_context: Set up an HPKE context used for decrypting an 507 Oblivious DoH query. 509 def setup_query_context(skR, key_id, Q_encrypted): 510 enc || ct = Q_encrypted 511 context = SetupBaseR(enc, skR, "odoh query") 512 return context 514 decrypt_query_body: Decrypt an Oblivious DoH query. 516 def decrypt_query_body(context, key_id, Q_encrypted): 517 aad = 0x01 || len(key_id) || key_id 518 enc || ct = Q_encrypted 519 Q_plain, error = context.Open(aad, ct) 520 return Q_plain, error 522 derive_secrets: Derive keying material used for encrypting an 523 Oblivious DoH response. 525 def derive_secrets(context, Q_plain, resp_nonce): 526 secret = context.Export("odoh response", Nk) 527 salt = Q_plain || len(resp_nonce) || resp_nonce 528 prk = Extract(salt, secret) 529 key = Expand(odoh_prk, "odoh key", Nk) 530 nonce = Expand(odoh_prk, "odoh nonce", Nn) 531 return key, nonce 533 The random(N) function returns N cryptographically secure random 534 bytes from a good source of entropy [RFC4086]. The max(A, B) 535 function returns A if A > B, and B otherwise. 537 encrypt_response_body: Encrypt an Oblivious DoH response. 539 def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce): 540 aad = 0x02 || len(resp_nonce) || resp_nonce 541 R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain) 542 return R_encrypted 544 7. Oblivious Client Behavior 546 Let M be a DNS message (query) a Client wishes to protect with 547 Oblivious DoH. When sending an Oblivious DoH Query for resolving M 548 to an Oblivious Target with ObliviousDoHConfigContents config, a 549 Client does the following: 551 1. Create an ObliviousDoHQuery structure, carrying the message M and 552 padding, to produce Q_plain. 554 2. Deserialize config.public_key to produce a public key pkR of type 555 config.kem_id. 557 3. Compute the encrypted message as Q_encrypted = 558 encrypt_query_body(pkR, key_id, Q_plain), where key_id is as 559 computed in Section 6. Note also that len(key_id) outputs the 560 length of key_id as a two-byte unsigned integer. 562 4. Output an ObliviousDoHMessage message Q where Q.message_type = 563 0x01, Q.key_id carries key_id, and Q.encrypted_message = 564 Q_encrypted. 566 The Client then sends Q to the Proxy according to Section 4.1. Once 567 the Client receives a response R, encrypted as specified in 568 Section 8, it uses decrypt_response_body to decrypt 569 R.encrypted_message (using R.key_id as a nonce) and produce R_plain. 570 Clients MUST validate R_plain.padding (as all zeros) before using 571 R_plain.dns_message. 573 8. Oblivious Target Behavior 575 Targets that receive a Query message Q decrypt and process it as 576 follows: 578 1. Look up the ObliviousDoHConfigContents according to Q.key_id. If 579 no such key exists, the Target MAY discard the query, and if so, 580 it MUST return a 401 (Unauthorized) response to the Proxy. 581 Otherwise, let skR be the private key corresponding to this 582 public key, or one chosen for trial decryption. 584 2. Compute context = setup_query_context(skR, Q.key_id, 585 Q.encrypted_message). 587 3. Compute Q_plain, error = decrypt_query_body(context, Q.key_id, 588 Q.encrypted_message). 590 4. If no error was returned, and Q_plain.padding is valid (all 591 zeros), resolve Q_plain.dns_message as needed, yielding a DNS 592 message M. Otherwise, if an error was returned or the padding 593 was invalid, return a 400 (Client Error) response to the Proxy. 595 5. Create an ObliviousDoHResponseBody structure, carrying the 596 message M and padding, to produce R_plain. 598 6. Create a fresh nonce resp_nonce = random(max(Nn, Nk)). 600 7. Compute aead_key, aead_nonce = derive_secrets(context, Q_plain, 601 resp_nonce). 603 8. Compute R_encrypted = encrypt_response_body(R_plain, aead_key, 604 aead_nonce, resp_nonce). The key_id field used for encryption 605 carries resp_nonce in order for Clients to derive the same 606 secrets. Also, the Seal function is that which is associated 607 with the HPKE AEAD. 609 9. Output an ObliviousDoHMessage message R where R.message_type = 610 0x02, R.key_id = resp_nonce, and R.encrypted_message = 611 R_encrypted. 613 The Target then sends R in a 2xx (Successful) response to the Proxy; 614 see Section 4.3. The Proxy forwards the message R without 615 modification back to the Client as the HTTP response to the Client's 616 original HTTP request. In the event of an error (non 2xx status 617 code), the Proxy forwards the Target error to the Client; see 618 Section 4.3. 620 9. Compliance Requirements 622 Oblivious DoH uses HPKE for public key encryption 623 [I-D.irtf-cfrg-hpke]. In the absence of an application profile 624 standard specifying otherwise, a compliant Oblivious DoH 625 implementation MUST support the following HPKE cipher suite: 627 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 628 Section 7.1) 630 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 632 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 634 10. Experiment Overview 636 This document describes an experimental extension to the DoH. The 637 purpose of this experiment is to assess deployment configuration 638 viability and related performance impacts on DNS resolution by 639 measuring key performance indicators such as resolution latency. 640 Experiment participants will test various parameters affecting 641 service operation and performance, including mechanisms for discovery 642 and configuration of DoH Proxies and Targets, as well as performance 643 implications of connection reuse and pools where appropriate. The 644 results of this experiment will be used to influence future protocol 645 design and deployment efforts related to Oblivious DoH, such as 646 Oblivious HTTP [OHTP]. Implementations of DoH that are not involved 647 in the experiment will not recognize this extension and will not 648 participate in the experiment. It is anticipated that use of 649 Oblivious DoH and the duration of this experiment to be widespread. 651 11. Security Considerations 653 Oblivious DoH aims to keep knowledge of the true query origin and its 654 contents known only to Clients. As a simplified model, consider a 655 case where there exists two Clients C1 and C2, one proxy P, and one 656 Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker 657 which can observe all network activity and can adaptively compromise 658 either P or T, but not C1 or C2. Note that compromising both P and T 659 is equivalent to collusion between these two parties in practice. 660 Once compromised, the attacker has access to all session information 661 and private key material. (This generalizes to arbitrarily many 662 Clients, Proxies, and Targets, with the constraints that not all 663 Targets and Proxies are simultaneously compromised, and at least two 664 Clients are left uncompromised.) The attacker is prohibited from 665 sending Client identifying information, such as IP addresses, to 666 Targets. (This would allow the attacker to trivially link a query to 667 the corresponding Client.) 669 In this model, both C1 and C2 send an Oblivious DoH queries Q1 and 670 Q2, respectively, through P to T, and T provides answers A1 and A2. 671 The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), 672 respectively. The attacker succeeds if this linkability is possible 673 without any additional interaction. (For example, if T is 674 compromised, it could return a DNS answer corresponding to an entity 675 it controls, and then observe the subsequent connection from a 676 Client, learning its identity in the process. Such attacks are out 677 of scope for this model.) 679 Oblivious DoH security prevents such linkability. Informally, this 680 means: 682 1. Queries and answers are known only to Clients and Targets in 683 possession of the corresponding response key and HPKE keying 684 material. In particular, Proxies know the origin and destination 685 of an oblivious query, yet do not know the plaintext query. 686 Likewise, Targets know only the oblivious query origin, i.e., the 687 Proxy, and the plaintext query. Only the Client knows both the 688 plaintext query contents and destination. 690 2. Target resolvers cannot link queries from the same Client in the 691 absence of unique per-Client keys. 693 Traffic analysis mitigations are outside the scope of this document. 694 In particular, this document does not prescribe padding lengths for 695 ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations 696 SHOULD follow the guidance for choosing padding length in [RFC8467]. 698 Oblivious DoH security does not depend on Proxy and Target 699 indistinguishability. Specifically, an on-path attacker could 700 determine whether a connection a specific endpoint is used for 701 oblivious or direct DoH queries. However, this has no effect on 702 confidentiality goals listed above. 704 11.1. Denial of Service 706 Malicious clients (or Proxies) can send bogus Oblivious DoH queries 707 to targets as a Denial-of-Service (DoS) attack. Target servers can 708 throttle processing requests if such an event occurs. Additionally, 709 since Targets provide explicit errors upon decryption failure, i.e., 710 if ciphertext decryption fails or if the plaintext DNS message is 711 malformed, Proxies can throttle specific clients in response to these 712 errors. In general, however, Targets trust Proxies to not overwhelm 713 the Target, and it is expected that Proxies either implement some 714 form of rate limiting or client authentication to limit abuse; see 715 Section 11.3. 717 Malicious Targets or Proxies can send bogus answers in response to 718 Oblivious DoH queries. Response decryption failure is a signal that 719 either the Proxy or Target is misbehaving. Clients can choose to 720 stop using one or both of these servers in the event of such failure. 721 However, as above, malicious Targets and Proxies are out of scope for 722 the threat model. 724 11.2. Proxy Policies 726 Proxies are free to enforce any forwarding policy they desire for 727 Clients. For example, they can choose to only forward requests to 728 known or otherwise trusted Targets. 730 Proxies that do not reuse connections to Targets for many Clients may 731 allow Targets to link individual queries to unknown Targets. To 732 mitigate this linkability vector, it is RECOMMENDED that Proxies pool 733 and reuse connections to Targets. Note that this benefits 734 performance as well as privacy since queries do not incur any delay 735 that might otherwise result from Proxy-to-Target connection 736 establishment. 738 11.3. Authentication 740 Depending on the deployment scenario, Proxies and Targets might 741 require authentication before use. Regardless of the authentication 742 mechanism in place, Proxies MUST NOT reveal any Client authentication 743 information to Targets. This is required so Targets cannot uniquely 744 identify individual Clients. 746 Note that if Targets require Proxies to authenticate at the HTTP- or 747 application-layer before use, this ought to be done before attempting 748 to forward any Client query to the Target. This will allow Proxies 749 to distinguish 401 Unauthorized response codes due to authentication 750 failure from 401 Unauthorized response codes due to Client key 751 mismatch; see Section 4.3. 753 11.4. General Proxy Services 755 Using DoH over anonymizing proxy services such as Tor can also 756 achieve the desired goal of separating query origins from their 757 contents. However, there are several reasons why such systems are 758 undesirable in comparison Oblivious DoH: 760 1. Tor is meant to be a generic connection-level anonymity system, 761 and incurs higher latency costs and protocol complexity for the 762 purpose of proxying individual DNS queries. In contrast, 763 Oblivious DoH is a lightweight extension to standard DoH, 764 implemented as an application-layer proxy, that can be enabled as 765 a default mode for users which need increased privacy. 767 2. As a one-hop proxy, Oblivious DoH encourages connection-less 768 proxies to mitigate Client query correlation with few round- 769 trips. In contrast, multi-hop systems such as Tor often run 770 secure connections (TLS) end-to-end, which means that DoH servers 771 could track queries over the same connection. Using a fresh DoH 772 connection per query would incur a non-negligible penalty in 773 connection setup time. 775 12. IANA Considerations 777 This document makes changes to the "Multipurpose Internet Mail 778 Extensions (MIME) and Media Types" registry. The changes are 779 described in the following subsection. 781 12.1. Oblivious DoH Message Media Type 783 This document registers a new media type, "application/oblivious-dns- 784 message". 786 Type name: application 788 Subtype name: oblivious-dns-message 790 Required parameters: N/A 792 Optional parameters: N/A 794 Encoding considerations: This is a binary format, containing 795 encrypted DNS requests and responses encoded as ObliviousDoHMessage 796 values, as defined in this Section 6.1. 798 Security considerations: See this document. The content is an 799 encrypted DNS message, and not executable code. 801 Interoperability considerations: This document specifies format of 802 conforming messages and the interpretation thereof; see Section 6.1. 804 Published specification: This document. 806 Applications that use this media type: This media type is intended to 807 be used by Clients wishing to hide their DNS queries when using DNS 808 over HTTPS. 810 Additional information: N/A 812 Person and email address to contact for further information: See 813 Authors' Addresses section 815 Intended usage: COMMON 817 Restrictions on usage: N/A 819 Author: Tommy Pauly tpauly@apple.com (mailto:tpauly@apple.com) 821 Change controller: Tommy Pauly tpauly@apple.com 822 (mailto:tpauly@apple.com) 824 Provisional registration? (standards tree only): No 826 13. Acknowledgments 828 This work is inspired by Oblivious DNS 829 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 830 that document. Thanks to Nafeez Ahamed, Elliot Briggs, Marwan Fayed, 831 Frederic Jacobs, Tommy Jensen, Jonathan Hoyland, Paul Schmitt, Brian 832 Swander, Erik Nygren, and Peter Wu for the feedback and input. 834 14. References 836 14.1. Normative References 838 [I-D.ietf-httpbis-proxy-status] 839 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 840 Response Header Field", Work in Progress, Internet-Draft, 841 draft-ietf-httpbis-proxy-status-08, 13 October 2021, 842 . 845 [I-D.irtf-cfrg-hpke] 846 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 847 "Hybrid Public Key Encryption", Work in Progress, 848 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 849 . 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 858 "Randomness Requirements for Security", BCP 106, RFC 4086, 859 DOI 10.17487/RFC4086, June 2005, 860 . 862 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 863 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 864 DOI 10.17487/RFC7231, June 2014, 865 . 867 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 868 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 869 RFC 7234, DOI 10.17487/RFC7234, June 2014, 870 . 872 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 873 Protocol (HTTP/1.1): Authentication", RFC 7235, 874 DOI 10.17487/RFC7235, June 2014, 875 . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 882 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 883 . 885 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 886 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 887 October 2018, . 889 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 890 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 891 . 893 14.2. Informative References 895 [I-D.annee-dprive-oblivious-dns] 896 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 897 "Oblivious DNS - Strong Privacy for DNS Queries", Work in 898 Progress, Internet-Draft, draft-annee-dprive-oblivious- 899 dns-00, 2 July 2018, . 902 [OHTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 903 Progress, Internet-Draft, draft-ietf-ohai-ohttp-00, 25 904 November 2021, . 907 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 908 RFC 7239, DOI 10.17487/RFC7239, June 2014, 909 . 911 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 912 Kumari, "Client Subnet in DNS Queries", RFC 7871, 913 DOI 10.17487/RFC7871, May 2016, 914 . 916 Authors' Addresses 918 Eric Kinnear 919 Apple Inc. 920 One Apple Park Way 921 Cupertino, California 95014, 922 United States of America 924 Email: ekinnear@apple.com 926 Patrick McManus 927 Fastly 929 Email: mcmanus@ducksong.com 931 Tommy Pauly 932 Apple Inc. 933 One Apple Park Way 934 Cupertino, California 95014, 935 United States of America 937 Email: tpauly@apple.com 938 Tanya Verma 939 Cloudflare 940 101 Townsend St 941 San Francisco, 942 United States of America 944 Email: vermatanyax@gmail.com 946 Christopher A. Wood 947 Cloudflare 948 101 Townsend St 949 San Francisco, 950 United States of America 952 Email: caw@heapingbits.net