idnits 2.17.1 draft-pauly-dprive-oblivious-doh-11.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 (17 February 2022) is 799 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 7235 (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-ohai-ohttp-01 Summary: 2 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: 21 August 2022 Fastly 6 T. Pauly 7 Apple Inc. 8 T. Verma 9 C.A. Wood 10 Cloudflare 11 17 February 2022 13 Oblivious DNS Over HTTPS 14 draft-pauly-dprive-oblivious-doh-11 16 Abstract 18 This document describes a protocol that allows clients to hide their 19 IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS 20 (DoH) messages. 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 protocol 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 21 August 2022. 45 Copyright Notice 47 Copyright (c) 2022 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 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 12.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 17 85 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 88 14.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Appendix A. Use of Generic Proxy Services . . . . . . . . . . . 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 HTTP messages protected with TLS. This 96 provides improved confidentiality and authentication for DNS 97 interactions in various circumstances. 99 While DoH can prevent eavesdroppers from directly reading the 100 contents of DNS exchanges, clients cannot send DNS queries to and 101 receive answers from servers without revealing their local IP address 102 (and thus information about the identity or location of the client) 103 to the server. 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 protocol built 110 on DoH that permits proxied resolution, in which DNS messages are 111 encrypted so that no 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 EDNS0 Client Subnet option [RFC7871], 118 Section 7.1.2 to provide a hint to the resolver using Oblivious DoH. 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 protocol 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 Proxy: An HTTP server that proxies encrypted DNS queries 141 and responses between a Client and an Oblivious Target, and is 142 identified by a URI template [RFC6570] (see Section 4.1). Note 143 that this Oblivious Proxy is not acting as a full HTTP proxy, but 144 is instead a specialized server used to forward oblivious DNS 145 messages. 147 Oblivious Target: An HTTP server that receives and decrypts 148 encrypted Client DNS queries from an Oblivious Proxy, and returns 149 encrypted DNS responses via that same Proxy. In order to provide 150 DNS responses, the Target can be a DNS resolver, be co-located 151 with a resolver, or forward to a resolver. 153 Throughout the rest of this document, we use the terms Proxy and 154 Target to refer to an Oblivious Proxy and Oblivious Target, 155 respectively. 157 3. Deployment Requirements 159 Oblivious DoH requires, at a minimum: 161 * An Oblivious Proxy server, identified by a URI template. 163 * An Oblivious Target server. The Target and Proxy are expected to 164 be non-colluding (see Section 11). 166 * One or more Target public keys for encrypting DNS queries send to 167 a Target via a Proxy (Section 5). These keys guarantee that only 168 the intended Target can decrypt Client queries. 170 The mechanism for discovering and provisioning the Proxy URI template 171 and Target public keys is out of scope of this document. 173 4. HTTP Exchange 175 Unlike direct resolution, oblivious hostname resolution over DoH 176 involves three parties: 178 1. The Client, which generates queries. 180 2. The Proxy, which receives encrypted queries from the Client and 181 passes them on to a Target. 183 3. The Target, which receives proxied queries from the Client via 184 the Proxy and produces proxied answers. 186 --- [ Request encrypted with Target public key ] --> 187 +---------+ +-----------+ +-----------+ 188 | Client +-------------> Oblivious +-------------> Oblivious | 189 | <-------------+ Proxy <-------------+ Target | 190 +---------+ +-----------+ +-----------+ 191 <-- [ Response encrypted with symmetric key ] --- 193 Figure 1: Obvlivious DoH Exchange 195 4.1. HTTP Request 197 Oblivious DoH queries are created by the Client, and sent to the 198 Proxy as HTTP requests using the POST method. Clients are configured 199 with a Proxy URI Template [RFC6570] and the Target URI. The scheme 200 for both the Proxy URI Template and the Target URI MUST be "https". 201 The Proxy URI Template uses the Level 3 encoding defined in 202 Section 1.2 of [RFC6570], and contains two variables: "targethost", 203 which indicates the host name of the Target server; and "targetpath", 204 which indicates the path on which the Target is accessible. Examples 205 of Proxy URI Templates are shown below: 207 https://dnsproxy.example/dns-query{?targethost,targetpath} 208 https://dnsproxy.example/{targethost}/{targetpath} 210 The URI Template MUST contain both the "targethost" and "targetpath" 211 variables exactly once, and MUST NOT contain any other variables. 212 The variables MUST be within the path or query components of the URI. 213 Clients MUST ignore configurations that do not conform to this 214 template. See Section 4.2 for an example request. 216 Oblivious DoH messages have no cache value since both requests and 217 responses are encrypted using ephemeral key material. Requests and 218 responses MUST NOT be cached. 220 Clients MUST set the HTTP Content-Type header to "application/ 221 oblivious-dns-message" to indicate that this request is an Oblivious 222 DoH query intended for proxying. Clients also SHOULD set this same 223 value for the HTTP Accept header. 225 A correctly encoded request has the HTTP Content-Type header 226 "application/oblivious-dns-message", uses the HTTP POST method, and 227 contains "targethost" and "targetpath" variables. If the Proxy fails 228 to match the "targethost" and "targetpath" variables from the path, 229 it MUST treat the request as malformed. The Proxy constructs the URI 230 of the Target with the "https" scheme, using the value of 231 "targethost" as the URI host, and the percent-decoded value of 232 "targetpath" as the URI path. Proxies MUST check that Client 233 requests are correctly encoded, and MUST return a 4xx (Client Error) 234 if the check fails, along with the Proxy-Status response header with 235 an "error" parameter of type "http_request_error" 236 [I-D.ietf-httpbis-proxy-status]. 238 Proxies MAY choose to not forward connections to non-standard ports. 239 In such cases, Proxies can indicate the error with a 403 response 240 status code, along with a Proxy-Status response header with an 241 "error" parameter of type "http_request_denied", along with an 242 appropriate explanation in "details". 244 If the Proxy cannot establish a connection to the Target, it can 245 indicate the error with a 502 response status code, along with a 246 Proxy-Status response header with an "error" parameter whose type 247 indicates the reason. For example, if DNS resolution fails, the 248 error type might be "dns_timeout", whereas if the TLS connection 249 failed the error type might be "tls_protocol_error". 251 Upon receipt of requests from a Proxy, Targets MUST validate that the 252 request has the HTTP Content-Type header "application/oblivious-dns- 253 message" and uses the HTTP POST method. Targets can respond with a 254 4xx response status code if this check fails. 256 4.2. HTTP Request Example 258 The following example shows how a Client requests that a Proxy, 259 "dnsproxy.example", forwards an encrypted message to 260 "dnstarget.example". The URI Template for the Proxy is 261 "https://dnsproxy.example/dns-query{?targethost,targetpath}". The 262 URI for the Target is "https://dnstarget.example/dns-query". 264 :method = POST 265 :scheme = https 266 :authority = dnsproxy.example 267 :path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query 268 accept = application/oblivious-dns-message 269 content-type = application/oblivious-dns-message 270 content-length = 106 272 274 The Proxy then sends the following request on to the Target: 276 :method = POST 277 :scheme = https 278 :authority = dnstarget.example 279 :path = /dns-query 280 accept = application/oblivious-dns-message 281 content-type = application/oblivious-dns-message 282 content-length = 106 284 286 4.3. HTTP Response 288 The response to an Oblivious DoH query is generated by the Target. 289 It MUST set the Content-Type HTTP header to "application/oblivious- 290 dns-message" for all successful responses. The body of the response 291 contains an encrypted DNS message; see Section 6. 293 The response from a Target MUST set the Content-Type HTTP header to 294 "application/oblivious-dns-message" which MUST be forwarded by the 295 Proxy to the Client. A Client MUST only consider a response which 296 contains the Content-Type header in the response before processing 297 the payload. A response without the appropriate header MUST be 298 treated as an error and be handled appropriately. All other aspects 299 of the HTTP response and error handling are inherited from standard 300 DoH. 302 Proxies forward responses from the Target to client, without any 303 modifications to the body or status code. The Proxy also SHOULD add 304 a Proxy-Status response header with an "received-status" parameter 305 indicating that the status code was generated by the Target. 307 Note that if a Client receives a 3xx status code and chooses to 308 follow a redirect, the subsequent request MUST also be performed 309 through a Proxy in order to avoid directly exposing requests to the 310 Target. 312 Requests that cannot be processed by the Target result in 4xx (Client 313 Error) responses. If the Target and Client keys do not match, it is 314 an authorization failure (HTTP status code 401; see Section 3.1 of 315 [RFC7235]). Otherwise, if the Client's request is invalid, such as 316 in the case of decryption failure, wrong message type, or 317 deserialization failure, this is a bad request (HTTP status code 400; 318 see Section 6.5.1 of [RFC7231]). 320 Even in case of DNS responses indicating failure, such as SERVFAIL or 321 NXDOMAIN, a successful HTTP response with a 2xx status code is used 322 as long as the DNS response is valid. This is identical to how DoH 323 [RFC8484] handles HTTP response codes. 325 4.4. HTTP Response Example 327 The following example shows a 2xx (Successful) response that can be 328 sent from a Target to a Client via a Proxy. 330 :status = 200 331 content-type = application/oblivious-dns-message 332 content-length = 154 334 336 4.5. HTTP Metadata 338 Proxies forward requests and responses between Clients and Targets as 339 specified in Section 4.1. Metadata sent with these messages could 340 inadvertently weaken or remove Oblivious DoH privacy properties. 341 Proxies MUST NOT send any Client-identifying information about 342 Clients to Targets, such as "Forwarded" HTTP headers [RFC7239]. 343 Additionally, Clients MUST NOT include any private state in requests 344 to Proxies, such as HTTP cookies. See Section 11.3 for related 345 discussion about Client authentication information. 347 5. Configuration and Public Key Format 349 In order send a message to a Target, the Client needs to know a 350 public key to use for encrypting its queries. The mechanism for 351 discovering this configuration is out of scope of this document. 353 Servers ought to rotate public keys regularly. It is RECOMMENDED 354 that servers rotate keys every day. Shorter rotation windows reduce 355 the anonymity set of Clients that might use the public key, whereas 356 longer rotation windows widen the timeframe of possible compromise. 358 An Oblivious DNS public key configuration is a structure encoded, 359 using TLS-style encoding [RFC8446], as follows: 361 struct { 362 uint16 kem_id; 363 uint16 kdf_id; 364 uint16 aead_id; 365 opaque public_key<1..2^16-1>; 366 } ObliviousDoHConfigContents; 368 struct { 369 uint16 version; 370 uint16 length; 371 select (ObliviousDoHConfig.version) { 372 case 0x0001: ObliviousDoHConfigContents contents; 373 } 374 } ObliviousDoHConfig; 376 ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; 378 The ObliviousDoHConfigs structure contains one or more 379 ObliviousDoHConfig structures in decreasing order of preference. 380 This allows a server to support multiple versions of Oblivious DoH 381 and multiple sets of Oblivious DoH parameters. 383 An ObliviousDoHConfig contains a versioned representation of an 384 Oblivious DoH configuration, with the following fields. 386 version The version of Oblivious DoH for which this configuration is 387 used. Clients MUST ignore any ObliviousDoHConfig structure with a 388 version they do not support. The version of Oblivious DoH 389 specified in this document is 0x0001. 391 length The length, in bytes, of the next field. 393 contents An opaque byte string whose contents depend on the version. 394 For this specification, the contents are an 395 ObliviousDoHConfigContents structure. 397 An ObliviousDoHConfigContents contains the information needed to 398 encrypt a message under ObliviousDoHConfigContents.public_key such 399 that only the owner of the corresponding private key can decrypt the 400 message. The values for ObliviousDoHConfigContents.kem_id, 401 ObliviousDoHConfigContents.kdf_id, and 402 ObliviousDoHConfigContents.aead_id are described in Section 7 of 403 [HPKE]. The fields in this structure are as follows: 405 kem_id The HPKE KEM identifier corresponding to public_key. Clients 406 MUST ignore any ObliviousDoHConfig structure with a key using a 407 KEM they do not support. 409 kdf_id The HPKE KDF identifier corresponding to public_key. Clients 410 MUST ignore any ObliviousDoHConfig structure with a key using a 411 KDF they do not support. 413 aead_id The HPKE AEAD identifier corresponding to public_key. 414 Clients MUST ignore any ObliviousDoHConfig structure with a key 415 using an AEAD they do not support. 417 public_key The HPKE public key used by the Client to encrypt 418 Oblivious DoH queries. 420 6. Protocol Encoding 422 This section includes encoding and wire format details for Oblivious 423 DoH, as well as routines for encrypting and decrypting encoded 424 values. 426 6.1. Message Format 428 There are two types of Oblivious DoH messages: Queries (0x01) and 429 Responses (0x02). Both messages carry the following information: 431 1. A DNS message, which is either a Query or Response, depending on 432 context. 434 2. Padding of arbitrary length which MUST contain all zeros. 436 They are encoded using the following structure: 438 struct { 439 opaque dns_message<1..2^16-1>; 440 opaque padding<0..2^16-1>; 441 } ObliviousDoHMessagePlaintext; 443 Both Query and Response messages use the ObliviousDoHMessagePlaintext 444 format. 446 ObliviousDoHMessagePlaintext ObliviousDoHQuery; 447 ObliviousDoHMessagePlaintext ObliviousDoHResponse; 449 An encrypted ObliviousDoHMessagePlaintext is carried in a 450 ObliviousDoHMessage message, encoded as follows: 452 struct { 453 uint8 message_type; 454 opaque key_id<0..2^16-1>; 455 opaque encrypted_message<1..2^16-1>; 456 } ObliviousDoHMessage; 458 The ObliviousDoHMessage structure contains the following fields: 460 message_type A one-byte identifier for the type of message. Query 461 messages use message_type 0x01, and Response messages use 462 message_type 0x02. 464 key_id The identifier of the corresponding 465 ObliviousDoHConfigContents key. This is computed as 466 Expand(Extract("", config), "odoh key id", Nh), where config is 467 the ObliviousDoHConfigContents structure and Extract, Expand, and 468 Nh are as specified by the HPKE cipher suite KDF corresponding to 469 config.kdf_id. 471 encrypted_message An encrypted message for the Oblivious Target (for 472 Query messages) or Client (for Response messages). 473 Implementations MAY enforce limits on the size of this field 474 depending on the size of plaintext DNS messages. (DNS queries, 475 for example, will not reach the size limit of 2^16-1 in practice.) 477 The contents of ObliviousDoHMessage.encrypted_message depend on 478 ObliviousDoHMessage.message_type. In particular, 479 ObliviousDoHMessage.encrypted_message is an encryption of a 480 ObliviousDoHQuery if the message is a Query, and ObliviousDoHResponse 481 if the message is a Response. 483 6.2. Encryption and Decryption Routines 485 Clients use the following utility functions for encrypting a Query 486 and decrypting a Response as described in Section 7. 488 encrypt_query_body: Encrypt an Oblivious DoH query. 490 def encrypt_query_body(pkR, key_id, Q_plain): 491 enc, context = SetupBaseS(pkR, "odoh query") 492 aad = 0x01 || len(key_id) || key_id 493 ct = context.Seal(aad, Q_plain) 494 Q_encrypted = enc || ct 495 return Q_encrypted 497 decrypt_response_body: Decrypt an Oblivious DoH response. 499 def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce): 500 aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce) 501 aad = 0x02 || len(resp_nonce) || resp_nonce 502 R_plain, error = Open(key, nonce, aad, R_encrypted) 503 return R_plain, error 505 The derive_secrets function is described below. 507 Targets use the following utility functions in processing queries and 508 producing responses as described in Section 8. 510 setup_query_context: Set up an HPKE context used for decrypting an 511 Oblivious DoH query. 513 def setup_query_context(skR, key_id, Q_encrypted): 514 enc || ct = Q_encrypted 515 context = SetupBaseR(enc, skR, "odoh query") 516 return context 518 decrypt_query_body: Decrypt an Oblivious DoH query. 520 def decrypt_query_body(context, key_id, Q_encrypted): 521 aad = 0x01 || len(key_id) || key_id 522 enc || ct = Q_encrypted 523 Q_plain, error = context.Open(aad, ct) 524 return Q_plain, error 526 derive_secrets: Derive keying material used for encrypting an 527 Oblivious DoH response. 529 def derive_secrets(context, Q_plain, resp_nonce): 530 secret = context.Export("odoh response", Nk) 531 salt = Q_plain || len(resp_nonce) || resp_nonce 532 prk = Extract(salt, secret) 533 key = Expand(odoh_prk, "odoh key", Nk) 534 nonce = Expand(odoh_prk, "odoh nonce", Nn) 535 return key, nonce 537 The random(N) function returns N cryptographically secure random 538 bytes from a good source of entropy [RFC4086]. The max(A, B) 539 function returns A if A > B, and B otherwise. 541 encrypt_response_body: Encrypt an Oblivious DoH response. 543 def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce): 544 aad = 0x02 || len(resp_nonce) || resp_nonce 545 R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain) 546 return R_encrypted 548 7. Oblivious Client Behavior 550 Let M be a DNS message (query) a Client wishes to protect with 551 Oblivious DoH. When sending an Oblivious DoH Query for resolving M 552 to an Oblivious Target with ObliviousDoHConfigContents config, a 553 Client does the following: 555 1. Create an ObliviousDoHQuery structure, carrying the message M and 556 padding, to produce Q_plain. 558 2. Deserialize config.public_key to produce a public key pkR of type 559 config.kem_id. 561 3. Compute the encrypted message as Q_encrypted = 562 encrypt_query_body(pkR, key_id, Q_plain), where key_id is as 563 computed in Section 6. Note also that len(key_id) outputs the 564 length of key_id as a two-byte unsigned integer. 566 4. Output an ObliviousDoHMessage message Q where Q.message_type = 567 0x01, Q.key_id carries key_id, and Q.encrypted_message = 568 Q_encrypted. 570 The Client then sends Q to the Proxy according to Section 4.1. Once 571 the Client receives a response R, encrypted as specified in 572 Section 8, it uses decrypt_response_body to decrypt 573 R.encrypted_message (using R.key_id as a nonce) and produce R_plain. 574 Clients MUST validate R_plain.padding (as all zeros) before using 575 R_plain.dns_message. 577 8. Oblivious Target Behavior 579 Targets that receive a Query message Q decrypt and process it as 580 follows: 582 1. Look up the ObliviousDoHConfigContents according to Q.key_id. If 583 no such key exists, the Target MAY discard the query, and if so, 584 it MUST return a 401 (Unauthorized) response to the Proxy. 585 Otherwise, let skR be the private key corresponding to this 586 public key, or one chosen for trial decryption. 588 2. Compute context = setup_query_context(skR, Q.key_id, 589 Q.encrypted_message). 591 3. Compute Q_plain, error = decrypt_query_body(context, Q.key_id, 592 Q.encrypted_message). 594 4. If no error was returned, and Q_plain.padding is valid (all 595 zeros), resolve Q_plain.dns_message as needed, yielding a DNS 596 message M. Otherwise, if an error was returned or the padding 597 was invalid, return a 400 (Client Error) response to the Proxy. 599 5. Create an ObliviousDoHResponseBody structure, carrying the 600 message M and padding, to produce R_plain. 602 6. Create a fresh nonce resp_nonce = random(max(Nn, Nk)). 604 7. Compute aead_key, aead_nonce = derive_secrets(context, Q_plain, 605 resp_nonce). 607 8. Compute R_encrypted = encrypt_response_body(R_plain, aead_key, 608 aead_nonce, resp_nonce). The key_id field used for encryption 609 carries resp_nonce in order for Clients to derive the same 610 secrets. Also, the Seal function is that which is associated 611 with the HPKE AEAD. 613 9. Output an ObliviousDoHMessage message R where R.message_type = 614 0x02, R.key_id = resp_nonce, and R.encrypted_message = 615 R_encrypted. 617 The Target then sends R in a 2xx (Successful) response to the Proxy; 618 see Section 4.3. The Proxy forwards the message R without 619 modification back to the Client as the HTTP response to the Client's 620 original HTTP request. In the event of an error (non 2xx status 621 code), the Proxy forwards the Target error to the Client; see 622 Section 4.3. 624 9. Compliance Requirements 626 Oblivious DoH uses HPKE for public key encryption [HPKE]. In the 627 absence of an application profile standard specifying otherwise, a 628 compliant Oblivious DoH implementation MUST support the following 629 HPKE cipher suite: 631 * KEM: DHKEM(X25519, HKDF-SHA256) (see [HPKE], Section 7.1) 633 * KDF: HKDF-SHA256 (see [HPKE], Section 7.2) 635 * AEAD: AES-128-GCM (see [HPKE], Section 7.3) 637 10. Experiment Overview 639 This document describes an experimental protocol built on DoH. The 640 purpose of this experiment is to assess deployment configuration 641 viability and related performance impacts on DNS resolution by 642 measuring key performance indicators such as resolution latency. 643 Experiment participants will test various parameters affecting 644 service operation and performance, including mechanisms for discovery 645 and configuration of DoH Proxies and Targets, as well as performance 646 implications of connection reuse and pools where appropriate. The 647 results of this experiment will be used to influence future protocol 648 design and deployment efforts related to Oblivious DoH, such as 649 Oblivious HTTP [OHTP]. Implementations of DoH that are not involved 650 in the experiment will not recognize this protocol and will not 651 participate in the experiment. It is anticipated that use of 652 Oblivious DoH and the duration of this experiment to be widespread. 654 11. Security Considerations 656 Oblivious DoH aims to keep knowledge of the true query origin and its 657 contents known only to Clients. As a simplified model, consider a 658 case where there exists two Clients C1 and C2, one proxy P, and one 659 Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker 660 which can observe all network activity and can adaptively compromise 661 either P or T, but not C1 or C2. Note that compromising both P and T 662 is equivalent to collusion between these two parties in practice. 663 Once compromised, the attacker has access to all session information 664 and private key material. (This generalizes to arbitrarily many 665 Clients, Proxies, and Targets, with the constraints that not all 666 Targets and Proxies are simultaneously compromised, and at least two 667 Clients are left uncompromised.) The attacker is prohibited from 668 sending Client identifying information, such as IP addresses, to 669 Targets. (This would allow the attacker to trivially link a query to 670 the corresponding Client.) 672 In this model, both C1 and C2 send an Oblivious DoH queries Q1 and 673 Q2, respectively, through P to T, and T provides answers A1 and A2. 674 The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), 675 respectively. The attacker succeeds if this linkability is possible 676 without any additional interaction. (For example, if T is 677 compromised, it could return a DNS answer corresponding to an entity 678 it controls, and then observe the subsequent connection from a 679 Client, learning its identity in the process. Such attacks are out 680 of scope for this model.) 682 Oblivious DoH security prevents such linkability. Informally, this 683 means: 685 1. Queries and answers are known only to Clients and Targets in 686 possession of the corresponding response key and HPKE keying 687 material. In particular, Proxies know the origin and destination 688 of an oblivious query, yet do not know the plaintext query. 689 Likewise, Targets know only the oblivious query origin, i.e., the 690 Proxy, and the plaintext query. Only the Client knows both the 691 plaintext query contents and destination. 693 2. Target resolvers cannot link queries from the same Client in the 694 absence of unique per-Client keys. 696 Traffic analysis mitigations are outside the scope of this document. 697 In particular, this document does not prescribe padding lengths for 698 ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations 699 SHOULD follow the guidance for choosing padding length in [RFC8467]. 701 Oblivious DoH security does not depend on Proxy and Target 702 indistinguishability. Specifically, an on-path attacker could 703 determine whether a connection a specific endpoint is used for 704 oblivious or direct DoH queries. However, this has no effect on 705 confidentiality goals listed above. 707 11.1. Denial of Service 709 Malicious clients (or Proxies) can send bogus Oblivious DoH queries 710 to targets as a Denial-of-Service (DoS) attack. Target servers can 711 throttle processing requests if such an event occurs. Additionally, 712 since Targets provide explicit errors upon decryption failure, i.e., 713 if ciphertext decryption fails or if the plaintext DNS message is 714 malformed, Proxies can throttle specific clients in response to these 715 errors. In general, however, Targets trust Proxies to not overwhelm 716 the Target, and it is expected that Proxies either implement some 717 form of rate limiting or client authentication to limit abuse; see 718 Section 11.3. 720 Malicious Targets or Proxies can send bogus answers in response to 721 Oblivious DoH queries. Response decryption failure is a signal that 722 either the Proxy or Target is misbehaving. Clients can choose to 723 stop using one or both of these servers in the event of such failure. 724 However, as above, malicious Targets and Proxies are out of scope for 725 the threat model. 727 11.2. Proxy Policies 729 Proxies are free to enforce any forwarding policy they desire for 730 Clients. For example, they can choose to only forward requests to 731 known or otherwise trusted Targets. 733 Proxies that do not reuse connections to Targets for many Clients may 734 allow Targets to link individual queries to unknown Targets. To 735 mitigate this linkability vector, it is RECOMMENDED that Proxies pool 736 and reuse connections to Targets. Note that this benefits 737 performance as well as privacy since queries do not incur any delay 738 that might otherwise result from Proxy-to-Target connection 739 establishment. 741 11.3. Authentication 743 Depending on the deployment scenario, Proxies and Targets might 744 require authentication before use. Regardless of the authentication 745 mechanism in place, Proxies MUST NOT reveal any Client authentication 746 information to Targets. This is required so Targets cannot uniquely 747 identify individual Clients. 749 Note that if Targets require Proxies to authenticate at the HTTP- or 750 application-layer before use, this ought to be done before attempting 751 to forward any Client query to the Target. This will allow Proxies 752 to distinguish 401 Unauthorized response codes due to authentication 753 failure from 401 Unauthorized response codes due to Client key 754 mismatch; see Section 4.3. 756 12. IANA Considerations 758 This document makes changes to the "Multipurpose Internet Mail 759 Extensions (MIME) and Media Types" registry. The changes are 760 described in the following subsection. 762 12.1. Oblivious DoH Message Media Type 764 This document registers a new media type, "application/oblivious-dns- 765 message". 767 Type name: application 769 Subtype name: oblivious-dns-message 771 Required parameters: N/A 773 Optional parameters: N/A 775 Encoding considerations: This is a binary format, containing 776 encrypted DNS requests and responses encoded as ObliviousDoHMessage 777 values, as defined in Section 6.1. 779 Security considerations: See this document. The content is an 780 encrypted DNS message, and not executable code. 782 Interoperability considerations: This document specifies format of 783 conforming messages and the interpretation thereof; see Section 6.1. 785 Published specification: This document. 787 Applications that use this media type: This media type is intended to 788 be used by Clients wishing to hide their DNS queries when using DNS 789 over HTTPS. 791 Additional information: N/A 793 Person and email address to contact for further information: See 794 Authors' Addresses section 796 Intended usage: COMMON 798 Restrictions on usage: N/A 800 Author: Tommy Pauly tpauly@apple.com (mailto:tpauly@apple.com) 802 Change controller: IETF 803 Provisional registration? (standards tree only): No 805 13. Acknowledgments 807 This work is inspired by Oblivious DNS 808 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 809 that document. Thanks to Nafeez Ahamed, Elliot Briggs, Marwan Fayed, 810 Frederic Jacobs, Tommy Jensen, Jonathan Hoyland, Paul Schmitt, Brian 811 Swander, Erik Nygren, and Peter Wu for the feedback and input. 813 14. References 815 14.1. Normative References 817 [HPKE] Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 818 "Hybrid Public Key Encryption", Work in Progress, 819 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 820 . 823 [I-D.ietf-httpbis-proxy-status] 824 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 825 Response Header Field", Work in Progress, Internet-Draft, 826 draft-ietf-httpbis-proxy-status-08, 13 October 2021, 827 . 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, 832 DOI 10.17487/RFC2119, March 1997, 833 . 835 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 836 "Randomness Requirements for Security", BCP 106, RFC 4086, 837 DOI 10.17487/RFC4086, June 2005, 838 . 840 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 841 and D. Orchard, "URI Template", RFC 6570, 842 DOI 10.17487/RFC6570, March 2012, 843 . 845 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 846 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 847 DOI 10.17487/RFC7231, June 2014, 848 . 850 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 851 Protocol (HTTP/1.1): Authentication", RFC 7235, 852 DOI 10.17487/RFC7235, June 2014, 853 . 855 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 856 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 857 May 2017, . 859 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 860 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 861 . 863 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 864 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 865 October 2018, . 867 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 868 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 869 . 871 14.2. Informative References 873 [I-D.annee-dprive-oblivious-dns] 874 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 875 "Oblivious DNS - Strong Privacy for DNS Queries", Work in 876 Progress, Internet-Draft, draft-annee-dprive-oblivious- 877 dns-00, 2 July 2018, . 880 [OHTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in 881 Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15 882 February 2022, . 885 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 886 RFC 7239, DOI 10.17487/RFC7239, June 2014, 887 . 889 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 890 Kumari, "Client Subnet in DNS Queries", RFC 7871, 891 DOI 10.17487/RFC7871, May 2016, 892 . 894 Appendix A. Use of Generic Proxy Services 896 Using DoH over anonymizing proxy services such as Tor can also 897 achieve the desired goal of separating query origins from their 898 contents. However, there are several reasons why such systems are 899 undesirable in comparison Oblivious DoH: 901 1. Tor is meant to be a generic connection-level anonymity system, 902 and incurs higher latency costs and protocol complexity for the 903 purpose of proxying individual DNS queries. In contrast, 904 Oblivious DoH is a lightweight protocol built on DoH, implemented 905 as an application-layer proxy, that can be enabled as a default 906 mode for users which need increased privacy. 908 2. As a one-hop proxy, Oblivious DoH encourages connection-less 909 proxies to mitigate Client query correlation with few round- 910 trips. In contrast, multi-hop systems such as Tor often run 911 secure connections (TLS) end-to-end, which means that DoH servers 912 could track queries over the same connection. Using a fresh DoH 913 connection per query would incur a non-negligible penalty in 914 connection setup time. 916 Authors' Addresses 918 Eric Kinnear 919 Apple Inc. 920 One Apple Park Way 921 Cupertino, California 95014, 922 United States of America 923 Email: ekinnear@apple.com 925 Patrick McManus 926 Fastly 927 Email: mcmanus@ducksong.com 929 Tommy Pauly 930 Apple Inc. 931 One Apple Park Way 932 Cupertino, California 95014, 933 United States of America 934 Email: tpauly@apple.com 935 Tanya Verma 936 Cloudflare 937 101 Townsend St 938 San Francisco, 939 United States of America 940 Email: vermatanyax@gmail.com 942 Christopher A. Wood 943 Cloudflare 944 101 Townsend St 945 San Francisco, 946 United States of America 947 Email: caw@heapingbits.net