idnits 2.17.1 draft-pauly-dprive-oblivious-doh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 04, 2019) is 1666 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-irtf-cfrg-hpke-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') ** Downref: Normative reference to an Experimental RFC: RFC 8467 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft T. Pauly 4 Intended status: Standards Track C. Wood 5 Expires: April 6, 2020 Apple Inc. 6 P. McManus 7 Fastly 8 October 04, 2019 10 Oblivious DNS Over HTTPS 11 draft-pauly-dprive-oblivious-doh-00 13 Abstract 15 This document describes an extension to DNS Over HTTPS (DoH) that 16 allows hiding client IP addresses via proxying encrypted DNS 17 transactions. This improves privacy of DNS operations by not 18 allowing any one server entity to be aware of both the client IP 19 address and the content of DNS queries and answers. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 3 59 4. HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. HTTP Request Example . . . . . . . . . . . . . . . . . . 5 62 4.3. HTTP Response . . . . . . . . . . . . . . . . . . . . . . 5 63 4.4. HTTP Response Example . . . . . . . . . . . . . . . . . . 5 64 5. Public Key Discovery . . . . . . . . . . . . . . . . . . . . 6 65 6. Oblivious DoH Public Key Format . . . . . . . . . . . . . . . 6 66 7. Oblivious DoH Message Format . . . . . . . . . . . . . . . . 6 67 7.1. Oblivious Queries . . . . . . . . . . . . . . . . . . . . 7 68 7.2. Oblivious Responses . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 10 73 9.2. Oblivious DoH Public Key DNS Parameter . . . . . . . . . 11 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 11.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 83 messages to be transmitted in encrypted HTTP messages. This provides 84 improved confidentiality and authentication for DNS interactions in 85 various circumstances. 87 While DoH can prevent eavesdroppers from directly reading the 88 contents of DNS exchanges, it does not allow clients to send DNS 89 queries and receive answers from servers without revealing their 90 local IP address, and thus information about the identity or location 91 of the client. 93 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 94 allow increased privacy by not allowing any single DNS server to be 95 aware of both the client IP address and the message contents. 97 This document defines Oblivious DoH, an extension to DoH that allows 98 for a proxied mode of resolution, in which DNS messages are encrypted 99 in such a way that no DoH server can independently read both the 100 client IP address and the DNS message contents. 102 This mechanism is intended to be used as one option for resolving 103 privacy-sensitive content in the broader context of Adaptive DNS 104 [I-D.pauly-dprive-adaptive-dns-privacy]. 106 1.1. Specification of Requirements 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2. Terminology 116 This document defines the following terms: 118 Oblivious Proxy: A server that proxies encrypted client DNS queries 119 to a resolution server that will be able to decrypt the query (the 120 Oblivious Target). Oblivious DoH servers can function as proxies, 121 but other non-resolver proxy servers could also be used. 123 Oblivious Target: A resolution server that receives encrypted client 124 DNS queries and generates encrypted DNS responses transferred via 125 an Oblivious Proxy. 127 3. Deployment Requirements 129 Oblivious DoH requires, at a minimum: 131 o Two DoH servers, where one can act as an Oblivious Proxy, and the 132 other can act as an Oblivious Target. 134 o Public keys for encrypting DNS queries that are passed from a 135 client through a proxy to a target (Section 6). These keys 136 guarantee that only the intended Oblivious Target can decrypt 137 client queries. 139 o Client ability to generate random [RFC4086] one-time-use symmetric 140 keys to encrypt DNS responses. These symmetric keys ensure that 141 only the client will be able to decrypt the response from the 142 Oblivious Target. They are only used once to prevent the 143 Oblivious Target from tracking clients based on keys. 145 The mechanism for discovering and provisioning the DoH URI Templates 146 and public keys is via parameters added to DNS resource records. The 147 mechanism for discovering the public key is decribed in Section 5. 148 The mechanism for discovering a DoH URI Template is described in 149 [I-D.pauly-dprive-adaptive-dns-privacy]. 151 4. HTTP Exchange 153 Unlike direct resolution, oblivious hostname resolution over DoH 154 involves three parties: 156 1. The Client, which generates queries. 158 2. The Oblivious Proxy, which is a resolution server that receives 159 encrypted queries from the client and passes them on to another 160 resolution server. 162 3. The Oblivious Target, which is a resolution server that receives 163 proxied queries from the client via the Oblivious Proxy. 165 4.1. HTTP Request 167 Oblivious DoH queries are created by the Client, and sent to the 168 Oblivious Proxy. The proxy's address is determined from the 169 authority of the proxy server's URI, while the authority information 170 of the HTTP request reflects the authority of the target server. 171 Likewise, when connecting to the proxy the client should use the 172 proxy target's information for HTTPS certificate selection via SNI 173 and when validating the resulting certificate. 175 Oblivious DoH messages have no cache value since both requests and 176 responses are encrypted using ephemeral key material. Clients SHOULD 177 prefer using HTTP methods and headers that will prevent unhelpful 178 cache storage of these exchanges (i.e., preferring POST instead of 179 GET). 181 Clients MUST set the HTTP Content-Type header to "application/ 182 oblivious-dns-message" to indicate that this request is an Oblivious 183 DoH query intended for proxying. Clients also SHOULD set this same 184 value for the HTTP Accept header. 186 The HTTP authority information (e.g., the HTTP/2 :authority psuedo- 187 header or the HTTP/1 host header) MUST indicate the hostname of the 188 Oblivious Target (not the Oblivious Proxy that initially receives the 189 request), and the path information MUST conform to the path specified 190 by the Oblivious Target's DoH URI Template. 192 Upon receiving a request that contains a "application/oblivious-dns- 193 message" Content-Type, the DoH server looks at the :authority and 194 :path psuedo-headers. If the fields are equivalent to the DoH 195 server's own hostname and configured path ([RFC7230] Section 2.7.3), 196 then it is the target of the query, and it can decrypt the query 197 (Section 7). If the fields do not indicate the local server, then 198 the server is acting as an Oblivious Proxy. If it is a proxy, it is 199 expected to send the request on to the Oblivious Target based on the 200 authority identified in the HTTP request. 202 4.2. HTTP Request Example 204 The following example shows how a client requests that an Oblivious 205 Proxy, "dnsproxy.example.net", forwards an encrypted message to 206 "dnstarget.example.net". 208 :method = POST 209 :scheme = https 210 :authority = dnstarget.example.net 211 :path = /dns-query 212 accept = application/oblivious-dns-message 213 cache-control = no-cache, no-store 214 content-type = application/oblivious-dns-message 215 content-length = 106 217 219 The Oblivious Proxy then sends the exact same request on to the 220 Oblivious Target, without modification. 222 4.3. HTTP Response 224 The response to an Oblivious DoH query is generated by the Oblivious 225 Target. It MUST set the Content-Type HTTP header to "application/ 226 oblivious-dns-message" for all successful responses. The body of the 227 response contains a DNS message that is encrypted with the client's 228 symmetric key (Section 7). 230 All other aspects of the HTTP response and error handling are 231 inherited from standard DoH. 233 4.4. HTTP Response Example 235 The following example shows a response that can be sent from an 236 Oblivious Target to a client via an Oblivious Proxy. 238 :status = 200 239 content-type = application/oblivious-dns-message 240 content-length = 154 242 244 5. Public Key Discovery 246 In order to use a DoH server as an Oblivious Target, the client must 247 know a public key to use for encrypting its queries. This key can be 248 discovered using the SVCB or HTTPSSVC record type 249 ([I-D.nygren-dnsop-svcb-httpssvc]) for a name owned by the server. 251 The key name is "odohkey", and has an encoded SvcParamKey value of 5. 252 If present, this key/value pair contains the public key to use when 253 encrypting Oblivious DoH messages that will be targeted at a DoH 254 server. The format of the key is defined in (Section 6). 256 Clients MUST only use keys that were retrieved from records protected 257 by DNSSEC [RFC4033] to encrypt messages to an Oblivious Target. 259 6. Oblivious DoH Public Key Format 261 An Oblivious DNS public key is a structure encoded, using TLS-style 262 encoding [RFC8446], as follows: 264 struct { 265 uint16 kem_id; 266 uint16 kdf_id; 267 uint16 aead_id; 268 opaque public_key<1..2^16-1>; 269 } ObliviousDNSKey; 271 It contains the information needed to encrypt a message under 272 ObliviousDNSKey.public_key such that only the owner of the 273 corresponding private key can decrypt the message. The values for 274 ObliviousDNSKey.kem_id, ObliviousDNSKey.kdf_id, and 275 ObliviousDNSKey.aead_id are described in [I-D.irtf-cfrg-hpke] 276 Section 7. For convenience, let Identifier(ObliviousDNSKey) be 277 defined as the SHA256 value of ObliviousDNSKey serialized. 279 7. Oblivious DoH Message Format 281 There are two types of Oblivious DoH messages: Queries (0x01) and 282 Responses (0x02). Both are encoded as follows: 284 struct { 285 uint8 message_type; 286 opaque key_id<0..2^16-1>; 287 opaque encrypted_message<1..2^16-1>; 288 } ObliviousDNSMessage; 290 ObliviousDNSMessage.message_type = 0x01 for Query messages and 291 ObliviousDNSMessage.message_type = 0x02 for Response messages. 292 ObliviousDNSMessage.key_id contains the identifier of the 293 corresponding ObliviousDNSKey key. 294 ObliviousDNSMessage.encrypted_message contains an encrypted message 295 for the Oblivious Target (for Query messages) or client (for Response 296 messages). The following sections describe how these meessage bodies 297 are constructed. 299 7.1. Oblivious Queries 301 Oblivious DoH Query messages must carry the following information: 303 1. A symmetric key under which the DNS response will be encrypted. 304 The AEAD algorithm used for the client's response key is the one 305 associated with the server's public key. 307 2. A DNS query message which the client wishes to resolve. 309 3. Padding of arbitrary length which MUST contain all zeros. 311 The key and message are encoded using the following structure: 313 struct { 314 opaque response_key<1..2^16-1>; 315 opaque dns_message<1..2^16-1>; 316 opaque padding<0..2^16-1>; 317 } ObliviousDNSQueryBody; 319 Let M be a DNS message a client wishes to protect with Oblivious DoH. 320 When sending an Oblivious DoH Query for resolving M to an Oblivious 321 Target with ObliviousDNSKey key pk, a client does the following: 323 1. Generate a random symmetric response_key whose length matches 324 that of the AEAD ciphersuite in pk.aead_id. All randomness must 325 be generated according to [RFC4086]. 327 2. Create an ObliviousDNSQueryBody structure, carrying response_key, 328 the message M, and padding, to produce Q_plain. 330 3. Unmarshal pk.public_key to produce a public key pkR of type 331 pk.kem_id. 333 4. Compute the encrypted message as Q_encrypted = 334 encrypt_query_body(pkR, key_id, Q_plain). key_id is defined as 335 Identifier(pk). 337 5. Output a ObliviousDNSMessage message Q where Q.message_type = 338 0x01, Q.key_id carries Identifier(pk), and Q.encrypted_message = 339 Q_encrypted. 341 The client then sends Q to the Oblivious Proxy according to 342 Section 4.1. 344 def encrypt_query_body(pkR, key_id, Q_plain): 345 enc, context = SetupBaseI(pkR, "odns-query") 346 aad = 0x01 || key_id 347 ct = context.Seal(aad, Q_plain) 348 Q_encrypted = enc || ct 349 return Q_encrypted 351 7.2. Oblivious Responses 353 An Oblivious DoH Response message carries the DNS response 354 (dns_message) along with padding. This message is encrypted with the 355 client's chosen response key. 357 struct { 358 opaque dns_message<1..2^16-1>; 359 opaque padding<0..2^16-1>; 360 } ObliviousDNSResponseBody; 362 Targets that receive a Query message Q decrypt and process it as 363 follows: 365 1. Look up the ObliviousDNSKey according to Q.key_id. If no such 366 key exists, the Target MAY discard the query. Otherwise, let skR 367 be the private key corresponding to this public key, or one 368 chosen for trial decryption, and pk be the corresponding 369 ObliviousDNSKey. 371 2. Compute Q_plain, error = decrypt_query_body(skR, Q.key_id, 372 Q.encrypted_message). 374 3. If no error was returned, and Q_plain.padding is valid (all 375 zeros), resolve Q_plain.dns_message as needed, yielding a DNS 376 message M. 378 4. Create an ObliviousDNSResponseBody structure, carrying the 379 message M and padding, to produce R_plain. 381 5. Compute R_encrypted = encrypt_response_body(R_plain, Q_plain). 382 (See definition for encrypt_response_body below. The key_id 383 field used for encryption is empty, yielding 0x0000 as part of 384 the AAD.) 386 6. Output a ObliviousDNSMessage message R where R.message_type = 387 0x02, R.key_id = nil, and R.encrypted_message = R_encrypted. 389 def decrypt_query_body(skR, key_id, Q_encrypted): 390 enc || ct = Q_encrypted 391 dec, context = SetupBaseR(skR, "odns-query") 392 aad = 0x01 || key_id 393 Q_plain, error = context.Open(aad, ct) 394 return Q_plain, error 396 def encrypt_response_body(R_plain, Q_plain): 397 aad = 0x02 || 0x0000 398 R_encrypted = Seal(Q_plain.response_key, 0^Nn, aad, R_plain) 399 return R_encrypted 401 The Target then sends R to the Proxy according to Section 4.3. 403 The Proxy forwards the message R without modification back to the 404 client as the HTTP response to the client's original HTTP request. 406 Once the client receives the response, it can use its known 407 response_key to decrypt R.encrypted_message, yielding R_plain. 408 Clients MUST validate R_plain.padding (as all zeros) before using 409 R_plain.dns_message. 411 def decrypt_response_body(R_encrypted): 412 aad = 0x02 || 0x0000 413 R_plain = Open(response_key, 0^Nn, aad, R_encrypted) 414 return R_plain 416 8. Security Considerations 418 DISCLAIMER: this is a work in progress draft and has not yet seen 419 significant security analysis. 421 Oblivious DoH aims to achieve the following goals: 423 1. Queries and answers are known only to clients and targets in 424 possession of the corresponding response key and HPKE keying 425 material. 427 2. Queries from the same client are unlinkable in the absence of 428 unique per-client keys. 430 Selection of padding length for ObliviousDNSQueryBody and 431 ObliviousDNSResponseBody is outside the scope of this document. 432 Implementations SHOULD follow the guidance for choosing padding 433 length in [RFC8467]. 435 8.1. Denial of Service 437 Malicious clients (or proxies) may send bogus Oblivious DoH queries 438 to targets as a Denial-of-Service (DoS) attack. Target servers may 439 throttle processing requests if such an event occurs. 441 Malicious targets or proxies may send bogus answers in response to 442 Oblivious DoH queries. Response decryption failure is a signal that 443 either the proxy or target is misbehaving. Clients can choose to 444 stop using one or both of these servers in the event of such failure. 446 9. IANA Considerations 448 9.1. Oblivious DoH Message Media Type 450 This document registers a new media type, "application/oblivious-dns- 451 message". 453 Type name: application 455 Subtype name: oblivious-dns-message 457 Required parameters: N/A 459 Optional parameters: N/A 461 Encoding considerations: This is a binary format, containing 462 encrypted DNS requests and responses, as defined in this document. 464 Security considerations: See this document. The content is an 465 encrypted DNS message, and not executable code. 467 Interoperability considerations: This document specifies format of 468 conforming messages and the interpretation thereof. 470 Published specification: This document. 472 Applications that use this media type: This media type is intended to 473 be used by clients wishing to hide their DNS queries when using DNS 474 over HTTPS. 476 Additional information: None 477 Person and email address to contact for further information: See 478 Authors' Addresses section 480 Intended usage: COMMON 482 Restrictions on usage: None 484 Author: IETF 486 Change controller: IETF 488 9.2. Oblivious DoH Public Key DNS Parameter 490 This document defines one new key to be added to the Service Binding 491 (SVCB) Parameter Registry [I-D.nygren-dnsop-svcb-httpssvc]. 493 Name: odohkey 495 SvcParamKey: 5 497 Meaning: Public key used to encrypt messages in Oblivious DoH 499 Reference: This document. 501 10. Acknowledgments 503 This work is inspired by Oblivious DNS 504 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 505 that document. Thanks to Frederic Jacobs, Elliot Briggs, Paul 506 Schmitt, Brian Swander, and Tommy Jensen for the feedback and input. 508 11. References 510 11.1. Normative References 512 [I-D.irtf-cfrg-hpke] 513 Barnes, R. and K. Bhargavan, "Hybrid Public Key 514 Encryption", draft-irtf-cfrg-hpke-00 (work in progress), 515 July 2019. 517 [I-D.nygren-dnsop-svcb-httpssvc] 518 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 519 and parameter specification via the DNS (DNS SVCB and 520 HTTPSSVC)", draft-nygren-dnsop-svcb-httpssvc-00 (work in 521 progress), September 2019. 523 [I-D.pauly-dprive-adaptive-dns-privacy] 524 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 525 "Adaptive DNS: Improving Privacy of Name Resolution", 526 draft-pauly-dprive-adaptive-dns-privacy (work in 527 progress) , October 2019. 529 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 530 Rose, "DNS Security Introduction and Requirements", 531 RFC 4033, DOI 10.17487/RFC4033, March 2005, 532 . 534 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 535 "Randomness Requirements for Security", BCP 106, RFC 4086, 536 DOI 10.17487/RFC4086, June 2005, 537 . 539 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 540 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 541 . 543 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 544 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 545 October 2018, . 547 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 548 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 549 . 551 11.2. Informative References 553 [I-D.annee-dprive-oblivious-dns] 554 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 555 "Oblivious DNS - Strong Privacy for DNS Queries", draft- 556 annee-dprive-oblivious-dns-00 (work in progress), July 557 2018. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 565 Protocol (HTTP/1.1): Message Syntax and Routing", 566 RFC 7230, DOI 10.17487/RFC7230, June 2014, 567 . 569 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 570 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 571 May 2017, . 573 Authors' Addresses 575 Eric Kinnear 576 Apple Inc. 577 One Apple Park Way 578 Cupertino, California 95014 579 United States of America 581 Email: ekinnear@apple.com 583 Tommy Pauly 584 Apple Inc. 585 One Apple Park Way 586 Cupertino, California 95014 587 United States of America 589 Email: tpauly@apple.com 591 Chris Wood 592 Apple Inc. 593 One Apple Park Way 594 Cupertino, California 95014 595 United States of America 597 Email: cawood@apple.com 599 Patrick McManus 600 Fastly 602 Email: mcmanus@ducksong.com