idnits 2.17.1 draft-jabley-dnsop-dns-onion-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 (March 5, 2014) is 3699 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bortzmeyer-dnsop-dns-privacy-01 Summary: 0 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 R. Arends 3 Internet-Draft Nominet 4 Intended status: Informational J. Abley 5 Expires: September 6, 2014 J. Damas 6 Dyn, Inc. 7 March 5, 2014 9 DNS Privacy with a Hint of Onion 10 draft-jabley-dnsop-dns-onion-00 12 Abstract 14 The Domain Name System (DNS) has no inherent capability to protect 15 the privacy of end users. The data associated with DNS queries and 16 responses can be observed by intermediate systems, and such 17 observations could provide a source of metadata relating to end user 18 behaviour. 20 This document describes an approach which separates the data in DNS 21 queries and responses from the identity of the DNS resolver used by 22 DNS clients. 24 This approach does not address privacy concerns between a stub 25 resolver and a recursive resolver. 27 This approach imposes no requirement for modification of authority 28 servers, and does not depend upon widespread deployment of DNSSEC 29 signing or validation. 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 http://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 September 6, 2014. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Notes to Readers . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. General Approach . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Operational Considerations . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 13 76 A.1. Change History . . . . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The Domain Name System (DNS), as described in [RFC1034] and 82 [RFC1035], has no inherent capability to protect the privacy of end 83 users. Privacy concerns are described in 84 [I-D.bortzmeyer-dnsop-dns-privacy] and 85 [I-D.koch-perpass-dns-confidentiality]. 87 This document describes an approach which separates the data in DNS 88 queries and responses from the identity of the DNS resolver used by 89 DNS clients. 91 This approach does not address privacy between a stub resolver and a 92 recursive resolver. 94 This approach imposes no requirement for modification of authority 95 servers, and does not depend upon widespread deployment of DNSSEC 96 signing or validation. 98 The approach described here is derived from (and is similar or 99 identical in many respects to) the Tor project [Tor]. The motivation 100 to write up a DNS-specific, Tor-like solution is to explore 101 opportunities to optimise the solution space specifically for the 102 DNS, e.g. for very short-lived transactions. 104 2. Notes to Readers 106 This is an incomplete proposal. It has been distributed in its 107 current form for the purposes of discussion, such that the high-level 108 approach can be considered amongst other options in the general 109 consideration of DNS privacy. 111 The authors have called out particular gaps in this document. The 112 authors are confident that there are many other gaps that have not 113 been mentioned. The absence of a description of a gap in this 114 document does not imply there is no gap. Contents may have settled 115 in transit. Your statutory rights are not affected. 117 The origins of this document lie in a beer-soaked afternoon 118 conversation in the lobby bar of the Hilton Metropole, London, UK. 119 Should this document play any future part in preserving human life or 120 dignity, the authors recommend the installation of a small but 121 elegant brass plaque, the text embossed upon which should naturally 122 be encrypted. 124 3. Nomenclature 126 The following terms used in this document are intended in the sense 127 described below, in the interests of avoiding ambiguity. The 128 definitions presented here are abridged and tilted towards the 129 subject matter of this document. For more exhaustive treatment 130 please consult [RFC1034] and [RFC1035]. 132 Authority Server A DNS component that provides authoritative 133 responses on behalf of a Zone Manager, typically in response to 134 queries received from Recursive Resolvers (q.v.); also known as 135 "authoritative server" and "authoritative-only server". 137 Recursive Resolver A DNS component that finds answers for queries on 138 behalf of a Stub Resolver (q.v.). A Recursive resolver draws upon 139 data stored in a local cache and fills in where necessary using an 140 iterative process of sending relevant queries to Authority 141 Servers. A Recursive Resolver may be located on the same host as 142 its dependant Stub Resolver, or it may be located on a different 143 host and be used remotely across a network by multiple Stub 144 Resolvers. 146 Stub Resolver A DNS component, present on a host used locally by an 147 end user, that sends DNS queries to and receives responses from a 148 Recursive Resolver (q.v.) 150 Zone Manager The party responsible for the contents of a DNS zone, 151 and consequently (directly or indirectly) for the provisioning of 152 the Authority Servers (q.v.) for that zone. 154 The following terms are specific to this proposal, and are used in 155 this document accordingly. These are not terms commonly used within 156 the taxonomy of DNS. See Section 4 for more details. 158 Entry Resolver A component of a Recursive Resolver service which 159 accepts queries from a Stub Resolver, encrypts the query towards 160 one or more Relay Resolvers and an Exit Resolver, and forwards 161 towards the first Relay Resolver. 163 Relay Resolver A component of a Recursive Resolver service that 164 accepts an encrypted query from an Entry Resolver, decrypts it and 165 forwards it to the next Relay Resolver. 167 Exit Resolver The last Relay Resolver in a chain of Relay Resolvers. 169 4. General Approach 171 For the purposes of this document, consider that the network path 172 between a Stub Resolver and a Recursive Resolver is entirely 173 trustworthy. The Recursive Resolver might run on the same host as 174 the Stub Resolver, for example, or might lie within the same trust 175 perimeter as the Stub Resolver in an enterprise network. 177 A query received by an Entry Resolver is assigned a chain of Relay 178 Resolvers, the number and choice of which are decided according to 179 local policy. The Entry Resolver must have available a public key 180 and knowledge of and capability of using the appropriate 181 corresponding encryption algorithm for each selected Relay Resolver 182 along the chain. 184 ,------. ,----------------. 185 | Stub | ----===----> | Entry Resolver | 186 `------' ^ `----------------' 187 | 188 `---- [ Standard-format DNS request ] 190 An Entry Resolver generates a symmetric session key and encrypts it 191 towards the Exit Resolver. 193 The Entry Resolver encrypts the query once for each Relay Resolver on 194 the selected chain, in order. 196 The Entry Resolver constructs a package that consists of the 197 encrypted session key and the multiply-encrypted (onion-wrapped) 198 query and forwards it to the first Relay Resolver. 200 ,----------------. ,------------------. 201 | Entry Resolver | ----===----> | Relay Resolver 1 | 202 `----------------' ^ `------------------' 203 | 204 `---- [ encrypted session key, 205 onion-wrapped query ] 207 Each Relay Resolver in the chain decrypts the query and identifies 208 from the result the next Relay Resolver in the chain. The source of 209 the query from the Relay Resolver's perspective (the Entry Resolver, 210 or the previous Relay Resolver) is encrypted towards the Relay 211 Resolver itself and included in the package with the peeled query. 212 The resulting package is forwarded to the next Relay Resolver in the 213 chain. 215 ,------------------. ,------------------. 216 | Relay Resolver 1 | ----===----> | Relay Resolver 2 | 217 `------------------' ^ `------------------' 218 | 219 `---- [ encrypted session key, 220 onion-wrapped query (peeled once), 221 onion-wrapped path (wrapped once) ] 223 A Relay Resolver that receives a package in which the query component 224 is encrypted only towards itself is the Exit Resolver for this chain. 225 The Relay Resolver decrypts the query and follows the normal DNS 226 Resolver process to obtain a response. 228 ,---------------. ,--------------------------. 229 | Exit Resolver | ----===----> | Various Authorit Servers | 230 `---------------' ^ `--------------------------' 231 | | 232 ( local cache ) `---- [ standard-format DNS requests ] 234 The Exit Resolver obtains the session key from the original package 235 and encrypts the response using it. The Exit Resolver then sends the 236 package back down the chain, each Relay Resolver in turn identifying 237 the next hop for the package using the directions it encrypted on the 238 forward path. 240 ,----------------------. ,---------------. 241 | Relay Resolver [i-1] | <---===---- | Exit Resolver | 242 `----------------------' ^ `---------------' 243 | 244 `--- [ encrypted response, 245 onion-wrapped path ] 247 Once the response is received by the Entry resolver, it is decrypted 248 with the session key and a response is dispatched to the original 249 stub resolver. 251 ,---------------. ,----------------. 252 | Stub Resolver | <---===---- | Entry Resolver | 253 `---------------' ^ `----------------' 254 | 255 `--- [ standard-format DNS response ] 257 5. Operational Considerations 259 An Entry Resolver might be primed with information about a large 260 number of candidate Relay Resolvers, together with local policy 261 relating to the minimum chain length required for particular (or, 262 e.g., any) outbound queries. An Entry Resolver might build random 263 chains from the available pool of Entry Resolvers and select between 264 them when dealing with particular queries. 266 Care should be taken when re-using session keys for particular Exit 267 Resolvers, since repeated use of the same session keys might be used 268 to identify that different queries originate from the same user. A 269 sufficiently large pool of candidate chains might provide an 270 opportunity for session key regeneration in parallel to query 271 processing. 273 An Entry Resolver might be configured to send padding queries down 274 particular chains (e.g. CHAOS-class queries that can be resolved 275 cheaply on an Exit Resolver) in order to reduce the opportunity to 276 compare query frequency between different Resolver Relays and make 277 inferences about chain construction by particular Entry Resolvers. 279 All Relay Resolvers ought to be usable as Exit Resolvers, and hence 280 every Relay Resolver has an opportunity to build and maintain a DNS 281 cache in the manner of a conventional DNS Resolver. The cache of 282 course will only be used in the event that a particular Relay 283 Resolver is acting as an Exit Resolver for a particular chain. 285 It should be expected that particular Relay Resolvers will become 286 unavailable from time to time, e.g. due to scheduled maintenance or 287 unexpected device failure. Entry Resolvers should time out and retry 288 in the event that a chain is broken, and should take observed failure 289 into account when building candidate chains for use for queries yet 290 to be sent. 292 There is no requirement for the communication between Entry Resolvers 293 and Relay Resolvers, or between Relay Resolvers, to use the DNS 294 protocol. We might imagine that communication being made using 295 modern APIs and dynamically-provisioned pools of TCP sessions, for 296 example. The only requirement for the standard DNS protocol is 297 between the Stub Resolver and the Entry Resolver, and between the 298 Exit Resolver and Authority Servers. 300 6. Security Considerations 302 This document describes an approach for improving the privacy of the 303 DNS, reducing opportunities to map an end user identity to data 304 present in the DNS queries triggered by end user behaviour. 306 This document does not include an assessment of the impact of the 307 proposed approach on the use of the DNS to launch denial of service 308 (or other) attacks. Such analysis seems prudent to include in future 309 revisions of this document, should there be interest in proceeding 310 with it. 312 The ability of a chain of Relay Resolvers to provide privacy for an 313 Entry Resolver depends on choosing a chain that crosses privacy 314 domains (e.g. organisational or geopolitical boundaries). This 315 document is missing guidance on how this might be done reliably. 317 7. IANA Considerations 319 This document makes no request of the IANA. 321 8. Acknowledgements 323 Many aspects of the approach described in this document are similar 324 or identical to the approach taken in the design and implemnetation 325 of The Onion Router [Tor], a project which has produced software that 326 is widely-used to protect end-user privacy. 328 Also, your name here, etc. 330 9. References 332 9.1. Normative References 334 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 335 STD 13, RFC 1034, November 1987. 337 [RFC1035] Mockapetris, P., "Domain names - implementation and 338 specification", STD 13, RFC 1035, November 1987. 340 9.2. Informative References 342 [I-D.bortzmeyer-dnsop-dns-privacy] 343 Bortzmeyer, S., "DNS privacy problem statement", 344 draft-bortzmeyer-dnsop-dns-privacy-01 (work in progress), 345 December 2013. 347 [I-D.koch-perpass-dns-confidentiality] 348 Koch, P., "Confidentiality Aspects of DNS Data, 349 Publication, and Resolution", 350 draft-koch-perpass-dns-confidentiality-00 (work in 351 progress), November 2013. 353 [Tor] Dingledine, R. and N. Mathewson, "Tor Protocol 354 Specification". 356 Appendix A. Editorial Notes 358 This section (and sub-sections) to be removed prior to publication. 360 A.1. Change History 362 00 Initial idea, circulated for the purposes of entertainment. 364 Authors' Addresses 366 Roy Arends 367 Nominet 368 Sandford Gate 369 Sandy Lane West 370 Oxford OX4 6LB 371 UK 373 Email: roy@nominet.org.uk 375 Joe Abley 376 Dyn, Inc. 377 470 Moore Street 378 London, ON N6C 2C2 379 Canada 381 Phone: +1 519 670 9327 382 Email: jabley@dyn.com 384 Joao Luis Silva Damas 385 Dyn, Inc. 386 Avenida de la Albufera 14 387 San Sebastian de los Reyes, Madrid 28701 388 Spain 390 Email: jdamas@dyn.com