idnits 2.17.1 draft-pauly-dprive-oblivious-doh-03.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 December 2020) is 1239 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) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-02 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-06 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Experimental RFC: RFC 8467 Summary: 5 errors (**), 0 flaws (~~), 3 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: Standards Track P. McManus 5 Expires: 5 June 2021 Fastly 6 T. Pauly 7 Apple Inc. 8 C.A. Wood 9 Cloudflare 10 2 December 2020 12 Oblivious DNS Over HTTPS 13 draft-pauly-dprive-oblivious-doh-03 15 Abstract 17 This document describes an extension to DNS Over HTTPS (DoH) that 18 allows hiding client IP addresses via proxying encrypted DNS 19 transactions. This improves privacy of DNS operations by not 20 allowing any one server entity to be aware of both the client IP 21 address and the content of DNS queries and answers. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 June 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 3 60 4. HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. HTTP Request Example . . . . . . . . . . . . . . . . . . 5 63 4.3. HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. HTTP Response Example . . . . . . . . . . . . . . . . . . 6 65 5. Configuration and Public Key Discovery . . . . . . . . . . . 7 66 6. Configuration and Public Key Format . . . . . . . . . . . . . 7 67 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 8 69 7.2. Encryption and Decryption Routines . . . . . . . . . . . 9 70 8. Oblivious Client Behavior . . . . . . . . . . . . . . . . . . 11 71 9. Oblivious Target Behavior . . . . . . . . . . . . . . . . . . 11 72 10. Compliance Requirements . . . . . . . . . . . . . . . . . . . 12 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 11.1. Denial of Service . . . . . . . . . . . . . . . . . . . 14 75 11.2. General Proxy Services . . . . . . . . . . . . . . . . . 14 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 12.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 14 78 12.2. Oblivious DoH Public Key DNS Parameter . . . . . . . . . 15 79 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 14.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 88 messages to be transmitted in encrypted HTTP messages. This provides 89 improved confidentiality and authentication for DNS interactions in 90 various circumstances. 92 While DoH can prevent eavesdroppers from directly reading the 93 contents of DNS exchanges, clients cannot send DNS queries and 94 receive answers from servers without revealing their local IP 95 address, and thus information about the identity or location of the 96 client. 98 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 99 increase privacy by ensuring no single DNS server is aware of both 100 the client IP address and the message contents. 102 This document defines Oblivious DoH, an extension to DoH that permits 103 proxied resolution, in which DNS messages are encrypted so that no 104 DoH server can independently read both the client IP address and the 105 DNS message contents. 107 This mechanism is intended to be used as one option for resolving 108 privacy-sensitive content in the broader context of Adaptive DNS 109 [I-D.pauly-dprive-adaptive-dns-privacy]. 111 1.1. Specification of Requirements 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 2. Terminology 121 This document defines the following terms: 123 Oblivious Server: A DoH server that acts as either an Oblivious 124 Proxy or Oblivious Target. 126 Oblivious Proxy: An Oblivious Server that proxies encrypted DNS 127 queries and responses between a client and an Oblivious Target. 129 Oblivious Target: An Oblivious Server that receives and decrypts 130 encrypted client DNS queries from an Oblivious Proxy, and returns 131 encrypted DNS responses via that same Proxy. In order to provide 132 DNS responses, the Target can be a DNS resolver, be co-located 133 with a resolver, or forward to a resolver. 135 Throughout the rest of this document, we use the terms Proxy and 136 Target to refer to an Oblivious Proxy and Oblivious Target, 137 respectively. 139 3. Deployment Requirements 141 Oblivious DoH requires, at a minimum: 143 * Two Oblivious Servers, where one can act as a Proxy, and the other 144 can act as a Target. 146 * Public keys for encrypting DNS queries that are passed from a 147 client through a Proxy to a Target (Section 6). These keys 148 guarantee that only the intended Target can decrypt client 149 queries. 151 The mechanism for discovering and provisioning the DoH URI Templates 152 and public keys is via parameters added to DNS resource records. The 153 mechanism for discovering the public key is described in Section 5. 154 The mechanism for discovering a DoH URI Template is described in 155 [I-D.pauly-add-resolver-discovery]. 157 4. HTTP Exchange 159 Unlike direct resolution, oblivious hostname resolution over DoH 160 involves three parties: 162 1. The Client, which generates queries. 164 2. The Proxy, which receives encrypted queries from the client and 165 passes them on to a Target. 167 3. The Target, which receives proxied queries from the client via 168 the Proxy and produces proxied answers. 170 --- [ Request encrypted with target public key ] --> 171 +---------+ +-----------+ +-----------+ 172 | Client +-------------> Oblivious +-------------> Oblivious | 173 | <-------------+ Proxy <-------------+ Target | 174 +---------+ +-----------+ +-----------+ 175 <-- [ Response encrypted with client symmetric key ] --- 177 Figure 1: Obvlivious DoH Exchange 179 4.1. HTTP Request 181 Oblivious DoH queries are created by the Client, and sent to the 182 Proxy. Requests to the Proxy indicate which DoH server to use as a 183 Target by specifying two variables: "targethost", which indicates the 184 host name of the Target server, and "targetpath", which indicates the 185 path on which the Target's DoH server is running. See Section 4.2 186 for an example request. 188 Oblivious DoH messages have no cache value since both requests and 189 responses are encrypted using ephemeral key material. Clients SHOULD 190 prefer using HTTP methods and headers that will prevent unhelpful 191 cache storage of these exchanges (i.e., preferring POST instead of 192 GET). 194 Clients MUST set the HTTP Content-Type header to "application/ 195 oblivious-dns-message" to indicate that this request is an Oblivious 196 DoH query intended for proxying. Clients also SHOULD set this same 197 value for the HTTP Accept header. 199 Upon receiving a request that contains a "application/oblivious-dns- 200 message" Content-Type, the DoH server looks for the "targethost" and 201 "targetpath" variables. If the variables are not present, then it is 202 the target of the query, and it can decrypt the query (Section 7). 203 If the variables are present, then the DoH server is acting as a 204 Proxy. If it is a proxy, it is expected to send the request on to 205 the Target using the URI template constructed as "https://targethost/ 206 targetpath". 208 4.2. HTTP Request Example 210 The following example shows how a client requests that a Proxy, 211 "dnsproxy.example.net", forwards an encrypted message to 212 "dnstarget.example.net". The URI template for the Proxy is 213 "https://dnsproxy.example.net/dns-query{?targethost,targetpath}". 214 The URI template for the Target is "https://dnstarget.example.net/ 215 dns-query". 217 :method = POST 218 :scheme = https 219 :authority = dnsproxy.example.net 220 :path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query 221 accept = application/oblivious-dns-message 222 cache-control = no-cache, no-store 223 content-type = application/oblivious-dns-message 224 content-length = 106 226 228 The Proxy then sends the following request on to the Target: 230 :method = POST 231 :scheme = https 232 :authority = dnstarget.example.net 233 :path = /dns-query 234 accept = application/oblivious-dns-message 235 cache-control = no-cache, no-store 236 content-type = application/oblivious-dns-message 237 content-length = 106 239 241 4.3. HTTP Response 243 The response to an Oblivious DoH query is generated by the Target. 244 It MUST set the Content-Type HTTP header to "application/oblivious- 245 dns-message" for all successful responses. The body of the response 246 contains a DNS message that is encrypted with the client's symmetric 247 key (Section 7). 249 The response from a Target MUST set the Content-Type HTTP header to 250 "application/oblivious-dns-message" which MUST be forwarded by the 251 Proxy to the Client. A Client MUST only consider a response which 252 contains the Content-Type header in the response before processing 253 the payload. A response without the appropriate header MUST be 254 treated as an error and be handled appropriately. All other aspects 255 of the HTTP response and error handling are inherited from standard 256 DoH. 258 4.4. HTTP Response Example 260 The following example shows a 2xx (Successful) response that can be 261 sent from a Target to a client via a Proxy. 263 :status = 200 264 content-type = application/oblivious-dns-message 265 content-length = 154 267 269 Requests that cannot be processed by the target result in 4xx (Client 270 Error) responses. If the target and client keys do not match, it is 271 an authorization failure (HTTP status code 401; see Section 3.1 of 272 [RFC7235]). Otherwise, if the client's request is invalid, such as 273 in the case of decryption failure, wrong message type, or 274 deserialization failure, this is a bad request (HTTP status code 400; 275 see Section 6.5.1 of [RFC7231]). 277 Even in case of DNS responses indicating failure, such as SERVFAIL or 278 NXDOMAIN, a successful HTTP response with a 2xx status code is used 279 as long as the DNS response is valid. This is similar to how DoH 280 [RFC8484] handles HTTP response codes. 282 In case of server error, the usual HTTP status code 500 (see 283 Section 6.6.1 of [RFC7231]) applies. 285 5. Configuration and Public Key Discovery 287 In order to use a DoH server as a Target, the client must know a 288 public key to use for encrypting its queries. This key can be 289 discovered using the SVCB or HTTPSSVC record type 290 ([I-D.ietf-dnsop-svcb-https]) for a name owned by the server. 292 The Service Binding key name is "odohconfig" (Section 12). If 293 present, this key/value pair contains the public key to use when 294 encrypting Oblivious DoH messages that will be targeted at a DoH 295 server. The format of the key is defined in (Section 6). 297 Clients MUST only use keys that were retrieved from records protected 298 by DNSSEC [RFC4033] to encrypt messages to a Target. 300 6. Configuration and Public Key Format 302 An Oblivious DNS public key configuration is a structure encoded, 303 using TLS-style encoding [RFC8446], as follows: 305 struct { 306 uint16 kem_id; 307 uint16 kdf_id; 308 uint16 aead_id; 309 opaque public_key<1..2^16-1>; 310 } ObliviousDoHConfigContents; 312 struct { 313 uint16 version; 314 uint16 length; 315 select (ObliviousDoHConfig.version) { 316 case 0xff03: ObliviousDoHConfigContents contents; 317 } 318 } ObliviousDoHConfig; 320 ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; 322 The "ObliviousDoHConfigs" structure contains one or more 323 "ObliviousDoHConfig" structures in decreasing order of preference. 324 This allows a server to support multiple versions of Oblivious DoH 325 and multiple sets of Oblivious DoH parameters. 327 An "ObliviousDoHConfig" contains a versioned representation of an 328 Oblivious DoH configuration, with the following fields. 330 version The version of Oblivious DoH for which this configuration is 331 used. Clients MUST ignore any "ObliviousDoHConfig" structure with 332 a version they do not support. The version of Oblivious DoH 333 specified in this document is "0xff03". 335 length The length, in bytes, of the next field. 337 contents An opaque byte string whose contents depend on the version. 338 For this specification, the contents are an 339 "ObliviousDoHConfigContents" structure. 341 An "ObliviousDoHConfigContents" contains the information needed to 342 encrypt a message under "ObliviousDoHConfigContents.public_key" such 343 that only the owner of the corresponding private key can decrypt the 344 message. The values for "ObliviousDoHConfigContents.kem_id", 345 "ObliviousDoHConfigContents.kdf_id", and 346 "ObliviousDoHConfigContents.aead_id" are described in 347 [I-D.irtf-cfrg-hpke] Section 7. The fields in this structure are as 348 follows: 350 kem_id The HPKE KEM identifier corresponding to "public_key". 351 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 352 using a KEM they do not support. 354 kdf_id The HPKE KDF identifier corresponding to "public_key". 355 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 356 using a KDF they do not support. 358 aead_id The HPKE AEAD identifier corresponding to "public_key". 359 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 360 using an AEAD they do not support. 362 public_key The HPKE public key used by the client to encrypt 363 Oblivious DoH queries. 365 7. Protocol Encoding 367 7.1. Message Format 369 There are two types of Oblivious DoH messages: Queries (0x01) and 370 Responses (0x02). Both messages carry the following information: 372 1. A DNS message, which is either a Query or Response, depending on 373 context. 375 2. Padding of arbitrary length which MUST contain all zeros. 377 They are encoded using the following structure: 379 struct { 380 opaque dns_message<1..2^16-1>; 381 opaque padding<0..2^16-1>; 382 } ObliviousDoHMessagePlaintext; 384 Both Query and Response messages use the 385 "ObliviousDoHMessagePlaintext" format. 387 ObliviousDoHMessagePlaintext ObliviousDoHQuery; 388 ObliviousDoHMessagePlaintext ObliviousDoHResponse; 390 An encrypted "ObliviousDoHMessagePlaintext" is carried in a 391 "ObliviousDoHMessage" message, encoded as follows: 393 struct { 394 uint8 message_type; 395 opaque key_id<0..2^16-1>; 396 opaque encrypted_message<1..2^16-1>; 397 } ObliviousDoHMessage; 399 The "ObliviousDoHMessage" structure contains the following fields: 401 message_type A one-byte identifier for the type of message. Query 402 messages use "message_type" 0x01, and Response messages use 403 "message_type" 0x02. 405 key_id The identifier of the corresponding 406 "ObliviousDoHConfigContents" key. This is computed as 407 "Expand(Extract("", config), "odoh key id", Nh)", where "config" 408 is the ObliviousDoHConfigContents structure and "Extract", 409 "Expand", and "Nh" are as specified by the HPKE cipher suite KDF 410 corresponding to "config.kdf_id". 412 encrypted_message An encrypted message for the Oblivious Target (for 413 Query messages) or client (for Response messages). 415 The contents of "ObliviousDoHMessage.encrypted_message" depend on 416 "ObliviousDoHMessage.message_type". In particular, 417 "ObliviousDoHMessage.encrypted_message" is an encryption of a 418 "ObliviousDoHQuery" if the message is a Query, and 419 "ObliviousDoHResponse" if the message is a Response. 421 7.2. Encryption and Decryption Routines 423 Clients use the following utility functions for encrypting a Query 424 and decrypting a Response as described in Section 8. 426 encrypt_query_body: Encrypt an Oblivious DoH query. 428 def encrypt_query_body(pkR, key_id, Q_plain): 429 enc, context = SetupBaseS(pkR, "odoh query") 430 aad = 0x01 || len(key_id) || key_id 431 ct = context.Seal(aad, Q_plain) 432 Q_encrypted = enc || ct 433 return Q_encrypted 435 decrypt_response_body: Decrypt an Oblivious DoH response. 437 def decrypt_response_body(context, Q_plain, R_encrypted): 438 key, nonce = derive_secrets(context, Q_plain) 439 aad = 0x02 || 0x0000 // 0x0000 represents a 0-length KeyId 440 R_plain, error = Open(key, nonce, aad, R_encrypted) 441 return R_plain, error 443 The "derive_secrets" function is described below. 445 Targets use the following utility functions in processing queries and 446 producing responses as described in Section 9. 448 setup_query_context: Set up an HPKE context used for decrypting an 449 Oblivious DoH query. 451 def setup_query_context(skR, key_id, Q_encrypted): 452 enc || ct = Q_encrypted 453 context = SetupBaseR(enc, skR, "odoh query") 454 return context 456 decrypt_query_body: Decrypt an Oblivious DoH query. 458 def decrypt_query_body(context, key_id, Q_encrypted): 459 aad = 0x01 || len(key_id) || key_id 460 enc || ct = Q_encrypted 461 Q_plain, error = context.Open(aad, ct) 462 return Q_plain, error 464 derive_secrets: Derive keying material used for encrypting an 465 Oblivious DoH response. 467 def derive_secrets(context, Q_plain): 468 odoh_secret = context.Export("odoh secret", 32) 469 odoh_prk = Extract(Q_plain, odoh_secret) 470 key = Expand(odoh_prk, "odoh key", Nk) 471 nonce = Expand(odoh_prk, "odoh nonce", Nn) 472 return key, nonce 474 encrypt_response_body: Encrypt an Oblivious DoH response. 476 def encrypt_response_body(R_plain, answer_key, answer_nonce): 477 aad = 0x02 || 0x0000 // 0x0000 represents a 0-length KeyId 478 R_encrypted = Seal(answer_key, answer_nonce, aad, R_plain) 479 return R_encrypted 481 8. Oblivious Client Behavior 483 Let "M" be a DNS message (query) a client wishes to protect with 484 Oblivious DoH. When sending an Oblivious DoH Query for resolving "M" 485 to an Oblivious Target with "ObliviousDoHConfigContents" "config", a 486 client does the following: 488 1. Create an "ObliviousDoHQuery" structure, carrying the message M 489 and padding, to produce Q_plain. 491 2. Deserialize "config.public_key" to produce a public key pkR of 492 type "config.kem_id". 494 3. Compute the encrypted message as "Q_encrypted = 495 encrypt_query_body(pkR, key_id, Q_plain)", where "key_id" is as 496 computed in Section 7. Note also that "len(key_id)" outputs the 497 length of "key_id" as a two-byte unsigned integer. 499 4. Output a ObliviousDoHMessage message "Q" where "Q.message_type = 500 0x01", "Q.key_id" carries "key_id", and "Q.encrypted_message = 501 Q_encrypted". 503 The client then sends "Q" to the Proxy according to Section 4.1. 504 Once the client receives a response "R", encrypted as specified in 505 Section 9, it uses "decrypt_response_body" to decrypt 506 "R.encrypted_message" and produce R_plain. Clients MUST validate 507 "R_plain.padding" (as all zeros) before using R_plain.dns_message. 509 9. Oblivious Target Behavior 511 Targets that receive a Query message Q decrypt and process it as 512 follows: 514 1. Look up the "ObliviousDoHConfigContents" according to "Q.key_id". 515 If no such key exists, the Target MAY discard the query, and if 516 so, it MUST return a 400 (Client Error) response to the Proxy. 517 Otherwise, let "skR" be the private key corresponding to this 518 public key, or one chosen for trial decryption. 520 2. Compute "context = setup_query_context(skR, Q.key_id, 521 Q.encrypted_message)". 523 3. Compute "Q_plain, error = decrypt_query_body(context, Q.key_id, 524 Q.encrypted_message)". 526 4. If no error was returned, and "Q_plain.padding" is valid (all 527 zeros), resolve "Q_plain.dns_message" as needed, yielding a DNS 528 message M. Otherwise, if an error was returned or the padding 529 was invalid, return a 400 (Client Error) response to the Proxy. 531 5. Create an "ObliviousDoHResponseBody" structure, carrying the 532 message "M" and padding, to produce "R_plain". 534 6. Compute "answer_key, answer_nonce = derive_secrets(context, 535 Q_plain)". 537 7. Compute "R_encrypted = encrypt_response_body(R_plain, answer_key, 538 answer_nonce)". The "key_id" field used for encryption is empty, 539 yielding "0x0000" as part of the AAD. Also, the "Seal" function 540 is that which is associated with the HPKE AEAD. 542 8. Output a "ObliviousDoHMessage" message "R" where "R.message_type 543 = 0x02", "R.key_id = nil", and "R.encrypted_message = 544 R_encrypted". 546 The Target then sends "R" in a 2xx (Successful) response to the Proxy 547 according to Section 4.3. The Proxy forwards the message "R" without 548 modification back to the client as the HTTP response to the client's 549 original HTTP request. 551 10. Compliance Requirements 553 Oblivious DoH uses draft-06 of HPKE for public key encryption 554 [I-D.irtf-cfrg-hpke]. In the absence of an application profile 555 standard specifying otherwise, a compliant Oblivious DoH 556 implementation MUST support the following HPKE cipher suite: 558 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 559 Section 7.1) 561 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 563 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 565 11. Security Considerations 567 DISCLAIMER: this is a work in progress draft and has not yet seen 568 significant security analysis. 570 Oblivious DoH aims to keep knowledge of the true query origin and its 571 contents known to only clients. As a simplified model, consider a 572 case where there exists two clients C1 and C2, one proxy P, and one 573 target T. Oblivious DoH assumes an extended Dolev-Yao style attacker 574 which can observe all network activity and can adaptively compromise 575 either P or T, but not C1 or C2. Once compromised, the attacker has 576 access to all session information and private key material. (This 577 generalizes to arbitrarily many clients, proxies, and targets, with 578 the constraints that not all targets and proxies are simultaneously 579 compromised, and at least two clients are left uncompromised.) The 580 attacker is prohibited from sending client identifying information, 581 such as IP addresses, to targets. (This would allow the attacker to 582 trivially link a query to the corresponding client.) 584 In this model, both C1 and C2 send an Oblivious DoH queries Q1 and 585 Q2, respectively, through P to T, and T provides answers A1 and A2. 586 The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), 587 respectively. The attacker succeeds if this linkability is possible 588 without any additional interaction. (For example, if T is 589 compromised, it may return a DNS answer corresponding to an entity it 590 controls, and then observe the subsequent connection from a client, 591 learning its identity in the process. Such attacks are out of scope 592 for this model.) 594 Oblivious DoH security prevents such linkability. Informally, this 595 means: 597 1. Queries and answers are known only to clients and targets in 598 possession of the corresponding response key and HPKE keying 599 material. In particular, proxies know the origin and destination 600 of an oblivious query, yet do not know the plaintext query. 601 Likewise, targets know only the oblivious query origin, i.e., the 602 proxy, and the plaintext query. Only the client knows both the 603 plaintext query contents and destination. 605 2. Target resolvers cannot link queries from the same client in the 606 absence of unique per-client keys. 608 Traffic analysis mitigations are outside the scope of this document. 609 In particular, this document does not recommend padding lengths for 610 ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations 611 SHOULD follow the guidance for choosing padding length in [RFC8467]. 613 Oblivious DoH security does not depend on proxy and target 614 indistinguishability. Specifically, an on-path attacker could 615 determine whether a connection a specific endpoint is used for 616 oblivious or direct DoH queries. However, this has no effect on 617 confidentiality goals listed above. 619 11.1. Denial of Service 621 Malicious clients (or proxies) may send bogus Oblivious DoH queries 622 to targets as a Denial-of-Service (DoS) attack. Target servers may 623 throttle processing requests if such an event occurs. Additionally, 624 since Targets provide explicit errors upon decryption failure, i.e., 625 if ciphertext decryption fails or if the plaintext DNS message is 626 malformed, Proxies may throttle specific clients in response to these 627 errors. 629 Malicious Targets or Proxies may send bogus answers in response to 630 Oblivious DoH queries. Response decryption failure is a signal that 631 either the proxy or target is misbehaving. Clients can choose to 632 stop using one or both of these servers in the event of such failure. 633 However, as above, malicious Targets and Proxies are out of scope for 634 the threat model. 636 11.2. General Proxy Services 638 Using DoH over anonymizing proxy services such as Tor would also 639 achieve the desired goal of separating query origins from their 640 contents. However, there are several reasons why such systems are 641 undesirable in comparison Oblivious DoH: 643 1. Tor is also meant as a generic connection-level anonymity system, 644 and thus seems overly complex and costly for the purpose of 645 proxying individual DoH queries. In contrast, Oblivious DoH is a 646 lightweight extension to standard DoH, implemented as an 647 application-layer proxy, that can be enabled as a default mode 648 for users which need increased privacy. 650 2. As a one-hop proxy, Oblivious DoH encourages connection-less 651 proxies to mitigate client query correlation with few round- 652 trips. In contrast, multi-hop systems such as Tor often run 653 secure connections (TLS) end-to-end, which means that DoH servers 654 could track queries over the same connection. Using a fresh DoH 655 connection per query would incur a non-negligible penalty in 656 connection setup time. 658 12. IANA Considerations 660 12.1. Oblivious DoH Message Media Type 662 This document registers a new media type, "application/oblivious-dns- 663 message". 665 Type name: application 666 Subtype name: oblivious-dns-message 668 Required parameters: N/A 670 Optional parameters: N/A 672 Encoding considerations: This is a binary format, containing 673 encrypted DNS requests and responses, as defined in this document. 675 Security considerations: See this document. The content is an 676 encrypted DNS message, and not executable code. 678 Interoperability considerations: This document specifies format of 679 conforming messages and the interpretation thereof. 681 Published specification: This document. 683 Applications that use this media type: This media type is intended to 684 be used by clients wishing to hide their DNS queries when using DNS 685 over HTTPS. 687 Additional information: None 689 Person and email address to contact for further information: See 690 Authors' Addresses section 692 Intended usage: COMMON 694 Restrictions on usage: None 696 Author: IETF 698 Change controller: IETF 700 12.2. Oblivious DoH Public Key DNS Parameter 702 This document adds a parameter ("odohconfig") to the "Service Binding 703 (SVCB) Parameter" registry [I-D.ietf-dnsop-svcb-https]. The 704 allocation request is 32769, taken from the to the First Come First 705 Served range. 707 If present, the "odohconfig" parameter contains a ObliviousDoHConfigs 708 structure. In wire format, the value of the parameter is an 709 ObliviousDoHConfigs vector, including the redundant length prefix. 710 In presentation format, the value is encoded in [base64]. 712 Name: odohconfig 713 SvcParamKey: 32769 715 Meaning: An ObliviousDoHConfigs structure. 717 Reference: This document. 719 13. Acknowledgments 721 This work is inspired by Oblivious DNS 722 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 723 that document. Thanks to Elliot Briggs, Marwan Fayed, Frederic 724 Jacobs, Tommy Jensen Paul Schmitt, and Brian Swander for the feedback 725 and input. 727 14. References 729 14.1. Normative References 731 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 732 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 733 . 735 [I-D.ietf-dnsop-svcb-https] 736 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 737 and parameter specification via the DNS (DNS SVCB and 738 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 739 dnsop-svcb-https-02, 2 November 2020, 740 . 743 [I-D.irtf-cfrg-hpke] 744 Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 745 Public Key Encryption", Work in Progress, Internet-Draft, 746 draft-irtf-cfrg-hpke-06, 23 October 2020, 747 . 750 [I-D.pauly-add-resolver-discovery] 751 Pauly, T., Kinnear, E., Wood, C., McManus, P., and T. 752 Jensen, "Adaptive DNS Resolver Discovery", Work in 753 Progress, Internet-Draft, draft-pauly-add-resolver- 754 discovery-01, 13 July 2020, . 757 [I-D.pauly-dprive-adaptive-dns-privacy] 758 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 759 "Adaptive DNS: Improving Privacy of Name Resolution", Work 760 in Progress, Internet-Draft, draft-pauly-dprive-adaptive- 761 dns-privacy-01, 1 November 2019, . 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 771 Rose, "DNS Security Introduction and Requirements", 772 RFC 4033, DOI 10.17487/RFC4033, March 2005, 773 . 775 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 776 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 777 DOI 10.17487/RFC7231, June 2014, 778 . 780 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 781 Protocol (HTTP/1.1): Authentication", RFC 7235, 782 DOI 10.17487/RFC7235, June 2014, 783 . 785 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 786 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 787 May 2017, . 789 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 790 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 791 . 793 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 794 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 795 October 2018, . 797 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 798 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 799 . 801 14.2. Informative References 803 [I-D.annee-dprive-oblivious-dns] 804 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 805 "Oblivious DNS - Strong Privacy for DNS Queries", Work in 806 Progress, Internet-Draft, draft-annee-dprive-oblivious- 807 dns-00, 2 July 2018, . 810 Authors' Addresses 812 Eric Kinnear 813 Apple Inc. 814 One Apple Park Way 815 Cupertino, California 95014, 816 United States of America 818 Email: ekinnear@apple.com 820 Patrick McManus 821 Fastly 823 Email: mcmanus@ducksong.com 825 Tommy Pauly 826 Apple Inc. 827 One Apple Park Way 828 Cupertino, California 95014, 829 United States of America 831 Email: tpauly@apple.com 833 Christopher A. Wood 834 Cloudflare 835 101 Townsend St 836 San Francisco, 837 United States of America 839 Email: caw@heapingbits.net