idnits 2.17.1 draft-annee-dprive-oblivious-dns-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-dnsop-terminology-bis-10 == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-12 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive A. Edmundson 3 Internet-Draft P. Schmitt 4 Intended status: Experimental N. Feamster 5 Expires: January 3, 2019 Princeton University 6 A. Mankin 7 Salesforce 8 July 2, 2018 10 Oblivious DNS - Strong Privacy for DNS Queries 11 draft-annee-dprive-oblivious-dns-00 13 Abstract 15 Recognizing the privacy vulnerabilities associated with DNS queries, 16 a number of standards have been developed and services deployed that 17 that encrypt a user's DNS queries to the recursive resolver and thus 18 obscure them from some network observers and from the user's Internet 19 service provider. However, these systems merely transfer trust to a 20 third party. We argue that no single party should be able to 21 associate DNS queries with a client IP address that issues those 22 queries. To this end, this document specifies Oblivious DNS (ODNS), 23 which introduces an additional layer of obfuscation between clients 24 and their queries. To accomplish this, ODNS uses its own 25 authoritative namespace; the authoritative servers for the ODNS 26 namespace act as recursive resolvers for the DNS queries that they 27 receive, but they never see the IP addresses for the clients that 28 initiated these queries. The ODNS experimental protocol is 29 compatible with existing DNS infrastructure. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. ODNS Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Sending and Receiving ODNS Queries . . . . . . . . . . . . . 5 69 5. Replication and Privacy-Preserving Key Distribution . . . . . 6 70 5.1. Scalability and Performance Using Anycast . . . . . . . . 6 71 5.2. Key Distribution . . . . . . . . . . . . . . . . . . . . 6 72 5.3. QNAME Length . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 74 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security considerations . . . . . . . . . . . . . . . . . . . 8 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 12.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 Privacy terminology is as described in Section 3 of [RFC6973]. 94 DNS terminology is as described in [I-D.ietf-dnsop-terminology-bis] 95 with one modification: we use the definition of Privacy-enabling DNS 96 server taken from [RFC8310]: 98 2. Introduction 100 Recognizing the privacy vulnerabilities associated with DNS queries, 101 a number of specifications and services have been developed that 102 encrypt a user's DNS queries to the recursive resolver and thus 103 obscure them from some network observers and from the user's Internet 104 service provider. However, these systems merely transfer trust to a 105 third party. We argue that no single party should be able to 106 associate DNS queries with a client IP address that issues those 107 queries, that there should be obfuscation between the client and its 108 queries. 110 DNS queries can reveal significant information about the Internet 111 destinations that a user or device is communicating with. For 112 example, the domain names themselves may reveal the websites that a 113 user is visiting. In the case of smart-home Internet of Things (IoT) 114 devices, the DNS queries may reveal the types of devices in user 115 homes. Previous work has also demonstrated that DNS lookups can 116 identify the websites that a user is visiting, even when they are 117 using an anonymizing service such as Tor [Tor-DNS]. The operator of 118 a DNS resolver may also retain information about DNS queries and 119 responses---including the IP addresses that query the domains and the 120 DNS names that are queries. 122 Other approaches have layered encryption on top of the DNS query 123 stream. For example, DNS-over-TLS [RFC7858], DNS-over-DTLS 124 [RFC8094], and DNS-over-HTTPS [I-D.ietf-doh-dns-over-https] all send 125 DNS queries over an encrypted channel, which prevents an eavesdropper 126 from learning the contents of a DNS lookup but does not prevent the 127 operator of the recursive resolver from linking queries and IP 128 addresses. DNSCurve (ref to be added) uses elliptic curve 129 cryptography to encrypt DNS requests and responses; it also 130 authenticates all DNS responses and eliminates any forged responses. 131 DNSCrypt (ref to be added) encrypts and authenticates DNS traffic 132 between a client and a recursive resolver. None of the approaches 133 prevent the recursive resolver from observing DNS queries and 134 responses. Note: a new draft is under development, targetted to for 135 BCP, that n would offers a policy and best-practices approach to the 136 problem of recursive resolvers's observation of this data. 138 ODNS (1) obfuscates the queries that a recursive resolver sees from 139 the clients that issue DNS queries; and (2) obfuscates the client's 140 IP address from upper levels of the DNS hierarchy that ultimately 141 resolve the query (that is, the authoritative servers). ODNS 142 operates in the context of the existing DNS protocol, allowing the 143 existing deployed infrastructure to remain unchanged. A client sends 144 an encrypted query to a recursive resolver, which then forwards the 145 query to an authoritative DNS server that can resolve ODNS queries. 146 The recursive resolver never sees the DNS domain that the client 147 queries, and the ODNS server never sees the IP address of the client. 149 ODNS requires a modified client stub resolver, and a modified 150 authoritative DNS server. The stub resolver must take an existing 151 DNS name, encrypt it, and append the ODNS domain to ensure that the 152 query is forwarded to the ODNS authoritative DNS server. The 153 authoritative DNS server for ODNS must also act as a recursive DNS 154 resolver; it must not only reply for the ODNS namespace but also 155 ultimately retrieve the DNS record that corresponds to the client's 156 initial query. 158 3. ODNS Overview 160 ODNS operates similarly to conventional DNS, but adds two components: 161 (1)each client runs a modified stub resolver; and (2) ODNS runs an 162 authoritative name server that also acts as a recursive DNS resolver 163 for the original DNS query: 165 o The client's stub resolver obfuscates the domain that the client 166 is requesting (via symmetric encryption), resulting in the 167 client's configured recursive resolver being unaware of the 168 requested domain. 170 o The authoritative name server for ODNS separates the clients' 171 identities from their corresponding DNS requests, such that the 172 name servers cannot learn who is requesting specific domains. 174 As detailed in [RFC7626], operators of recursive DNS resolvers see 175 individual IP addresses along with the fully qualified domain name 176 those IPs request. Operators of authoritative resolvers may also be 177 able to learn information about the client by using one of the 178 extensions to DNS, notably EDNS0 Client Subnet (ECS) [RFC7871]. ECS 179 can reveal information about the user's IP address or subnet to 180 authoritative DNS servers higher in the DNS hierarchy (not only 181 recursive DNS resolvers). ODNS hides a client's IP address from the 182 authoritative name servers at different levels of the DNS hierarchy. 184 The configured (non-ODNS) recursive DNS resolver knows the client IP 185 address but never sees the domain that it queries. ODNS requires the 186 client to use a custom local stub resolver, which hides the requested 187 domain from the recursive resolver. The ODNS stub resolver, which 188 runs at the client, encrypts the original DNS query for the ODNS 189 authoritative DNS server before it appends the domain for the ODNS 190 namespace to the query, which causes the recursive resolver to 191 forward the encrypted domain name on to the ODNS authoritative 192 server. NOTE: for simplicity, we sometimes say that this 193 authoritative server is for .odns, but any authoritative DNS domain 194 can run an ODNS server. Even if there was a TLD, there would be 195 leakage of information, because the IP addresses of clients and 196 recursive resolvers would be seen at the root. Experiments can be 197 done to avoid leakage about queries of this nature through adaptation 198 of [RFC7706]. 200 When an ODNS authoritative DNS server receives a DNS query, it 201 removes any client information from the request (e.g., the client IP 202 address, EDNS0 client subnet information) before performing 203 additional DNS lookups. The ODNS name server then switches to acting 204 as a recursive resolver. The authoritative server forwards any 205 response to the original recursive DNS resolver, which in turn sends 206 the response to the client. 208 The recursive DNS resolver receives the request from the client, but 209 cannot identify the genuine domain. It parses the TLD (.odns) and 210 forwards the request onto the .odns authoritative server. Because 211 the session key was originally encrypted with the authoritative 212 server's public key, the authoritative server can decrypt the session 213 key with its private key, and subsequently decrypt the domain with 214 the session key. The authoritative server then acts as a recursive 215 resolver and contacts the necessary name servers to resolve the 216 domain. Once an answer is obtained, the authoritative server 217 encrypts the domain with the session key, appends the .odns TLD and 218 forwards the response to the recursive DNS resolver. As explained by 219 the use of session keys, the recursive resolver cannot learn the 220 domains a client requests, despite being able to learn who the client 221 is. 223 TODO (in -01 or later): Create an ASCII diagram form of Figure 1 from 224 odns.cs.princeton.edu 226 4. Sending and Receiving ODNS Queries 228 TODO (in -01 or later): Create an ASCII diagram form of Figure 2 from 229 odns.cs.princeton.edu 231 o When a client generates a DNS request, the local stub resolver 232 generates a symmetric session key, encrypts the domain name with 233 the session key, encrypts the session key with the authoritative 234 server's public key, and appends the .odns TLD to the encrypted 235 domain. (www.example.com_k.odns.) The stub also appends the 236 session key encrypted under the ODNS authoritative server's public 237 key k_PK) 239 o The client sends the query in the Additional Information portion 240 of the DNS query to the recursive resolver, which then sends it to 241 the authoritative name server for ODNS. 243 o The authoritative server for ODNS queries decrypts the session 244 key, which it uses to decrypt the domain in the query. 246 o The authoritative server forwards a recursive DNS request to the 247 appropriate name server for the original domain, which then 248 returns the answer to the ODNS server. 250 o The ODNS server returns the answer to the client's recursive 251 resolver. 253 Other authoritative DNS servers see incoming DNS requests, but these 254 only see the IP address of the ODNS authoritative resolver, which 255 effectively proxies the DNS request for the original client. The 256 client's original recursive resolver can learn the client's IP 257 address, but cannot learn the domain names in the client's DNS 258 queries. 260 5. Replication and Privacy-Preserving Key Distribution 262 5.1. Scalability and Performance Using Anycast 264 To achieve scalability the authoritative server is replicated in a 265 variety of geographical locations and all replicas are assigned to 266 both an anycast IP address as well as a unique unicast IP address. 267 Using anycast, all servers that share the IP address are able to 268 answer a query. When a recursive sends a DNS query to the ODNS 269 authoritative server, the query will be routed by BGP to the 270 ``nearest'' authoritative server. And because the recursive resolver 271 (an open resolver) is also anycast, both the recursive and the ODNS 272 authoritative server should be the optimal choices based on the 273 client's network connectivity {\it without revealing the client's 274 location}. This results in maximizing the performance of ODNS by 275 minimizing the network path that queries must traverse. 277 5.2. Key Distribution 279 Use of anycast and multiple authoritative replicas introduce a key 280 distribution challenge for ODNS. The ODNS stub server uses the 281 public key of the authoritative server to encrypt session keys in 282 ODNS queries. Based on best practices, we cannot share public / 283 private keypairs across all of the replicated authoritative servers. 284 Likewise, in order to preserve user identity privacy the key 285 distribution must be done in a way that the authoritative server 286 never learns the identity (i.e., IP address) of a stub. This 287 disqualifies out-of-band key exchange as in EncDNS. Instead, we 288 leverage the DNS infrastructure itself to distribute keys while 289 maintaining privacy. We have defined a ``special'' query (e.g., 290 special.odns) that we use to select a specific authoritative server 291 as well as distribute the appropriate public key. 293 The client's stub resolver sends a special ODNS query to the 294 recursive resolver, which will in turn use the anycast address to 295 locate the nearest authoritative server. The authoritative that 296 receives the query responds with an OPT record that includes a self- 297 certifying name (e.g., ABC.odns), such that the name of the server is 298 derived from the public key itself and is associated with an instance 299 of the authoritative nameserver listening on the unique unicast IP 300 address, and the authoritative server's public key; this response is 301 returned to the client's stub resolver via the recursive. Subsequent 302 ODNS queries at the stub append the unique name of the authoritative 303 that responded to the special query, which means that the requests 304 will all reach the same server and the client encrypt using the 305 appropriate public key. 307 5.3. QNAME Length 309 In principle, a query could include the encrypted query and / or 310 session key in a special Resource Record (RR) in the ``Additional 311 Information'' section of a DNS message (known as an OPT), but we 312 discovered that, in practice, most open resolvers strip all OPT 313 records before forwarding the query on to the authoritative 314 nameserver. In this case, ODNS cannot simply use an OPT to 315 communicate the session key. ODNS overcomes this challenge by 316 placing the encrypted key in the QNAME field of the DNS message; the 317 QNAME field consists of 4 sets of 63 bytes, which limits both the key 318 size and encryption scheme used. For this reason, ODNS uses 16-byte 319 AES session keys and encrypts the session keys using the Elliptic 320 Curve Integrated Encryption Scheme (ECIES)~. Once the session key is 321 encrypted, the resulting value takes up 44 bytes of the QNAME field. 322 In the future, we envision an ODNS-specific OPT code that would cause 323 recursive resolvers to maintain and forward the ODNS OPT record 324 intact to the authoritative nameserver. Such a mechanism allows for 325 the use of larger encryption keys as OPT records can be much larger 326 (typically 4096 bytes) that the space alloted for QNAMEs. 328 6. Backward Compatibility 330 For a new extension to DNS such as ODNS to be widely adopted it must 331 be backward-compatible with existing infrastructure, as changes to 332 the DNS system occur over long time scales. Our design must not rely 333 upon changes made at recursive resolvers, root nameservers, or TLD 334 nameservers. We engineer the ODNS stub and authoritative 335 functionality with this in mind as these two locations in the DNS 336 hierarchy are readily controlled. 338 7. IANA considerations 340 For initial experimental deployment of this protocol, the name 341 obliviousdns.com has been registered. Its length is a drawback, for 342 the reasons discussed in Section 5.3 and a shorter privately 343 registered name may be chosen for future larger-scale 344 experimentation. An infrastructure related zone would be more 345 advantageous choice. Therefore discussion should resolve the 346 appropriateness and conditions of a request for a special use domain 347 name, e.g. odns.arpa. This falls under the considerations in 348 [RFC3172]. Notes: because of restrictions on TLD registration, 349 following the example of .onion [RFC7686] is infeasible. Traffic for 350 ODNS traverses normal Internet paths, therefore the IANA special use 351 registry recently established for Locally-Served DNS Zones, in which 352 home.arpa has recently been registered [RFC8375], is also not a model 353 for IANA considerations for the ODNS Namespace. 355 8. Security considerations 357 TODO (some questions to consider): what are residual risks in the 358 ODNS scheme and additional mitigations? Is there any increase in 359 attack surface for the users and operators in ODNS? Are systems 360 depending on ODNS vulnerable to DoS in specific ways that should be 361 mitigated? 363 9. Acknowledgements 365 10. Contributors 367 The following contributed significantly to the document: 369 11. Changelog 371 draft-annee-dprive-oblivious-dns-00 373 o Initial commit 375 12. References 377 12.1. Normative References 379 [I-D.ietf-dnsop-terminology-bis] 380 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 381 Terminology", draft-ietf-dnsop-terminology-bis-10 (work in 382 progress), April 2018. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 390 Requirements for the Address and Routing Parameter Area 391 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 392 September 2001, . 394 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 395 Morris, J., Hansen, M., and R. Smith, "Privacy 396 Considerations for Internet Protocols", RFC 6973, 397 DOI 10.17487/RFC6973, July 2013, 398 . 400 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 401 Kumari, "Client Subnet in DNS Queries", RFC 7871, 402 DOI 10.17487/RFC7871, May 2016, 403 . 405 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 406 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 407 May 2017, . 409 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 410 for DNS over TLS and DNS over DTLS", RFC 8310, 411 DOI 10.17487/RFC8310, March 2018, 412 . 414 12.2. Informative References 416 [I-D.ietf-doh-dns-over-https] 417 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 418 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 419 progress), June 2018. 421 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 422 DOI 10.17487/RFC7626, August 2015, 423 . 425 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 426 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 427 2015, . 429 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 430 Servers by Running One on Loopback", RFC 7706, 431 DOI 10.17487/RFC7706, November 2015, 432 . 434 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 435 and P. Hoffman, "Specification for DNS over Transport 436 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 437 2016, . 439 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 440 Transport Layer Security (DTLS)", RFC 8094, 441 DOI 10.17487/RFC8094, February 2017, 442 . 444 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 445 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 446 . 448 [Tor-DNS] Reschbach, G., Pulls, B., Roberts, L., Winter, P., and N. 449 Feamster, "The Effect of DNS on Tor's Anonymity", 2016. 451 Authors' Addresses 453 Annie Edmundson 454 Princeton University 455 Princeton, NJ 456 United States 458 Email: annee@cs.princeton.edu 460 Paul Schmitt 461 Princeton University 462 Princeton, NJ 463 United States 465 Email: pschmitt@cs.princeton.edu 467 Nick Feamster 468 Princeton University 469 Princeton, NJ 470 United States 472 Email: nfeamster@cs.princeton.edu 473 Allison Mankin 474 Salesforce 476 Email: allison.mankin@gmail.com