idnits 2.17.1 draft-pauly-dprive-oblivious-doh-07.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 4 instances of too long lines in the document, the longest one being 1 character 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 September 2021) is 964 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-httpbis-proxy-status-06 ** 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) Summary: 4 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 March 2022 Fastly 6 T. Pauly 7 Apple Inc. 8 T. Verma 9 C.A. Wood 10 Cloudflare 11 2 September 2021 13 Oblivious DNS Over HTTPS 14 draft-pauly-dprive-oblivious-doh-07 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 March 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 Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified 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. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 15 80 10.2. Proxy Policies . . . . . . . . . . . . . . . . . . . . . 15 81 10.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16 82 10.4. General Proxy Services . . . . . . . . . . . . . . . . . 16 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 11.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 16 85 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 13.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 94 messages to be transmitted in encrypted HTTP messages. This provides 95 improved confidentiality and authentication for DNS interactions in 96 various circumstances. 98 While DoH can prevent eavesdroppers from directly reading the 99 contents of DNS exchanges, clients cannot send DNS queries and 100 receive answers from servers without revealing their local IP 101 address, and thus information about the identity or location of the 102 client. 104 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 105 increase privacy by ensuring no single DNS server is aware of both 106 the client IP address and the message contents. 108 This document defines Oblivious DoH, an experimental extension to DoH 109 that permits proxied resolution, in which DNS messages are encrypted 110 so that no DoH server can independently read both the client IP 111 address and the DNS message contents. 113 This mechanism is intended to be used as one mechanism for resolving 114 privacy-sensitive content in the broader context of DNS privacy. 116 This experimental extension is developed outside the IETF and is 117 published here to guide implementation, ensure interoperability among 118 implementations, and enable wide-scale experimentation. 120 1.1. Specification of Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Terminology 130 This document defines the following terms: 132 Oblivious Server: A DoH server that acts as either an Oblivious 133 Proxy or Oblivious Target. 135 Oblivious Proxy: An Oblivious Server that proxies encrypted DNS 136 queries and responses between a client and an Oblivious Target. 138 Oblivious Target: An Oblivious Server that receives and decrypts 139 encrypted client DNS queries from an Oblivious Proxy, and returns 140 encrypted DNS responses via that same Proxy. In order to provide 141 DNS responses, the Target can be a DNS resolver, be co-located 142 with a resolver, or forward to a resolver. 144 Throughout the rest of this document, we use the terms Proxy and 145 Target to refer to an Oblivious Proxy and Oblivious Target, 146 respectively. 148 3. Deployment Requirements 150 Oblivious DoH requires, at a minimum: 152 * Two Oblivious Servers, where one can act as a Proxy, and the other 153 can act as a Target. 155 * Public keys for encrypting DNS queries that are passed from a 156 client through a Proxy to a Target (Section 5). These keys 157 guarantee that only the intended Target can decrypt client 158 queries. 160 The mechanism for discovering and provisioning the DoH URI Templates 161 and public keys is out of scope of this document. 163 4. HTTP Exchange 165 Unlike direct resolution, oblivious hostname resolution over DoH 166 involves three parties: 168 1. The Client, which generates queries. 170 2. The Proxy, which receives encrypted queries from the client and 171 passes them on to a Target. 173 3. The Target, which receives proxied queries from the client via 174 the Proxy and produces proxied answers. 176 --- [ Request encrypted with target public key ] --> 177 +---------+ +-----------+ +-----------+ 178 | Client +-------------> Oblivious +-------------> Oblivious | 179 | <-------------+ Proxy <-------------+ Target | 180 +---------+ +-----------+ +-----------+ 181 <-- [ Response encrypted with symmetric key ] --- 183 Figure 1: Obvlivious DoH Exchange 185 4.1. HTTP Request 187 Oblivious DoH queries are created by the Client, and sent to the 188 Proxy as an HTTP request using the POST method. Requests to the 189 Proxy indicate which DoH server to use as a Target by specifying two 190 variables: "targethost", which indicates the host name of the Target 191 server, and "targetpath", which indicates the path on which the 192 Target's DoH server is running. See Section 4.2 for an example 193 request. 195 Oblivious DoH messages have no cache value since both requests and 196 responses are encrypted using ephemeral key material. Clients SHOULD 197 indicate this using the "Cache-Control" header with "no-cache" and 198 "no-store" specified [RFC7234]. 200 Clients MUST set the HTTP Content-Type header to "application/ 201 oblivious-dns-message" to indicate that this request is an Oblivious 202 DoH query intended for proxying. Clients also SHOULD set this same 203 value for the HTTP Accept header. 205 Proxies must check that client requests are correctly encoded, and 206 MUST return a 4xx (Client Error) if the check fails, along with the 207 Proxy-Status response header with an "error" parameter of type 208 "http_request_error" [I-D.ietf-httpbis-proxy-status]. A correctly 209 encoded request has the HTTP Content-Type header "application/ 210 oblivious-dns-message", and HTTP method POST. If the proxy does not 211 operate as a target, then the request must additionally contain 212 "targethost" and "targetpath" variables. 214 Upon receiving a request that contains a "application/oblivious-dns- 215 message" Content-Type, the DoH server looks for the "targethost" and 216 "targetpath" variables. If the variables are not present, then it is 217 the target of the query, and it can decrypt the query (Section 6). 218 If the variables are present, then the DoH server is acting as a 219 Proxy. If it is a proxy, it is expected to send the request on to 220 the Target using the URI template constructed as "https://targethost/ 221 targetpath". 223 Note that "targethost" MAY contain a port. Proxies MAY choose to not 224 forward connections to non-standard ports. In such cases, proxies 225 MUST return a 4xx (Client Error) response to the client request, 226 along with Proxy-Status response header with an "error" parameter of 227 type "http_request_error". 229 If the proxy cannot establish a connection to "targethost", it MUST 230 return a 502 (Bad Gateway) response to the client request, along with 231 Proxy-Status response header with an "error" parameter whose type 232 indicates the reason. For example, if DNS resolution fails, the 233 error type might be "dns_timeout", whereas if the TLS connection 234 failed the error type might be "tls_protocol_error". Proxies SHOULD 235 choose an error type that best captures the connection failure. 237 4.2. HTTP Request Example 239 The following example shows how a client requests that a Proxy, 240 "dnsproxy.example.net", forwards an encrypted message to 241 "dnstarget.example.net". The URI template for the Proxy is 242 "https://dnsproxy.example.net/dns-query{?targethost,targetpath}". 243 The URI template for the Target is "https://dnstarget.example.net/ 244 dns-query". 246 :method = POST 247 :scheme = https 248 :authority = dnsproxy.example.net 249 :path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query 250 accept = application/oblivious-dns-message 251 cache-control = no-cache, no-store 252 content-type = application/oblivious-dns-message 253 content-length = 106 255 257 The Proxy then sends the following request on to the Target: 259 :method = POST 260 :scheme = https 261 :authority = dnstarget.example.net 262 :path = /dns-query 263 accept = application/oblivious-dns-message 264 cache-control = no-cache, no-store 265 content-type = application/oblivious-dns-message 266 content-length = 106 268 270 4.3. HTTP Response 272 The response to an Oblivious DoH query is generated by the Target. 273 It MUST set the Content-Type HTTP header to "application/oblivious- 274 dns-message" for all successful responses. The body of the response 275 contains an encrypted DNS message; see Section 6. 277 The response from a Target MUST set the Content-Type HTTP header to 278 "application/oblivious-dns-message" which MUST be forwarded by the 279 Proxy to the Client. A Client MUST only consider a response which 280 contains the Content-Type header in the response before processing 281 the payload. A response without the appropriate header MUST be 282 treated as an error and be handled appropriately. All other aspects 283 of the HTTP response and error handling are inherited from standard 284 DoH. 286 Proxies MUST forward any Target responses with 2xx, 4xx, or 5xx 287 response codes unmodified to the client. Target responses with 1xx 288 response codes MUST NOT be forwarded to the client. If a proxy 289 receives a successful response from a target without the 290 "application/oblivious-dns-message" HTTP Content-Type header, it MUST 291 return a 502 (Bad Gateway) response to the client request, along with 292 Proxy-Status response header with an "error" parameter of type 293 "http_protocol_error". 295 Requests that cannot be processed by the target result in 4xx (Client 296 Error) responses. If the target and client keys do not match, it is 297 an authorization failure (HTTP status code 401; see Section 3.1 of 298 [RFC7235]). Otherwise, if the client's request is invalid, such as 299 in the case of decryption failure, wrong message type, or 300 deserialization failure, this is a bad request (HTTP status code 400; 301 see Section 6.5.1 of [RFC7231]). 303 Even in case of DNS responses indicating failure, such as SERVFAIL or 304 NXDOMAIN, a successful HTTP response with a 2xx status code is used 305 as long as the DNS response is valid. This is similar to how DoH 306 [RFC8484] handles HTTP response codes. 308 In case of server error, the usual HTTP status code 500 (see 309 Section 6.6.1 of [RFC7231]) applies. 311 4.4. HTTP Response Example 313 The following example shows a 2xx (Successful) response that can be 314 sent from a Target to a client via a Proxy. 316 :status = 200 317 content-type = application/oblivious-dns-message 318 content-length = 154 320 322 4.5. HTTP Metadata 324 Proxies forward requests and responses between clients and targets as 325 specified in Section 4.1. Metadata sent with these messages may 326 inadvertently weaken or remove Oblivious DoH privacy properties. 327 Proxies MUST NOT send any client-identifying information about 328 clients to targets, such as "Forwarded" HTTP headers [RFC7239]. 329 Additionally, clients MUST NOT include any private state in requests 330 to proxies, such as HTTP cookies. See Section 10.3 for related 331 discussion about client authentication information. 333 5. Configuration and Public Key Format 335 In order to use a DoH server as a Target, the client must know a 336 public key to use for encrypting its queries. The mechanism for 337 discovering this configuration is out of scope of this document. 339 Servers SHOULD rotate public keys regularly. It is RECOMMENDED that 340 servers rotate keys every day. Shorter rotation windows reduce the 341 anonymity set of clients that might use the public key, whereas 342 longer rotation windows widen the timeframe of possible compromise. 344 An Oblivious DNS public key configuration is a structure encoded, 345 using TLS-style encoding [RFC8446], as follows: 347 struct { 348 uint16 kem_id; 349 uint16 kdf_id; 350 uint16 aead_id; 351 opaque public_key<1..2^16-1>; 352 } ObliviousDoHConfigContents; 354 struct { 355 uint16 version; 356 uint16 length; 357 select (ObliviousDoHConfig.version) { 358 case 0x0001: ObliviousDoHConfigContents contents; 359 } 360 } ObliviousDoHConfig; 362 ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; 364 The "ObliviousDoHConfigs" structure contains one or more 365 "ObliviousDoHConfig" structures in decreasing order of preference. 366 This allows a server to support multiple versions of Oblivious DoH 367 and multiple sets of Oblivious DoH parameters. 369 An "ObliviousDoHConfig" contains a versioned representation of an 370 Oblivious DoH configuration, with the following fields. 372 version The version of Oblivious DoH for which this configuration is 373 used. Clients MUST ignore any "ObliviousDoHConfig" structure with 374 a version they do not support. The version of Oblivious DoH 375 specified in this document is "0x0001". 377 length The length, in bytes, of the next field. 379 contents An opaque byte string whose contents depend on the version. 380 For this specification, the contents are an 381 "ObliviousDoHConfigContents" structure. 383 An "ObliviousDoHConfigContents" contains the information needed to 384 encrypt a message under "ObliviousDoHConfigContents.public_key" such 385 that only the owner of the corresponding private key can decrypt the 386 message. The values for "ObliviousDoHConfigContents.kem_id", 387 "ObliviousDoHConfigContents.kdf_id", and 388 "ObliviousDoHConfigContents.aead_id" are described in 389 [I-D.irtf-cfrg-hpke] Section 7. The fields in this structure are as 390 follows: 392 kem_id The HPKE KEM identifier corresponding to "public_key". 393 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 394 using a KEM they do not support. 396 kdf_id The HPKE KDF identifier corresponding to "public_key". 397 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 398 using a KDF they do not support. 400 aead_id The HPKE AEAD identifier corresponding to "public_key". 401 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 402 using an AEAD they do not support. 404 public_key The HPKE public key used by the client to encrypt 405 Oblivious DoH queries. 407 6. Protocol Encoding 409 6.1. Message Format 411 There are two types of Oblivious DoH messages: Queries (0x01) and 412 Responses (0x02). Both messages carry the following information: 414 1. A DNS message, which is either a Query or Response, depending on 415 context. 417 2. Padding of arbitrary length which MUST contain all zeros. 419 They are encoded using the following structure: 421 struct { 422 opaque dns_message<1..2^16-1>; 423 opaque padding<0..2^16-1>; 424 } ObliviousDoHMessagePlaintext; 426 Both Query and Response messages use the 427 "ObliviousDoHMessagePlaintext" format. 429 ObliviousDoHMessagePlaintext ObliviousDoHQuery; 430 ObliviousDoHMessagePlaintext ObliviousDoHResponse; 432 An encrypted "ObliviousDoHMessagePlaintext" is carried in a 433 "ObliviousDoHMessage" message, encoded as follows: 435 struct { 436 uint8 message_type; 437 opaque key_id<0..2^16-1>; 438 opaque encrypted_message<1..2^16-1>; 439 } ObliviousDoHMessage; 441 The "ObliviousDoHMessage" structure contains the following fields: 443 message_type A one-byte identifier for the type of message. Query 444 messages use "message_type" 0x01, and Response messages use 445 "message_type" 0x02. 447 key_id The identifier of the corresponding 448 "ObliviousDoHConfigContents" key. This is computed as 449 "Expand(Extract("", config), "odoh key id", Nh)", where "config" 450 is the ObliviousDoHConfigContents structure and "Extract", 451 "Expand", and "Nh" are as specified by the HPKE cipher suite KDF 452 corresponding to "config.kdf_id". 454 encrypted_message An encrypted message for the Oblivious Target (for 455 Query messages) or client (for Response messages). 456 Implementations MAY enforce limits on the size of this field 457 depending on the size of plaintext DNS messages. (DNS queries, 458 for example, will not reach the size limit of 2^16-1 in practice.) 460 The contents of "ObliviousDoHMessage.encrypted_message" depend on 461 "ObliviousDoHMessage.message_type". In particular, 462 "ObliviousDoHMessage.encrypted_message" is an encryption of a 463 "ObliviousDoHQuery" if the message is a Query, and 464 "ObliviousDoHResponse" if the message is a Response. 466 6.2. Encryption and Decryption Routines 468 Clients use the following utility functions for encrypting a Query 469 and decrypting a Response as described in Section 7. 471 encrypt_query_body: Encrypt an Oblivious DoH query. 473 def encrypt_query_body(pkR, key_id, Q_plain): 474 enc, context = SetupBaseS(pkR, "odoh query") 475 aad = 0x01 || len(key_id) || key_id 476 ct = context.Seal(aad, Q_plain) 477 Q_encrypted = enc || ct 478 return Q_encrypted 480 decrypt_response_body: Decrypt an Oblivious DoH response. 482 def decrypt_response_body(context, Q_plain, R_encrypted, response_nonce): 483 aead_key, aead_nonce = derive_secrets(context, Q_plain, response_nonce) 484 aad = 0x02 || len(response_nonce) || response_nonce 485 R_plain, error = Open(key, nonce, aad, R_encrypted) 486 return R_plain, error 488 The "derive_secrets" function is described below. 490 Targets use the following utility functions in processing queries and 491 producing responses as described in Section 8. 493 setup_query_context: Set up an HPKE context used for decrypting an 494 Oblivious DoH query. 496 def setup_query_context(skR, key_id, Q_encrypted): 497 enc || ct = Q_encrypted 498 context = SetupBaseR(enc, skR, "odoh query") 499 return context 501 decrypt_query_body: Decrypt an Oblivious DoH query. 503 def decrypt_query_body(context, key_id, Q_encrypted): 504 aad = 0x01 || len(key_id) || key_id 505 enc || ct = Q_encrypted 506 Q_plain, error = context.Open(aad, ct) 507 return Q_plain, error 509 derive_secrets: Derive keying material used for encrypting an 510 Oblivious DoH response. 512 def derive_secrets(context, Q_plain, response_nonce): 513 secret = context.Export("odoh response", Nk) 514 salt = Q_plain || len(response_nonce) || response_nonce 515 prk = Extract(salt, secret) 516 key = Expand(odoh_prk, "odoh key", Nk) 517 nonce = Expand(odoh_prk, "odoh nonce", Nn) 518 return key, nonce 520 The "random(N)" function returns "N" cryptographically secure random 521 bytes from a good source of entropy [RFC4086]. The "max(A, B)" 522 function returns "A" if "A > B", and "B" otherwise. 524 encrypt_response_body: Encrypt an Oblivious DoH response. 526 def encrypt_response_body(R_plain, aead_key, aead_nonce, response_nonce): 527 aad = 0x02 || len(response_nonce) || response_nonce 528 R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain) 529 return R_encrypted 531 7. Oblivious Client Behavior 533 Let "M" be a DNS message (query) a client wishes to protect with 534 Oblivious DoH. When sending an Oblivious DoH Query for resolving "M" 535 to an Oblivious Target with "ObliviousDoHConfigContents" "config", a 536 client does the following: 538 1. Create an "ObliviousDoHQuery" structure, carrying the message M 539 and padding, to produce Q_plain. 541 2. Deserialize "config.public_key" to produce a public key pkR of 542 type "config.kem_id". 544 3. Compute the encrypted message as "Q_encrypted = 545 encrypt_query_body(pkR, key_id, Q_plain)", where "key_id" is as 546 computed in Section 6. Note also that "len(key_id)" outputs the 547 length of "key_id" as a two-byte unsigned integer. 549 4. Output a ObliviousDoHMessage message "Q" where "Q.message_type = 550 0x01", "Q.key_id" carries "key_id", and "Q.encrypted_message = 551 Q_encrypted". 553 The client then sends "Q" to the Proxy according to Section 4.1. 554 Once the client receives a response "R", encrypted as specified in 555 Section 8, it uses "decrypt_response_body" to decrypt 556 "R.encrypted_message" (using "R.key_id" as a nonce) and produce 557 R_plain. Clients MUST validate "R_plain.padding" (as all zeros) 558 before using "R_plain.dns_message". 560 8. Oblivious Target Behavior 562 Targets that receive a Query message Q decrypt and process it as 563 follows: 565 1. Look up the "ObliviousDoHConfigContents" according to "Q.key_id". 566 If no such key exists, the Target MAY discard the query, and if 567 so, it MUST return a 400 (Client Error) response to the Proxy. 568 Otherwise, let "skR" be the private key corresponding to this 569 public key, or one chosen for trial decryption. 571 2. Compute "context = setup_query_context(skR, Q.key_id, 572 Q.encrypted_message)". 574 3. Compute "Q_plain, error = decrypt_query_body(context, Q.key_id, 575 Q.encrypted_message)". 577 4. If no error was returned, and "Q_plain.padding" is valid (all 578 zeros), resolve "Q_plain.dns_message" as needed, yielding a DNS 579 message M. Otherwise, if an error was returned or the padding 580 was invalid, return a 400 (Client Error) response to the Proxy. 582 5. Create an "ObliviousDoHResponseBody" structure, carrying the 583 message "M" and padding, to produce "R_plain". 585 6. Create a fresh nonce "response_nonce = random(max(Nn, Nk))". 587 7. Compute "aead_key, aead_nonce = derive_secrets(context, Q_plain, 588 response_nonce)". 590 8. Compute "R_encrypted = encrypt_response_body(R_plain, aead_key, 591 aead_nonce, response_nonce)". The "key_id" field used for 592 encryption carries "response_nonce" in order for clients to 593 derive the same secrets. Also, the "Seal" function is that which 594 is associated with the HPKE AEAD. 596 9. Output a "ObliviousDoHMessage" message "R" where "R.message_type 597 = 0x02", "R.key_id = response_nonce", and "R.encrypted_message = 598 R_encrypted". 600 The Target then sends "R" in a 2xx (Successful) response to the 601 Proxy; see Section 4.3. The Proxy forwards the message "R" without 602 modification back to the client as the HTTP response to the client's 603 original HTTP request. In the event of an error (non 2xx status 604 code), the Proxy forwards the Target error to the client; see 605 Section 4.3. 607 9. Compliance Requirements 609 Oblivious DoH uses HPKE for public key encryption 610 [I-D.irtf-cfrg-hpke]. In the absence of an application profile 611 standard specifying otherwise, a compliant Oblivious DoH 612 implementation MUST support the following HPKE cipher suite: 614 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 615 Section 7.1) 617 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 619 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 621 10. Security Considerations 623 Oblivious DoH aims to keep knowledge of the true query origin and its 624 contents known to only clients. As a simplified model, consider a 625 case where there exists two clients C1 and C2, one proxy P, and one 626 target T. Oblivious DoH assumes an extended Dolev-Yao style attacker 627 which can observe all network activity and can adaptively compromise 628 either P or T, but not C1 or C2. Once compromised, the attacker has 629 access to all session information and private key material. (This 630 generalizes to arbitrarily many clients, proxies, and targets, with 631 the constraints that not all targets and proxies are simultaneously 632 compromised, and at least two clients are left uncompromised.) The 633 attacker is prohibited from sending client identifying information, 634 such as IP addresses, to targets. (This would allow the attacker to 635 trivially link a query to the corresponding client.) 637 In this model, both C1 and C2 send an Oblivious DoH queries Q1 and 638 Q2, respectively, through P to T, and T provides answers A1 and A2. 639 The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), 640 respectively. The attacker succeeds if this linkability is possible 641 without any additional interaction. (For example, if T is 642 compromised, it may return a DNS answer corresponding to an entity it 643 controls, and then observe the subsequent connection from a client, 644 learning its identity in the process. Such attacks are out of scope 645 for this model.) 647 Oblivious DoH security prevents such linkability. Informally, this 648 means: 650 1. Queries and answers are known only to clients and targets in 651 possession of the corresponding response key and HPKE keying 652 material. In particular, proxies know the origin and destination 653 of an oblivious query, yet do not know the plaintext query. 654 Likewise, targets know only the oblivious query origin, i.e., the 655 proxy, and the plaintext query. Only the client knows both the 656 plaintext query contents and destination. 658 2. Target resolvers cannot link queries from the same client in the 659 absence of unique per-client keys. 661 Traffic analysis mitigations are outside the scope of this document. 662 In particular, this document does not recommend padding lengths for 663 ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations 664 SHOULD follow the guidance for choosing padding length in [RFC8467]. 666 Oblivious DoH security does not depend on proxy and target 667 indistinguishability. Specifically, an on-path attacker could 668 determine whether a connection a specific endpoint is used for 669 oblivious or direct DoH queries. However, this has no effect on 670 confidentiality goals listed above. 672 10.1. Denial of Service 674 Malicious clients (or proxies) may send bogus Oblivious DoH queries 675 to targets as a Denial-of-Service (DoS) attack. Target servers may 676 throttle processing requests if such an event occurs. Additionally, 677 since Targets provide explicit errors upon decryption failure, i.e., 678 if ciphertext decryption fails or if the plaintext DNS message is 679 malformed, Proxies may throttle specific clients in response to these 680 errors. 682 Malicious Targets or Proxies may send bogus answers in response to 683 Oblivious DoH queries. Response decryption failure is a signal that 684 either the proxy or target is misbehaving. Clients can choose to 685 stop using one or both of these servers in the event of such failure. 686 However, as above, malicious Targets and Proxies are out of scope for 687 the threat model. 689 10.2. Proxy Policies 691 Proxies are free to enforce any forwarding policy they desire for 692 clients. For example, they may only forward requests to known or 693 otherwise trusted targets. 695 10.3. Authentication 697 Depending on the deployment scenario, Proxies and Targets MAY require 698 authentication before use. Regardless of the authentication 699 mechanism in place, Proxies MUST NOT reveal any client authentication 700 information to Targets. This is required so targets cannot uniquely 701 identify individual clients. 703 Note that if Targets require Proxies to authenticate at the HTTP- or 704 application-layer before use, this SHOULD be done before attempting 705 to forward any client query to the Target. This will allow Proxies 706 to distinguish 401 Unauthorized response codes due to authentication 707 failure from 401 Unauthorized response codes due to client key 708 mismatch; see Section 4.3. 710 10.4. General Proxy Services 712 Using DoH over anonymizing proxy services such as Tor would also 713 achieve the desired goal of separating query origins from their 714 contents. However, there are several reasons why such systems are 715 undesirable in comparison Oblivious DoH: 717 1. Tor is also meant as a generic connection-level anonymity system, 718 and thus seems overly complex and costly for the purpose of 719 proxying individual DoH queries. In contrast, Oblivious DoH is a 720 lightweight extension to standard DoH, implemented as an 721 application-layer proxy, that can be enabled as a default mode 722 for users which need increased privacy. 724 2. As a one-hop proxy, Oblivious DoH encourages connection-less 725 proxies to mitigate client query correlation with few round- 726 trips. In contrast, multi-hop systems such as Tor often run 727 secure connections (TLS) end-to-end, which means that DoH servers 728 could track queries over the same connection. Using a fresh DoH 729 connection per query would incur a non-negligible penalty in 730 connection setup time. 732 11. IANA Considerations 734 11.1. Oblivious DoH Message Media Type 736 This document registers a new media type, "application/oblivious-dns- 737 message". 739 Type name: application 741 Subtype name: oblivious-dns-message 742 Required parameters: N/A 744 Optional parameters: N/A 746 Encoding considerations: This is a binary format, containing 747 encrypted DNS requests and responses, as defined in this document. 749 Security considerations: See this document. The content is an 750 encrypted DNS message, and not executable code. 752 Interoperability considerations: This document specifies format of 753 conforming messages and the interpretation thereof. 755 Published specification: This document. 757 Applications that use this media type: This media type is intended to 758 be used by clients wishing to hide their DNS queries when using DNS 759 over HTTPS. 761 Additional information: N/A 763 Person and email address to contact for further information: See 764 Authors' Addresses section 766 Intended usage: COMMON 768 Restrictions on usage: N/A 770 Author: Tommy Pauly tpauly@apple.com (mailto:tpauly@apple.com) 772 Change controller: Tommy Pauly tpauly@apple.com 773 (mailto:tpauly@apple.com) 775 Provisional registration? (standards tree only): No 777 12. Acknowledgments 779 This work is inspired by Oblivious DNS 780 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 781 that document. Thanks to Nafeez Ahamed, Elliot Briggs, Marwan Fayed, 782 Frederic Jacobs, Tommy Jensen, Jonathan Hoyland, Paul Schmitt, Brian 783 Swander, Erik Nygren, and Peter Wu for the feedback and input. 785 13. References 787 13.1. Normative References 789 [I-D.ietf-httpbis-proxy-status] 790 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 791 Response Header Field", Work in Progress, Internet-Draft, 792 draft-ietf-httpbis-proxy-status-06, 16 August 2021, 793 . 796 [I-D.irtf-cfrg-hpke] 797 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 798 "Hybrid Public Key Encryption", Work in Progress, 799 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 800 . 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, 805 DOI 10.17487/RFC2119, March 1997, 806 . 808 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 809 "Randomness Requirements for Security", BCP 106, RFC 4086, 810 DOI 10.17487/RFC4086, June 2005, 811 . 813 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 814 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 815 DOI 10.17487/RFC7231, June 2014, 816 . 818 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 819 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 820 RFC 7234, DOI 10.17487/RFC7234, June 2014, 821 . 823 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 824 Protocol (HTTP/1.1): Authentication", RFC 7235, 825 DOI 10.17487/RFC7235, June 2014, 826 . 828 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 829 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 830 May 2017, . 832 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 833 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 834 . 836 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 837 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 838 October 2018, . 840 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 841 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 842 . 844 13.2. Informative References 846 [I-D.annee-dprive-oblivious-dns] 847 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 848 "Oblivious DNS - Strong Privacy for DNS Queries", Work in 849 Progress, Internet-Draft, draft-annee-dprive-oblivious- 850 dns-00, 2 July 2018, . 853 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 854 RFC 7239, DOI 10.17487/RFC7239, June 2014, 855 . 857 Authors' Addresses 859 Eric Kinnear 860 Apple Inc. 861 One Apple Park Way 862 Cupertino, California 95014, 863 United States of America 865 Email: ekinnear@apple.com 867 Patrick McManus 868 Fastly 870 Email: mcmanus@ducksong.com 872 Tommy Pauly 873 Apple Inc. 874 One Apple Park Way 875 Cupertino, California 95014, 876 United States of America 878 Email: tpauly@apple.com 879 Tanya Verma 880 Cloudflare 881 101 Townsend St 882 San Francisco, 883 United States of America 885 Email: vermatanyax@gmail.com 887 Christopher A. Wood 888 Cloudflare 889 101 Townsend St 890 San Francisco, 891 United States of America 893 Email: caw@heapingbits.net