idnits 2.17.1 draft-pauly-dprive-oblivious-doh-05.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 is 1 instance 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 (21 February 2021) is 1160 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 (-08) exists of draft-ietf-httpbis-proxy-status-02 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-07 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. '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 (~~), 4 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: 25 August 2021 Fastly 6 T. Pauly 7 Apple Inc. 8 C.A. Wood 9 Cloudflare 10 21 February 2021 12 Oblivious DNS Over HTTPS 13 draft-pauly-dprive-oblivious-doh-05 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 25 August 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 4 60 4. HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. HTTP Request Example . . . . . . . . . . . . . . . . . . 6 63 4.3. HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. HTTP Response Example . . . . . . . . . . . . . . . . . . 7 65 4.5. HTTP Metadata . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Configuration and Public Key Discovery . . . . . . . . . . . 8 67 6. Configuration and Public Key Format . . . . . . . . . . . . . 8 68 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 9 70 7.2. Encryption and Decryption Routines . . . . . . . . . . . 11 71 8. Oblivious Client Behavior . . . . . . . . . . . . . . . . . . 12 72 9. Oblivious Target Behavior . . . . . . . . . . . . . . . . . . 12 73 10. Compliance Requirements . . . . . . . . . . . . . . . . . . . 13 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 11.1. Denial of Service . . . . . . . . . . . . . . . . . . . 15 76 11.2. Proxy Policies . . . . . . . . . . . . . . . . . . . . . 15 77 11.3. General Proxy Services . . . . . . . . . . . . . . . . . 15 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 12.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 16 80 12.2. Oblivious DoH Public Key DNS Parameter . . . . . . . . . 17 81 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 14.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 90 messages to be transmitted in encrypted HTTP messages. This provides 91 improved confidentiality and authentication for DNS interactions in 92 various circumstances. 94 While DoH can prevent eavesdroppers from directly reading the 95 contents of DNS exchanges, clients cannot send DNS queries and 96 receive answers from servers without revealing their local IP 97 address, and thus information about the identity or location of the 98 client. 100 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 101 increase privacy by ensuring no single DNS server is aware of both 102 the client IP address and the message contents. 104 This document defines Oblivious DoH, an extension to DoH that permits 105 proxied resolution, in which DNS messages are encrypted so that no 106 DoH server can independently read both the client IP address and the 107 DNS message contents. 109 This mechanism is intended to be used as one option for resolving 110 privacy-sensitive content in the broader context of Adaptive DNS 111 [I-D.pauly-dprive-adaptive-dns-privacy]. 113 1.1. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 2. Terminology 123 This document defines the following terms: 125 Oblivious Server: A DoH server that acts as either an Oblivious 126 Proxy or Oblivious Target. 128 Oblivious Proxy: An Oblivious Server that proxies encrypted DNS 129 queries and responses between a client and an Oblivious Target. 131 Oblivious Target: An Oblivious Server that receives and decrypts 132 encrypted client DNS queries from an Oblivious Proxy, and returns 133 encrypted DNS responses via that same Proxy. In order to provide 134 DNS responses, the Target can be a DNS resolver, be co-located 135 with a resolver, or forward to a resolver. 137 Throughout the rest of this document, we use the terms Proxy and 138 Target to refer to an Oblivious Proxy and Oblivious Target, 139 respectively. 141 3. Deployment Requirements 143 Oblivious DoH requires, at a minimum: 145 * Two Oblivious Servers, where one can act as a Proxy, and the other 146 can act as a Target. 148 * Public keys for encrypting DNS queries that are passed from a 149 client through a Proxy to a Target (Section 6). These keys 150 guarantee that only the intended Target can decrypt client 151 queries. 153 The mechanism for discovering and provisioning the DoH URI Templates 154 and public keys is via parameters added to DNS resource records. The 155 mechanism for discovering the public key is described in Section 5. 156 The mechanism for discovering a DoH URI Template is described in 157 [I-D.pauly-add-resolver-discovery]. 159 4. HTTP Exchange 161 Unlike direct resolution, oblivious hostname resolution over DoH 162 involves three parties: 164 1. The Client, which generates queries. 166 2. The Proxy, which receives encrypted queries from the client and 167 passes them on to a Target. 169 3. The Target, which receives proxied queries from the client via 170 the Proxy and produces proxied answers. 172 --- [ Request encrypted with target public key ] --> 173 +---------+ +-----------+ +-----------+ 174 | Client +-------------> Oblivious +-------------> Oblivious | 175 | <-------------+ Proxy <-------------+ Target | 176 +---------+ +-----------+ +-----------+ 177 <-- [ Response encrypted with symmetric key ] --- 179 Figure 1: Obvlivious DoH Exchange 181 4.1. HTTP Request 183 Oblivious DoH queries are created by the Client, and sent to the 184 Proxy. Requests to the Proxy indicate which DoH server to use as a 185 Target by specifying two variables: "targethost", which indicates the 186 host name of the Target server, and "targetpath", which indicates the 187 path on which the Target's DoH server is running. See Section 4.2 188 for an example request. 190 Oblivious DoH messages have no cache value since both requests and 191 responses are encrypted using ephemeral key material. Clients SHOULD 192 prefer using HTTP methods and headers that will prevent unhelpful 193 cache storage of these exchanges (i.e., preferring POST instead of 194 GET). 196 Clients MUST set the HTTP Content-Type header to "application/ 197 oblivious-dns-message" to indicate that this request is an Oblivious 198 DoH query intended for proxying. Clients also SHOULD set this same 199 value for the HTTP Accept header. 201 Proxies must check that client requests are correctly encoded, and 202 MUST return a 4xx (Client Error) if the check fails, along with the 203 Proxy-Status response header with an "error" parameter of type 204 "http_request_error" [I-D.ietf-httpbis-proxy-status]. A correctly 205 encoded request has the HTTP Content-Type header "application/ 206 oblivious-dns-message", and HTTP method POST. If the proxy does not 207 operate as a target, then the request must additionally contain 208 "targethost" and "targetpath" variables. 210 Upon receiving a request that contains a "application/oblivious-dns- 211 message" Content-Type, the DoH server looks for the "targethost" and 212 "targetpath" variables. If the variables are not present, then it is 213 the target of the query, and it can decrypt the query (Section 7). 214 If the variables are present, then the DoH server is acting as a 215 Proxy. If it is a proxy, it is expected to send the request on to 216 the Target using the URI template constructed as "https://targethost/ 217 targetpath". 219 Note that "targethost" may contain a port. Proxies MAY choose to not 220 forward connections to non-standard ports. In such cases, proxies 221 MUST return a 4xx (Client Error) response to the client request, 222 along with Proxy-Status response header with an "error" parameter of 223 type "http_request_error". 225 If the proxy cannot establish a connection to "targethost", it MUST 226 return a 502 (Bad Gateway) response to the client request, along with 227 Proxy-Status response header with an "error" parameter whose type 228 indicates the reason. For example, if DNS resolution fails, the 229 error type might be "dns_timeout", whereas if the TLS connection 230 failed the error type might be "tls_protocol_error". Proxies SHOULD 231 choose an error type that best captures the connection failure. 233 4.2. HTTP Request Example 235 The following example shows how a client requests that a Proxy, 236 "dnsproxy.example.net", forwards an encrypted message to 237 "dnstarget.example.net". The URI template for the Proxy is 238 "https://dnsproxy.example.net/dns-query{?targethost,targetpath}". 239 The URI template for the Target is "https://dnstarget.example.net/ 240 dns-query". 242 :method = POST 243 :scheme = https 244 :authority = dnsproxy.example.net 245 :path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query 246 accept = application/oblivious-dns-message 247 cache-control = no-cache, no-store 248 content-type = application/oblivious-dns-message 249 content-length = 106 251 253 The Proxy then sends the following request on to the Target: 255 :method = POST 256 :scheme = https 257 :authority = dnstarget.example.net 258 :path = /dns-query 259 accept = application/oblivious-dns-message 260 cache-control = no-cache, no-store 261 content-type = application/oblivious-dns-message 262 content-length = 106 264 266 4.3. HTTP Response 268 The response to an Oblivious DoH query is generated by the Target. 269 It MUST set the Content-Type HTTP header to "application/oblivious- 270 dns-message" for all successful responses. The body of the response 271 contains an encrypted DNS message; see Section 7. 273 The response from a Target MUST set the Content-Type HTTP header to 274 "application/oblivious-dns-message" which MUST be forwarded by the 275 Proxy to the Client. A Client MUST only consider a response which 276 contains the Content-Type header in the response before processing 277 the payload. A response without the appropriate header MUST be 278 treated as an error and be handled appropriately. All other aspects 279 of the HTTP response and error handling are inherited from standard 280 DoH. 282 Proxies MUST forward responses unmodified to clients. Specifically, 283 the HTTP status code generated by Targets must be forwarded to 284 clients unmodified. If a proxy receives a successful response from a 285 target without the "application/oblivious-dns-message" HTTP Content- 286 Type header, it MUST return a 502 (Bad Gateway) response to the 287 client request, along with Proxy-Status response header with an 288 "error" parameter of type "http_protocol_error". 290 4.4. HTTP Response Example 292 The following example shows a 2xx (Successful) response that can be 293 sent from a Target to a client via a Proxy. 295 :status = 200 296 content-type = application/oblivious-dns-message 297 content-length = 154 299 301 Requests that cannot be processed by the target result in 4xx (Client 302 Error) responses. If the target and client keys do not match, it is 303 an authorization failure (HTTP status code 401; see Section 3.1 of 304 [RFC7235]). Otherwise, if the client's request is invalid, such as 305 in the case of decryption failure, wrong message type, or 306 deserialization failure, this is a bad request (HTTP status code 400; 307 see Section 6.5.1 of [RFC7231]). 309 Even in case of DNS responses indicating failure, such as SERVFAIL or 310 NXDOMAIN, a successful HTTP response with a 2xx status code is used 311 as long as the DNS response is valid. This is similar to how DoH 312 [RFC8484] handles HTTP response codes. 314 In case of server error, the usual HTTP status code 500 (see 315 Section 6.6.1 of [RFC7231]) applies. 317 4.5. HTTP Metadata 319 Proxies forward requests and responses between clients and targets as 320 specified in Section 4.1. Metadata sent with these messages may 321 inadvertently weaken or remove Oblivious DoH privacy properties. 322 Proxies MUST NOT send any client-identifying information about 323 clients to targets, such as "Forwarded" HTTP headers [RFC7239]. 324 Additionally, clients MUST NOT include any private state in requests 325 to proxies, such as HTTP cookies. 327 5. Configuration and Public Key Discovery 329 In order to use a DoH server as a Target, the client must know a 330 public key to use for encrypting its queries. This document 331 specifies one discovery mechanism for public keys using the SVCB or 332 HTTPSSVC record type ([I-D.ietf-dnsop-svcb-https]) for a name owned 333 by the server. 335 The Service Binding key name is "odohconfig" (Section 12). If 336 present, this key/value pair contains the public key to use when 337 encrypting Oblivious DoH messages that will be targeted at a DoH 338 server. The format of the key is defined in (Section 6). 340 Clients that use this discovery mechansim MUST only use keys that 341 were retrieved from records protected by DNSSEC [RFC4033] to encrypt 342 messages to a Target. 344 Servers SHOULD rotate public keys regularly. It is RECOMMENDED that 345 servers rotate keys every day. Shorter rotation windows reduce the 346 anonymity set of clients that might use the public key, whereas 347 longer rotation windows widen the timeframe of possible compromise. 349 6. Configuration and Public Key Format 351 An Oblivious DNS public key configuration is a structure encoded, 352 using TLS-style encoding [RFC8446], as follows: 354 struct { 355 uint16 kem_id; 356 uint16 kdf_id; 357 uint16 aead_id; 358 opaque public_key<1..2^16-1>; 359 } ObliviousDoHConfigContents; 361 struct { 362 uint16 version; 363 uint16 length; 364 select (ObliviousDoHConfig.version) { 365 case 0xff05: ObliviousDoHConfigContents contents; 366 } 367 } ObliviousDoHConfig; 369 ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>; 371 The "ObliviousDoHConfigs" structure contains one or more 372 "ObliviousDoHConfig" structures in decreasing order of preference. 373 This allows a server to support multiple versions of Oblivious DoH 374 and multiple sets of Oblivious DoH parameters. 376 An "ObliviousDoHConfig" contains a versioned representation of an 377 Oblivious DoH configuration, with the following fields. 379 version The version of Oblivious DoH for which this configuration is 380 used. Clients MUST ignore any "ObliviousDoHConfig" structure with 381 a version they do not support. The version of Oblivious DoH 382 specified in this document is "0xff05". 384 length The length, in bytes, of the next field. 386 contents An opaque byte string whose contents depend on the version. 387 For this specification, the contents are an 388 "ObliviousDoHConfigContents" structure. 390 An "ObliviousDoHConfigContents" contains the information needed to 391 encrypt a message under "ObliviousDoHConfigContents.public_key" such 392 that only the owner of the corresponding private key can decrypt the 393 message. The values for "ObliviousDoHConfigContents.kem_id", 394 "ObliviousDoHConfigContents.kdf_id", and 395 "ObliviousDoHConfigContents.aead_id" are described in 396 [I-D.irtf-cfrg-hpke] Section 7. The fields in this structure are as 397 follows: 399 kem_id The HPKE KEM identifier corresponding to "public_key". 400 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 401 using a KEM they do not support. 403 kdf_id The HPKE KDF identifier corresponding to "public_key". 404 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 405 using a KDF they do not support. 407 aead_id The HPKE AEAD identifier corresponding to "public_key". 408 Clients MUST ignore any "ObliviousDoHConfig" structure with a key 409 using an AEAD they do not support. 411 public_key The HPKE public key used by the client to encrypt 412 Oblivious DoH queries. 414 7. Protocol Encoding 416 7.1. Message Format 418 There are two types of Oblivious DoH messages: Queries (0x01) and 419 Responses (0x02). Both messages carry the following information: 421 1. A DNS message, which is either a Query or Response, depending on 422 context. 424 2. Padding of arbitrary length which MUST contain all zeros. 426 They are encoded using the following structure: 428 struct { 429 opaque dns_message<1..2^16-1>; 430 opaque padding<0..2^16-1>; 431 } ObliviousDoHMessagePlaintext; 433 Both Query and Response messages use the 434 "ObliviousDoHMessagePlaintext" format. 436 ObliviousDoHMessagePlaintext ObliviousDoHQuery; 437 ObliviousDoHMessagePlaintext ObliviousDoHResponse; 439 An encrypted "ObliviousDoHMessagePlaintext" is carried in a 440 "ObliviousDoHMessage" message, encoded as follows: 442 struct { 443 uint8 message_type; 444 opaque key_id<0..2^16-1>; 445 opaque encrypted_message<1..2^16-1>; 446 } ObliviousDoHMessage; 448 The "ObliviousDoHMessage" structure contains the following fields: 450 message_type A one-byte identifier for the type of message. Query 451 messages use "message_type" 0x01, and Response messages use 452 "message_type" 0x02. 454 key_id The identifier of the corresponding 455 "ObliviousDoHConfigContents" key. This is computed as 456 "Expand(Extract("", config), "odoh key id", Nh)", where "config" 457 is the ObliviousDoHConfigContents structure and "Extract", 458 "Expand", and "Nh" are as specified by the HPKE cipher suite KDF 459 corresponding to "config.kdf_id". 461 encrypted_message An encrypted message for the Oblivious Target (for 462 Query messages) or client (for Response messages). 463 Implementations MAY enforce limits on the size of this field 464 depending on the size of plaintext DNS messages. (DNS queries, 465 for example, will not reach the size limit of 2^16-1 in practice.) 467 The contents of "ObliviousDoHMessage.encrypted_message" depend on 468 "ObliviousDoHMessage.message_type". In particular, 469 "ObliviousDoHMessage.encrypted_message" is an encryption of a 470 "ObliviousDoHQuery" if the message is a Query, and 471 "ObliviousDoHResponse" if the message is a Response. 473 7.2. Encryption and Decryption Routines 475 Clients use the following utility functions for encrypting a Query 476 and decrypting a Response as described in Section 8. 478 encrypt_query_body: Encrypt an Oblivious DoH query. 480 def encrypt_query_body(pkR, key_id, Q_plain): 481 enc, context = SetupBaseS(pkR, "odoh query") 482 aad = 0x01 || len(key_id) || key_id 483 ct = context.Seal(aad, Q_plain) 484 Q_encrypted = enc || ct 485 return Q_encrypted 487 decrypt_response_body: Decrypt an Oblivious DoH response. 489 def decrypt_response_body(context, Q_plain, R_encrypted): 490 key, nonce = derive_secrets(context, Q_plain) 491 aad = 0x02 || 0x0000 // 0x0000 represents a 0-length KeyId 492 R_plain, error = Open(key, nonce, aad, R_encrypted) 493 return R_plain, error 495 The "derive_secrets" function is described below. 497 Targets use the following utility functions in processing queries and 498 producing responses as described in Section 9. 500 setup_query_context: Set up an HPKE context used for decrypting an 501 Oblivious DoH query. 503 def setup_query_context(skR, key_id, Q_encrypted): 504 enc || ct = Q_encrypted 505 context = SetupBaseR(enc, skR, "odoh query") 506 return context 508 decrypt_query_body: Decrypt an Oblivious DoH query. 510 def decrypt_query_body(context, key_id, Q_encrypted): 511 aad = 0x01 || len(key_id) || key_id 512 enc || ct = Q_encrypted 513 Q_plain, error = context.Open(aad, ct) 514 return Q_plain, error 516 derive_secrets: Derive keying material used for encrypting an 517 Oblivious DoH response. 519 def derive_secrets(context, Q_plain): 520 odoh_secret = context.Export("odoh secret", 32) 521 odoh_prk = Extract(Q_plain, odoh_secret) 522 key = Expand(odoh_prk, "odoh key", Nk) 523 nonce = Expand(odoh_prk, "odoh nonce", Nn) 524 return key, nonce 526 encrypt_response_body: Encrypt an Oblivious DoH response. 528 def encrypt_response_body(R_plain, answer_key, answer_nonce): 529 aad = 0x02 || 0x0000 // 0x0000 represents a 0-length KeyId 530 R_encrypted = Seal(answer_key, answer_nonce, aad, R_plain) 531 return R_encrypted 533 8. Oblivious Client Behavior 535 Let "M" be a DNS message (query) a client wishes to protect with 536 Oblivious DoH. When sending an Oblivious DoH Query for resolving "M" 537 to an Oblivious Target with "ObliviousDoHConfigContents" "config", a 538 client does the following: 540 1. Create an "ObliviousDoHQuery" structure, carrying the message M 541 and padding, to produce Q_plain. 543 2. Deserialize "config.public_key" to produce a public key pkR of 544 type "config.kem_id". 546 3. Compute the encrypted message as "Q_encrypted = 547 encrypt_query_body(pkR, key_id, Q_plain)", where "key_id" is as 548 computed in Section 7. Note also that "len(key_id)" outputs the 549 length of "key_id" as a two-byte unsigned integer. 551 4. Output a ObliviousDoHMessage message "Q" where "Q.message_type = 552 0x01", "Q.key_id" carries "key_id", and "Q.encrypted_message = 553 Q_encrypted". 555 The client then sends "Q" to the Proxy according to Section 4.1. 556 Once the client receives a response "R", encrypted as specified in 557 Section 9, it uses "decrypt_response_body" to decrypt 558 "R.encrypted_message" and produce R_plain. Clients MUST validate 559 "R_plain.padding" (as all zeros) before using R_plain.dns_message. 561 9. Oblivious Target Behavior 563 Targets that receive a Query message Q decrypt and process it as 564 follows: 566 1. Look up the "ObliviousDoHConfigContents" according to "Q.key_id". 567 If no such key exists, the Target MAY discard the query, and if 568 so, it MUST return a 400 (Client Error) response to the Proxy. 569 Otherwise, let "skR" be the private key corresponding to this 570 public key, or one chosen for trial decryption. 572 2. Compute "context = setup_query_context(skR, Q.key_id, 573 Q.encrypted_message)". 575 3. Compute "Q_plain, error = decrypt_query_body(context, Q.key_id, 576 Q.encrypted_message)". 578 4. If no error was returned, and "Q_plain.padding" is valid (all 579 zeros), resolve "Q_plain.dns_message" as needed, yielding a DNS 580 message M. Otherwise, if an error was returned or the padding 581 was invalid, return a 400 (Client Error) response to the Proxy. 583 5. Create an "ObliviousDoHResponseBody" structure, carrying the 584 message "M" and padding, to produce "R_plain". 586 6. Compute "answer_key, answer_nonce = derive_secrets(context, 587 Q_plain)". 589 7. Compute "R_encrypted = encrypt_response_body(R_plain, answer_key, 590 answer_nonce)". The "key_id" field used for encryption is empty, 591 yielding "0x0000" as part of the AAD. Also, the "Seal" function 592 is that which is associated with the HPKE AEAD. 594 8. Output a "ObliviousDoHMessage" message "R" where "R.message_type 595 = 0x02", "R.key_id = nil", and "R.encrypted_message = 596 R_encrypted". 598 The Target then sends "R" in a 2xx (Successful) response to the 599 Proxy; see Section 4.3. The Proxy forwards the message "R" without 600 modification back to the client as the HTTP response to the client's 601 original HTTP request. In the event of an error (non 2xx status 602 code), the Proxy forwards the Target error to the client; see 603 Section 4.3. 605 10. Compliance Requirements 607 Oblivious DoH uses draft-08 of HPKE for public key encryption 608 [I-D.irtf-cfrg-hpke]. In the absence of an application profile 609 standard specifying otherwise, a compliant Oblivious DoH 610 implementation MUST support the following HPKE cipher suite: 612 * KEM: DHKEM(X25519, HKDF-SHA256) (see [I-D.irtf-cfrg-hpke], 613 Section 7.1) 615 * KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2) 617 * AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3) 619 11. Security Considerations 621 DISCLAIMER: this is a work in progress draft and has not yet seen 622 significant security analysis. 624 Oblivious DoH aims to keep knowledge of the true query origin and its 625 contents known to only clients. As a simplified model, consider a 626 case where there exists two clients C1 and C2, one proxy P, and one 627 target T. Oblivious DoH assumes an extended Dolev-Yao style attacker 628 which can observe all network activity and can adaptively compromise 629 either P or T, but not C1 or C2. Once compromised, the attacker has 630 access to all session information and private key material. (This 631 generalizes to arbitrarily many clients, proxies, and targets, with 632 the constraints that not all targets and proxies are simultaneously 633 compromised, and at least two clients are left uncompromised.) The 634 attacker is prohibited from sending client identifying information, 635 such as IP addresses, to targets. (This would allow the attacker to 636 trivially link a query to the corresponding client.) 638 In this model, both C1 and C2 send an Oblivious DoH queries Q1 and 639 Q2, respectively, through P to T, and T provides answers A1 and A2. 640 The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), 641 respectively. The attacker succeeds if this linkability is possible 642 without any additional interaction. (For example, if T is 643 compromised, it may return a DNS answer corresponding to an entity it 644 controls, and then observe the subsequent connection from a client, 645 learning its identity in the process. Such attacks are out of scope 646 for this model.) 648 Oblivious DoH security prevents such linkability. Informally, this 649 means: 651 1. Queries and answers are known only to clients and targets in 652 possession of the corresponding response key and HPKE keying 653 material. In particular, proxies know the origin and destination 654 of an oblivious query, yet do not know the plaintext query. 655 Likewise, targets know only the oblivious query origin, i.e., the 656 proxy, and the plaintext query. Only the client knows both the 657 plaintext query contents and destination. 659 2. Target resolvers cannot link queries from the same client in the 660 absence of unique per-client keys. 662 Traffic analysis mitigations are outside the scope of this document. 663 In particular, this document does not recommend padding lengths for 664 ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations 665 SHOULD follow the guidance for choosing padding length in [RFC8467]. 667 Oblivious DoH security does not depend on proxy and target 668 indistinguishability. Specifically, an on-path attacker could 669 determine whether a connection a specific endpoint is used for 670 oblivious or direct DoH queries. However, this has no effect on 671 confidentiality goals listed above. 673 11.1. Denial of Service 675 Malicious clients (or proxies) may send bogus Oblivious DoH queries 676 to targets as a Denial-of-Service (DoS) attack. Target servers may 677 throttle processing requests if such an event occurs. Additionally, 678 since Targets provide explicit errors upon decryption failure, i.e., 679 if ciphertext decryption fails or if the plaintext DNS message is 680 malformed, Proxies may throttle specific clients in response to these 681 errors. 683 Malicious Targets or Proxies may send bogus answers in response to 684 Oblivious DoH queries. Response decryption failure is a signal that 685 either the proxy or target is misbehaving. Clients can choose to 686 stop using one or both of these servers in the event of such failure. 687 However, as above, malicious Targets and Proxies are out of scope for 688 the threat model. 690 11.2. Proxy Policies 692 Proxies are free to enforce any forwarding policy they desire for 693 clients. For example, they may only forward requests to known or 694 otherwise trusted targets. Proxies that do not have an allow list of 695 targets can attempt to determine if the specified target is a valid 696 Oblivious DoH target by querying for the target configuration as 697 specified in Section 5. 699 11.3. General Proxy Services 701 Using DoH over anonymizing proxy services such as Tor would also 702 achieve the desired goal of separating query origins from their 703 contents. However, there are several reasons why such systems are 704 undesirable in comparison Oblivious DoH: 706 1. Tor is also meant as a generic connection-level anonymity system, 707 and thus seems overly complex and costly for the purpose of 708 proxying individual DoH queries. In contrast, Oblivious DoH is a 709 lightweight extension to standard DoH, implemented as an 710 application-layer proxy, that can be enabled as a default mode 711 for users which need increased privacy. 713 2. As a one-hop proxy, Oblivious DoH encourages connection-less 714 proxies to mitigate client query correlation with few round- 715 trips. In contrast, multi-hop systems such as Tor often run 716 secure connections (TLS) end-to-end, which means that DoH servers 717 could track queries over the same connection. Using a fresh DoH 718 connection per query would incur a non-negligible penalty in 719 connection setup time. 721 12. IANA Considerations 723 12.1. Oblivious DoH Message Media Type 725 This document registers a new media type, "application/oblivious-dns- 726 message". 728 Type name: application 730 Subtype name: oblivious-dns-message 732 Required parameters: N/A 734 Optional parameters: N/A 736 Encoding considerations: This is a binary format, containing 737 encrypted DNS requests and responses, as defined in this document. 739 Security considerations: See this document. The content is an 740 encrypted DNS message, and not executable code. 742 Interoperability considerations: This document specifies format of 743 conforming messages and the interpretation thereof. 745 Published specification: This document. 747 Applications that use this media type: This media type is intended to 748 be used by clients wishing to hide their DNS queries when using DNS 749 over HTTPS. 751 Additional information: None 752 Person and email address to contact for further information: See 753 Authors' Addresses section 755 Intended usage: COMMON 757 Restrictions on usage: None 759 Author: IETF 761 Change controller: IETF 763 12.2. Oblivious DoH Public Key DNS Parameter 765 This document adds a parameter ("odohconfig") to the "Service Binding 766 (SVCB) Parameter" registry [I-D.ietf-dnsop-svcb-https]. The 767 allocation request is 32769, taken from the to the First Come First 768 Served range. 770 If present, the "odohconfig" parameter contains a ObliviousDoHConfigs 771 structure. In wire format, the value of the parameter is an 772 ObliviousDoHConfigs vector, including the redundant length prefix. 773 In presentation format, the value is encoded in [base64]. 775 Name: odohconfig 777 SvcParamKey: 32769 779 Meaning: An ObliviousDoHConfigs structure. 781 Reference: This document. 783 13. Acknowledgments 785 This work is inspired by Oblivious DNS 786 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 787 that document. Thanks to Nafeez Ahamed, Elliot Briggs, Marwan Fayed, 788 Frederic Jacobs, Tommy Jensen Paul Schmitt, Brian Swander, Tanya 789 Verma, and Peter Wu for the feedback and input. 791 14. References 793 14.1. Normative References 795 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 796 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 797 . 799 [I-D.ietf-dnsop-svcb-https] 800 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 801 and parameter specification via the DNS (DNS SVCB and 802 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 803 dnsop-svcb-https-02, 2 November 2020, 804 . 807 [I-D.ietf-httpbis-proxy-status] 808 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 809 Response Header Field", Work in Progress, Internet-Draft, 810 draft-ietf-httpbis-proxy-status-02, 11 August 2020, 811 . 814 [I-D.irtf-cfrg-hpke] 815 Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid 816 Public Key Encryption", Work in Progress, Internet-Draft, 817 draft-irtf-cfrg-hpke-07, 16 December 2020, 818 . 821 [I-D.pauly-add-resolver-discovery] 822 Pauly, T., Kinnear, E., Wood, C., McManus, P., and T. 823 Jensen, "Adaptive DNS Resolver Discovery", Work in 824 Progress, Internet-Draft, draft-pauly-add-resolver- 825 discovery-01, 13 July 2020, . 828 [I-D.pauly-dprive-adaptive-dns-privacy] 829 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 830 "Adaptive DNS: Improving Privacy of Name Resolution", Work 831 in Progress, Internet-Draft, draft-pauly-dprive-adaptive- 832 dns-privacy-01, 1 November 2019, . 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, 838 DOI 10.17487/RFC2119, March 1997, 839 . 841 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 842 Rose, "DNS Security Introduction and Requirements", 843 RFC 4033, DOI 10.17487/RFC4033, March 2005, 844 . 846 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 847 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 848 DOI 10.17487/RFC7231, June 2014, 849 . 851 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 852 Protocol (HTTP/1.1): Authentication", RFC 7235, 853 DOI 10.17487/RFC7235, June 2014, 854 . 856 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 857 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 858 May 2017, . 860 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 861 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 862 . 864 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 865 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 866 October 2018, . 868 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 869 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 870 . 872 14.2. Informative References 874 [I-D.annee-dprive-oblivious-dns] 875 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 876 "Oblivious DNS - Strong Privacy for DNS Queries", Work in 877 Progress, Internet-Draft, draft-annee-dprive-oblivious- 878 dns-00, 2 July 2018, . 881 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 882 RFC 7239, DOI 10.17487/RFC7239, June 2014, 883 . 885 Authors' Addresses 887 Eric Kinnear 888 Apple Inc. 889 One Apple Park Way 890 Cupertino, California 95014, 891 United States of America 893 Email: ekinnear@apple.com 894 Patrick McManus 895 Fastly 897 Email: mcmanus@ducksong.com 899 Tommy Pauly 900 Apple Inc. 901 One Apple Park Way 902 Cupertino, California 95014, 903 United States of America 905 Email: tpauly@apple.com 907 Christopher A. Wood 908 Cloudflare 909 101 Townsend St 910 San Francisco, 911 United States of America 913 Email: caw@heapingbits.net