idnits 2.17.1 draft-ietf-dprive-bcp-op-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6841]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2019) is 1748 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1321 -- Looks like a reference, but probably isn't: '2' on line 1324 -- Looks like a reference, but probably isn't: '3' on line 1326 -- Looks like a reference, but probably isn't: '4' on line 1329 -- Looks like a reference, but probably isn't: '5' on line 1331 -- Looks like a reference, but probably isn't: '6' on line 1333 -- Looks like a reference, but probably isn't: '7' on line 1335 -- Looks like a reference, but probably isn't: '8' on line 1337 -- Looks like a reference, but probably isn't: '9' on line 1339 -- Looks like a reference, but probably isn't: '10' on line 1341 -- Looks like a reference, but probably isn't: '11' on line 1344 -- Looks like a reference, but probably isn't: '12' on line 1347 -- Looks like a reference, but probably isn't: '13' on line 1349 -- Looks like a reference, but probably isn't: '14' on line 1351 -- Looks like a reference, but probably isn't: '15' on line 1354 -- Looks like a reference, but probably isn't: '16' on line 1356 -- Looks like a reference, but probably isn't: '17' on line 1358 -- Looks like a reference, but probably isn't: '18' on line 1505 -- Looks like a reference, but probably isn't: '19' on line 1511 -- Looks like a reference, but probably isn't: '20' on line 1521 -- Looks like a reference, but probably isn't: '21' on line 1534 -- Looks like a reference, but probably isn't: '22' on line 1551 -- Looks like a reference, but probably isn't: '23' on line 1552 -- Looks like a reference, but probably isn't: '24' on line 1555 -- Looks like a reference, but probably isn't: '25' on line 1567 -- Looks like a reference, but probably isn't: '26' on line 1582 -- Looks like a reference, but probably isn't: '27' on line 1582 -- Looks like a reference, but probably isn't: '28' on line 1586 -- Looks like a reference, but probably isn't: '29' on line 1588 -- Looks like a reference, but probably isn't: '30' on line 1595 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) ** Downref: Normative reference to an Informational RFC: RFC 7871 ** Downref: Normative reference to an Informational RFC: RFC 8404 ** Downref: Normative reference to an Experimental RFC: RFC 8467 == Outdated reference: A later version (-15) exists of draft-ietf-dnsop-dns-tcp-requirements-04 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-08 -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun IT 4 Intended status: Best Current Practice B. Overeinder 5 Expires: January 9, 2020 R. van Rijswijk-Deij 6 NLnet Labs 7 A. Mankin 8 Salesforce 9 July 8, 2019 11 Recommendations for DNS Privacy Service Operators 12 draft-ietf-dprive-bcp-op-03 14 Abstract 16 This document presents operational, policy and security 17 considerations for DNS operators who choose to offer DNS Privacy 18 services. With these recommendations, the operator can make 19 deliberate decisions regarding which services to provide, and how the 20 decisions and alternatives impact the privacy of users. 22 This document also presents a framework to assist writers of DNS 23 Privacy Policy and Practices Statements (analogous to DNS Security 24 Extensions (DNSSEC) Policies and DNSSEC Practice Statements described 25 in [RFC6841]). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Privacy related documents . . . . . . . . . . . . . . . . . . 5 64 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Recommendations for DNS privacy services . . . . . . . . . . 6 66 5.1. On the wire between client and server . . . . . . . . . . 7 67 5.1.1. Transport recommendations . . . . . . . . . . . . . . 7 68 5.1.2. Authentication of DNS privacy services . . . . . . . 8 69 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 70 5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11 72 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 73 5.1.7. Impact on Operators . . . . . . . . . . . . . . . . . 12 74 5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13 75 5.2. Data at rest on the server . . . . . . . . . . . . . . . 13 76 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13 77 5.2.2. Data minimization of network traffic . . . . . . . . 14 78 5.2.3. IP address pseudonymization and anonymization methods 15 79 5.2.4. Pseudonymization, anonymization or discarding of 80 other correlation data . . . . . . . . . . . . . . . 16 81 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 82 5.3. Data sent onwards from the server . . . . . . . . . . . . 17 83 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17 84 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18 85 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 86 6. DNS privacy policy and practice statement . . . . . . . . . . 19 87 6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 20 88 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20 89 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21 90 6.2. Current policy and privacy statements . . . . . . . . . . 22 91 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 22 92 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 93 8. Security considerations . . . . . . . . . . . . . . . . . . . 23 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 96 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 99 12.2. Informative References . . . . . . . . . . . . . . . . . 27 100 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 30 102 A.1. Potential increases in DNS privacy . . . . . . . . . . . 30 103 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 30 104 A.3. Related operational documents . . . . . . . . . . . . . . 31 105 Appendix B. IP address techniques . . . . . . . . . . . . . . . 31 106 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 32 107 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33 108 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 33 109 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 33 110 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34 111 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 34 112 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 34 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 115 1. Introduction 117 The Domain Name System (DNS) is at the core of the Internet; almost 118 every activity on the Internet starts with a DNS query (and often 119 several). However the DNS was not originally designed with strong 120 security or privacy mechanisms. A number of developments have taken 121 place in recent years which aim to increase the privacy of the DNS 122 system and these are now seeing some deployment. This latest 123 evolution of the DNS presents new challenges to operators and this 124 document attempts to provide an overview of considerations for 125 privacy focused DNS services. 127 In recent years there has also been an increase in the availability 128 of "public resolvers" [I-D.ietf-dnsop-terminology-bis] which users 129 may prefer to use instead of the default network resolver because 130 they offer a specific feature (e.g. good reachability, encrypted 131 transport, strong privacy policy, filtering (or lack of), etc.). 132 These open resolvers have tended to be at the forefront of adoption 133 of privacy related enhancements but it is anticipated that operators 134 of other resolver services will follow. 136 Whilst protocols that encrypt DNS messages on the wire provide 137 protection against certain attacks, the resolver operator still has 138 (in principle) full visibility of the query data and transport 139 identifiers for each user. Therefore, a trust relationship exists. 140 The ability of the operator to provide a transparent, well 141 documented, and secure privacy service will likely serve as a major 142 differentiating factor for privacy conscious users if they make an 143 active selection of which resolver to use. 145 It should also be noted that the choice of a user to configure a 146 single resolver (or a fixed set of resolvers) and an encrypted 147 transport to use in all network environments has both advantages and 148 disadvantages. For example the user has a clear expectation of which 149 resolvers have visibility of their query data however this resolver/ 150 transport selection may provide an added mechanism to track them as 151 they move across network environments. Commitments from operators to 152 minimize such tracking are also likely to play a role in user 153 selection of resolvers. 155 More recently the global legislative landscape with regard to 156 personal data collection, retention, and pseudonymization has seen 157 significant activity. It is an untested area that simply using a DNS 158 resolution service constitutes consent from the user for the operator 159 to process their query data. The impact of recent legislative 160 changes on data pertaining to the users of both Internet Service 161 Providers and public DNS resolvers is not fully understood at the 162 time of writing. 164 This document has two main goals: 166 o To provide operational and policy guidance related to DNS over 167 encrypted transports and to outline recommendations for data 168 handling for operators of DNS privacy services. 170 o To introduce the DNS Privacy Policy and Practice Statement (DPPPS) 171 and present a framework to assist writers of this document. A 172 DPPPS is a document that an operator can publish outlining their 173 operational practices and commitments with regard to privacy 174 thereby providing a means for clients to evaluate the privacy 175 properties of a given DNS privacy service. In particular, the 176 framework identifies the elements that should be considered in 177 formulating a DPPPS. This document does not, however, define a 178 particular Policy or Practice Statement, nor does it seek to 179 provide legal advice or recommendations as to the contents. 181 A desired operational impact is that all operators (both those 182 providing resolvers within networks and those operating large anycast 183 services) can demonstrate their commitment to user privacy thereby 184 driving all DNS resolution services to a more equitable footing. 185 Choices for users would (in this ideal world) be driven by other 186 factors e.g. differing security policies or minor difference in 187 operator policy rather than gross disparities in privacy concerns. 189 Community insight [or judgment?] about operational practices can 190 change quickly, and experience shows that a Best Current Practice 191 (BCP) document about privacy and security is a point-in-time 192 statement. Readers are advised to seek out any errata or updates 193 that apply to this document. 195 2. Scope 197 "DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis] 198 describes the general privacy issues and threats associated with the 199 use of the DNS by Internet users and much of the threat analysis here 200 is lifted from that document and from [RFC6973]. However this 201 document is limited in scope to best practice considerations for the 202 provision of DNS privacy services by servers (recursive resolvers) to 203 clients (stub resolvers or forwarders). Privacy considerations 204 specifically from the perspective of an end user, or those for 205 operators of authoritative nameservers are out of scope. 207 This document includes (but is not limited to) considerations in the 208 following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]): 210 1. Data "on the wire" between a client and a server 212 2. Data "at rest" on a server (e.g. in logs) 214 3. Data "sent onwards" from the server (either on the wire or shared 215 with a third party) 217 Whilst the issues raised here are targeted at those operators who 218 choose to offer a DNS privacy service, considerations for areas 2 and 219 3 could equally apply to operators who only offer DNS over 220 unencrypted transports but who would like to align with privacy best 221 practice. 223 3. Privacy related documents 225 There are various documents that describe protocol changes that have 226 the potential to either increase or decrease the privacy of the DNS. 227 Note this does not imply that some documents are good or bad, better 228 or worse, just that (for example) some features may bring functional 229 benefits at the price of a reduction in privacy and conversely some 230 features increase privacy with an accompanying increase in 231 complexity. A selection of the most relevant documents are listed in 232 Appendix A for reference. 234 4. Terminology 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in BCP 239 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 DNS terminology is as described in [I-D.ietf-dnsop-terminology-bis] 243 with one modification: we restate the clause in the original 244 definition of Privacy-enabling DNS server in [RFC8310] to include the 245 requirement that a DNS over (D)TLS server should also offer at least 246 one of the credentials described in Section 8 and implement the 247 (D)TLS profile described in Section 9 of [RFC8310]. 249 Other Terms: 251 o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6. 253 o DNS privacy service: The service that is offered via a privacy- 254 enabling DNS server and is documented either in an informal 255 statement of policy and practice with regard to users privacy or a 256 formal DPPPS. 258 5. Recommendations for DNS privacy services 260 We describe two classes of threats: 262 o 'Privacy Considerations for Internet Protocols' [RFC6973] Threats 264 * Privacy terminology, threats to privacy and mitigations as 265 described in Sections 3, 5 and 6 of [RFC6973]. 267 o DNS Privacy Threats 269 * These are threats to the users and operators of DNS privacy 270 services that are not directly covered by [RFC6973]. These may 271 be more operational in nature such as certificate management or 272 service availability issues. 274 We describe three classes of actions that operators of DNS privacy 275 services can take: 277 o Threat mitigation for well understood and documented privacy 278 threats to the users of the service and in some cases to the 279 operators of the service. 281 o Optimization of privacy services from an operational or management 282 perspective 284 o Additional options that could further enhance the privacy and 285 usability of the service 287 This document does not specify policy only best practice, however for 288 DNS Privacy services to be considered compliant with these best 289 practice guidelines they SHOULD implement (where appropriate) all: 291 o Threat mitigations to be minimally compliant 293 o Optimizations to be moderately compliant 295 o Additional options to be maximally compliant 297 5.1. On the wire between client and server 299 In this section we consider both data on the wire and the service 300 provided to the client. 302 5.1.1. Transport recommendations 304 [RFC6973] Threats: 306 o Surveillance: 308 * Passive surveillance of traffic on the wire 309 [I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.4.2. 311 DNS Privacy Threats: 313 o Active injection of spurious data or traffic 315 Mitigations: 317 A DNS privacy service can mitigate these threats by providing service 318 over one or more of the following transports 320 o DNS-over-TLS [RFC7858] and [RFC8310] 322 o DoH [RFC8484] 324 It is noted that a DNS privacy service can also be provided over DNS- 325 over-DTLS [RFC8094], however this is an Experimental specification 326 and there are no known implementations at the time of writing. 328 It is also noted that DNS privacy service might be provided over 329 IPSec, DNSCrypt or VPNs. However, use of these transports for DNS 330 are not standardized and any discussion of best practice for 331 providing such a service is out of scope for this document. 333 Whilst encryption of DNS traffic can protect against active injection 334 this does not diminish the need for DNSSEC, see Section 5.1.4. 336 5.1.2. Authentication of DNS privacy services 338 [RFC6973] Threats: 340 o Surveillance: 342 * Active attacks that can redirect traffic to rogue servers 343 [I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3. 345 Mitigations: 347 DNS privacy services should ensure clients can authenticate the 348 server. Note that this, in effect, commits the DNS privacy service 349 to a public identity users will trust. 351 When using DNS-over-TLS clients that select a 'Strict Privacy' usage 352 profile [RFC8310] (to mitigate the threat of active attack on the 353 client) require the ability to authenticate the DNS server. To 354 enable this, DNS privacy services that offer DNS-over-TLS should 355 provide credentials in the form of either X.509 certificates or SPKI 356 pinsets. 358 When offering DoH [RFC8484], HTTPS requires authentication of the 359 server as part of the protocol. 361 NOTE: At this time the reference to the TLS DNSSEC chain extension 362 draft has been removed as it is no longer considered an active TLS WG 363 document. 365 Optimizations: 367 DNS privacy services can also consider the following capabilities/ 368 options: 370 o As recommended in [RFC8310] providing DANE TLSA records for the 371 nameserver 373 * In particular, the service could provide TLSA records such that 374 authenticating solely via the PKIX infrastructure can be 375 avoided. 377 5.1.2.1. Certificate management 379 Anecdotal evidence to date highlights the management of certificates 380 as one of the more challenging aspects for operators of traditional 381 DNS resolvers that choose to additionally provide a DNS privacy 382 service as management of such credentials is new to those DNS 383 operators. 385 It is noted that SPKI pinset management is described in [RFC7858] but 386 that key pinning mechanisms in general have fallen out of favor 387 operationally for various reasons such as the logistical overhead of 388 rolling keys. 390 DNS Privacy Threats: 392 o Invalid certificates, resulting in an unavailable service. 394 o Mis-identification of a server by a client e.g. typos in URLs or 395 authentication domain names 397 Mitigations: 399 It is recommended that operators: 401 o Follow the guidance in Section 6.5 of [RFC7525] with regards to 402 certificate revocation 404 o Choose a short, memorable authentication name for the service 406 o Automate the generation and publication of certificates 408 o Monitor certificates to prevent accidental expiration of 409 certificates 411 5.1.3. Protocol recommendations 413 5.1.3.1. DNS-over-TLS 415 DNS Privacy Threats: 417 o Known attacks on TLS such as those described in [RFC7457] 419 o Traffic analysis, for example: Pitfalls of DNS Encryption [1] 421 o Potential for client tracking via transport identifiers 423 o Blocking of well known ports (e.g. 853 for DNS-over-TLS) 425 Mitigations: 427 In the case of DNS-over-TLS, TLS profiles from Section 9 and the 428 Countermeasures to DNS Traffic Analysis from section 11.1 of 429 [RFC8310] provide strong mitigations. This includes but is not 430 limited to: 432 o Adhering to [RFC7525] 433 o Implementing only (D)TLS 1.2 or later as specified in [RFC8310] 435 o Implementing EDNS(0) Padding [RFC7830] using the guidelines in 436 [RFC8467] 438 o Clients should not be required to use TLS session resumption 439 [RFC5077] or Domain Name System (DNS) Cookies [RFC7873]. 441 o A DNS-over-TLS privacy service on both port 853 and 443. This 442 practice may not be possible if e.g. the operator deploys DoH on 443 the same IP address. 445 Optimizations: 447 o Concurrent processing of pipelined queries, returning responses as 448 soon as available, potentially out of order as specified in 449 [RFC7766]. This is often called 'OOOR' - out-of-order responses. 450 (Providing processing performance similar to HTTP multiplexing) 452 o Management of TLS connections to optimize performance for clients 453 using either 455 * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or 457 * DNS Stateful Operations [I-D.ietf-dnsop-session-signal] 459 Additional options that providers may consider: 461 o Offer a .onion [RFC7686] service endpoint 463 5.1.3.2. DoH 465 DNS Privacy Threats: 467 o Known attacks on TLS such as those described in [RFC7457] 469 o Traffic analysis, for example: DNS Privacy not so private: the 470 traffic analysis perspective [2] 472 o Potential for client tracking via transport identifiers 474 Mitigations: 476 o Clients must be able to forego the use of HTTP Cookies [RFC6265] 477 and still use the service 479 o Clients should not be required to include any headers beyond the 480 absolute minimum to obtain service from a DoH server. (See 481 Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) 483 5.1.4. DNSSEC 485 DNS Privacy Threats: 487 o Users may be directed to bogus IP addresses for e.g. websites 488 where they might reveal personal information to attackers. 490 Mitigations: 492 o All DNS privacy services must offer a DNS privacy service that 493 performs DNSSEC validation. In addition they must be able to 494 provide the DNSSEC RRs to the client so that it can perform its 495 own validation. 497 The addition of encryption to DNS does not remove the need for DNSSEC 498 [RFC4033] - they are independent and fully compatible protocols, each 499 solving different problems. The use of one does not diminish the 500 need nor the usefulness of the other. 502 While the use of an authenticated and encrypted transport protects 503 origin authentication and data integrity between a client and a DNS 504 privacy service it provides no proof (for a non-validating client) 505 that the data provided by the DNS privacy service was actually DNSSEC 506 authenticated. As with cleartext DNS the user is still solely 507 trusting the AD bit (if present) set by the resolver. 509 It should also be noted that the use of an encrypted transport for 510 DNS actually solves many of the practical issues encountered by DNS 511 validating clients e.g. interference by middleboxes with cleartext 512 DNS payloads is completely avoided. In this sense a validating 513 client that uses a DNS privacy service which supports DNSSEC has a 514 far simpler task in terms of DNS Roadblock avoidance. 516 5.1.5. Availability 518 DNS Privacy Threats: 520 o A failed DNS privacy service could force the user to switch 521 providers, fallback to cleartext or accept no DNS service for the 522 outage. 524 Mitigations: 526 A DNS privacy service must be engineered for high availability. 527 Particular care should to be taken to protect DNS privacy services 528 against denial-of-service attacks, as experience has shown that 529 unavailability of DNS resolving because of attacks is a significant 530 motivation for users to switch services. See, for example 531 Section IV-C of Passive Observations of a Large DNS Service: 2.5 532 Years in the Life of Google [3]. 534 Techniques such as those described in Section 10 of [RFC7766] can be 535 of use to operators to defend against such attacks. 537 5.1.6. Service options 539 DNS Privacy Threats: 541 o Unfairly disadvantaging users of the privacy service with respect 542 to the services available. This could force the user to switch 543 providers, fallback to cleartext or accept no DNS service for the 544 outage. 546 Mitigations: 548 A DNS privacy service should deliver the same level of service as 549 offered on un-encrypted channels in terms of such options as 550 filtering (or lack thereof), DNSSEC validation, etc. 552 5.1.7. Impact on Operators 554 DNS Privacy Threats: 556 o Increased use of encryption impacts operator ability to manage 557 their network [RFC8404] 559 Many monitoring solutions for DNS traffic rely on the plain text 560 nature of this traffic and work by intercepting traffic on the wire, 561 either using a separate view on the connection between clients and 562 the resolver, or as a separate process on the resolver system that 563 inspects network traffic. Such solutions will no longer function 564 when traffic between clients and resolvers is encrypted. There are, 565 however, legitimate reasons for operators to inspect DNS traffic, 566 e.g. to monitor for network security threats. Operators may 567 therefore need to invest in alternative means of monitoring that 568 relies on either the resolver software directly, or exporting DNS 569 traffic from the resolver using e.g. dnstap [4]. 571 Optimization: 573 When implementing alternative means for traffic monitoring, operators 574 of a DNS privacy service should consider using privacy conscious 575 means to do so (see, for example, the discussion on the use of Bloom 576 Filters in the #documents appendix in this document). 578 5.1.8. Limitations of using a pure TLS proxy 580 DNS Privacy Threats: 582 o Limited ability to manage or monitor incoming connections using 583 DNS specific techniques 585 o Misconfiguration of the target server could lead to data leakage 586 if the proxy to target server path is not encrypted. 588 Optimization: 590 Some operators may choose to implement DNS-over-TLS using a TLS proxy 591 (e.g. nginx [5], haproxy [6] or stunnel [7]) in front of a DNS 592 nameserver because of proven robustness and capacity when handling 593 large numbers of client connections, load balancing capabilities and 594 good tooling. Currently, however, because such proxies typically 595 have no specific handling of DNS as a protocol over TLS or DTLS using 596 them can restrict traffic management at the proxy layer and at the 597 DNS server. For example, all traffic received by a nameserver behind 598 such a proxy will appear to originate from the proxy and DNS 599 techniques such as ACLs, RRL or DNS64 will be hard or impossible to 600 implement in the nameserver. 602 Operators may choose to use a DNS aware proxy such as dnsdist [8] 603 which offer custom options (similar to that proposed in 604 [I-D.bellis-dnsop-xpf]) to add source information to packets to 605 address this shortcoming. It should be noted that such options 606 potentially significantly increase the leaked information in the 607 event of a misconfiguration. 609 5.2. Data at rest on the server 611 5.2.1. Data handling 613 [RFC6973] Threats: 615 o Surveillance 617 o Stored data compromise 619 o Correlation 620 o Identification 622 o Secondary use 624 o Disclosure 626 Other Threats 628 o Contravention of legal requirements not to process user data? 630 Mitigations: 632 The following are common activities for DNS service operators and in 633 all cases should be minimized or completely avoided if possible for 634 DNS privacy services. If data is retained it should be encrypted and 635 either aggregated, pseudonymized or anonymized whenever possible. In 636 general the principle of data minimization described in [RFC6973] 637 should be applied. 639 o Transient data (e.g. that is used for real time monitoring and 640 threat analysis which might be held only memory) should be 641 retained for the shortest possible period deemed operationally 642 feasible. 644 o The retention period of DNS traffic logs should be only those 645 required to sustain operation of the service and, to the extent 646 that such exists, meet regulatory requirements. 648 o DNS privacy services should not track users except for the 649 particular purpose of detecting and remedying technically 650 malicious (e.g. DoS) or anomalous use of the service. 652 o Data access should be minimized to only those personnel who 653 require access to perform operational duties. 655 Optimizations: 657 o Consider use of full disk encryption for logs and data capture 658 storage. 660 5.2.2. Data minimization of network traffic 662 Data minimization refers to collecting, using, disclosing, and 663 storing the minimal data necessary to perform a task, and this can be 664 achieved by removing or obfuscating privacy-sensitive information in 665 network traffic logs. This is typically personal data, or data that 666 can be used to link a record to an individual, but may also include 667 revealing other confidential information, for example on the 668 structure of an internal corporate network. 670 The problem of effectively ensuring that DNS traffic logs contain no 671 or minimal privacy-sensitive information is not one that currently 672 has a generally agreed solution or any Standards to inform this 673 discussion. This section presents and overview of current techniques 674 to simply provide reference on the current status of this work. 676 Research into data minimization techniques (and particularly IP 677 address pseudonymization/anonymization) was sparked in the late 678 1990s/early 2000s, partly driven by the desire to share significant 679 corpuses of traffic captures for research purposes. Several 680 techniques reflecting different requirements in this area and 681 different performance/resource tradeoffs emerged over the course of 682 the decade. Developments over the last decade have been both a 683 blessing and a curse; the large increase in size between an IPv4 and 684 an IPv6 address, for example, renders some techniques impractical, 685 but also makes available a much larger amount of input entropy, the 686 better to resist brute force re-identification attacks that have 687 grown in practicality over the period. 689 Techniques employed may be broadly categorized as either 690 anonymization or pseudonymization. The following discussion uses the 691 definitions from [RFC6973] Section 3, with additional observations 692 from van Dijkhuizen et al. [9] 694 o Anonymization. To enable anonymity of an individual, there must 695 exist a set of individuals that appear to have the same 696 attribute(s) as the individual. To the attacker or the observer, 697 these individuals must appear indistinguishable from each other. 699 o Pseudonymization. The true identity is deterministically replaced 700 with an alternate identity (a pseudonym). When the 701 pseudonymization schema is known, the process can be reversed, so 702 the original identity becomes known again. 704 In practice there is a fine line between the two; for example, how to 705 categorize a deterministic algorithm for data minimization of IP 706 addresses that produces a group of pseudonyms for a single given 707 address. 709 5.2.3. IP address pseudonymization and anonymization methods 711 As [I-D.bortzmeyer-dprive-rfc7626-bis] makes clear, the big privacy 712 risk in DNS is connecting DNS queries to an individual and the major 713 vector for this in DNS traffic is the client IP address. 715 There is active discussion in the space of effective pseudonymization 716 of IP addresses in DNS traffic logs, however there seems to be no 717 single solution that is widely recognized as suitable for all or most 718 use cases. There are also as yet no standards for this that are 719 unencumbered by patents. The following table presents a high level 720 comparison of various techniques employed or under development today 721 and classifies them according to categorization of technique and 722 other properties. The list of techniques includes the main 723 techniques in current use, but does not claim to be comprehensive. 724 Appendix B provides a more detailed survey of these techniques and 725 definitions for the categories and properties listed below. 727 Figure showing comparison of IP address techniques (SVG) [10] 729 The choice of which method to use for a particular application will 730 depend on the requirements of that application and consideration of 731 the threat analysis of the particular situation. 733 For example, a common goal is that distributed packet captures must 734 be in an existing data format such as PCAP [pcap] or C-DNS 735 [I-D.ietf-dnsop-dns-capture-format] that can be used as input to 736 existing analysis tools. In that case, use of a format-preserving 737 technique is essential. This, though, is not cost-free - several 738 authors (e.g. Brenker & Arnes [11]) have observed that, as the 739 entropy in an IPv4 address is limited, given a de-identified log from 740 a target, if an attacker is capable of ensuring packets are captured 741 by the target and the attacker can send forged traffic with arbitrary 742 source and destination addresses to that target, any format- 743 preserving pseudonymization is vulnerable to an attack along the 744 lines of a cryptographic chosen plaintext attack. 746 5.2.4. Pseudonymization, anonymization or discarding of other 747 correlation data 749 DNS Privacy Threats: 751 o IP TTL/Hoplimit can be used to fingerprint client OS 753 o TLS version/Cipher suite combinations can be used to fingerprint 754 the client application or TLS library 756 o Tracking of TCP sessions 758 o Tracking of TLS sessions and session resumption mechanisms 760 o Resolvers _might_ receive client identifiers e.g. MAC addresses 761 in EDNS(0) options - some CPE devices are known to add them. 763 o HTTP headers 765 Mitigations: 767 o Data minimization or discarding of such correlation data. 769 5.2.5. Cache snooping 771 [RFC6973] Threats: 773 o Surveillance: 775 * Profiling of client queries by malicious third parties 777 Mitigations: 779 o See ISC Knowledge database on cache snooping [12] for an example 780 discussion on defending against cache snooping 782 5.3. Data sent onwards from the server 784 In this section we consider both data sent on the wire in upstream 785 queries and data shared with third parties. 787 5.3.1. Protocol recommendations 789 [RFC6973] Threats: 791 o Surveillance: 793 * Transmission of identifying data upstream. 795 Mitigations: 797 As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS 798 Privacy services the server should: 800 o Implement QNAME minimization [RFC7816] 802 o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the 803 EDNS(0) Client Subnet (ECS) option and not send an ECS option in 804 upstream queries. 806 Optimizations: 808 o The server should either 810 * not use the ECS option in upstream queries at all, or 811 * offer alternative services, one that sends ECS and one that 812 does not. 814 If operators do offer a service that sends the ECS options upstream 815 they should use the shortest prefix that is operationally feasible 816 (NOTE: the authors believe they will be able to add a reference for 817 advice here soon) and ideally use a policy of whitelisting upstream 818 servers to send ECS to in order to minimize data leakage. Operators 819 should make clear in any policy statement what prefix length they 820 actually send and the specific policy used. 822 Whitelisting has the benefit that not only does the operator know 823 which upstream servers can use ECS but also allows the operator to 824 decide which upstream servers apply privacy policies that the 825 operator is happy with. However some operators consider whitelisting 826 to incur significant operational overhead compared to dynamic 827 detection of ECS on authoritative servers. 829 Additional options: 831 o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the 832 number of queries to authoritative servers to increase privacy. 834 o Run a copy of the root zone on loopback [RFC7706] to avoid making 835 queries to the root servers that might leak information. 837 5.3.2. Client query obfuscation 839 Additional options: 841 Since queries from recursive resolvers to authoritative servers are 842 performed using cleartext (at the time of writing), resolver services 843 need to consider the extent to which they may be directly leaking 844 information about their client community via these upstream queries 845 and what they can do to mitigate this further. Note, that even when 846 all the relevant techniques described above are employed there may 847 still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For 848 example, a resolver with a very small community of users risks 849 exposing data in this way and OUGHT obfuscate this traffic by mixing 850 it with 'generated' traffic to make client characterization harder. 851 The resolver could also employ aggressive pre-fetch techniques as a 852 further measure to counter traffic analysis. 854 At the time of writing there are no standardized or widely recognized 855 techniques to perform such obfuscation or bulk pre-fetches. 857 Another technique that particularly small operators may consider is 858 forwarding local traffic to a larger resolver (with a privacy policy 859 that aligns with their own practices) over an encrypted protocol so 860 that the upstream queries are obfuscated among those of the large 861 resolver. 863 5.3.3. Data sharing 865 [RFC6973] Threats: 867 o Surveillance 869 o Stored data compromise 871 o Correlation 873 o Identification 875 o Secondary use 877 o Disclosure 879 DNS Privacy Threats: 881 o Contravention of legal requirements not to process user data 883 Mitigations: 885 Operators should not provide identifiable data to third-parties 886 without explicit consent from clients (we take the stance here that 887 simply using the resolution service itself does not constitute 888 consent). 890 Even when consent is granted operators should employ data 891 minimization techniques such as those described in Section 5.2.1 if 892 data is shared with third-parties. 894 Operators should consider including specific guidelines for the 895 collection of aggregated and/or anonymized data for research 896 purposes, within or outside of their own organization. This can 897 benefit not only the operator (through inclusion in novel research) 898 but also the wider Internet community. See SURFnet's policy [13] on 899 data sharing for research as an example. 901 6. DNS privacy policy and practice statement 902 6.1. Recommended contents of a DPPPS 904 6.1.1. Policy 906 1. Make an explicit statement that IP addressses are treated as PII 908 2. State if IP addresses are being logged 910 3. Specify clearly what data (including whether it is aggregated, 911 pseudonymized or anonymized and the conditions of data transfer) 912 is: 914 * Collected and retained by the operator, and for what period it 915 is retained 917 * Shared with partners 919 * Shared, sold or rented to third-parties 921 4. Specify any exceptions to the above, for example technically 922 malicious or anomalous behavior 924 5. Declare any partners, third-party affiliations or sources of 925 funding 927 6. Whether user DNS data is correlated or combined with any other 928 personal information held by the operator 930 7. Result filtering. This section should explain whether the 931 operator filters, edits or alters in any way the replies that it 932 receives from the authoritative servers for each DNS zone, before 933 forwarding them to the clients. For each category listed below, 934 the operator should also specify how the filtering lists are 935 created and managed, whether it employs any third-party sources 936 for such lists, and which ones. 938 * Specify if any replies are being filtered out or altered for 939 network and computer security reasons (e.g. preventing 940 connections to malware-spreading websites or botnet control 941 servers) 943 * Specify if any replies are being filtered out or altered for 944 mandatory legal reasons, due to applicable legislation or 945 binding orders by courts and other public authorities 947 * Specify if any replies are being filtered out or altered for 948 voluntary legal reasons, due to an internal policy by the 949 operator aiming at reducing potential legal risks 951 * Specify if any replies are being filtered out or altered for 952 any other reason, including commercial ones 954 6.1.2. Practice 956 This section should explain the current operational practices of the 957 service. 959 1. Specify any temporary or permanent deviations from the policy for 960 operational reasons 962 2. With reference to section Section 5 provide specific details of 963 which capabilities are provided on which client facing addresses 964 and ports 966 3. Specify the authentication name to be used (if any) and if TLSA 967 records are published (including options used in the TLSA 968 records) 970 4. Specify the SPKI pinsets to be used (if any) and policy for 971 rolling keys 973 5. Provide contact/support information for the service 975 6. Jurisdiction. This section should communicate the applicable 976 jurisdictions and law enforcement regimes under which the service 977 is being provided. 979 * Specify the entity or entities that will control the data and 980 be responsible for their treatment, and their legal place of 981 business 983 * Specify, either directly or by pointing to the applicable 984 privacy policy, the relevant privacy laws that apply to the 985 treatment of the data, the rights that users enjoy in regard 986 to their own personal information that is treated by the 987 service, and how they can contact the operator to enforce them 989 * Specify the countries in which the servers handling the DNS 990 requests and the data are located (if the operator applies a 991 geolocation policy so that requests from certain countries are 992 only served by certain servers, this should be specified as 993 well) 995 * Specify whether the operator has any agreement in place with 996 law enforcement agencies, or other public and private parties 997 dealing with security and intelligence, to give them access to 998 the servers and/or to the data 1000 7. Describe how consent is obtained from the user of the DNS privacy 1001 service differentiating 1003 * Uninformed users for whom this trust relationship is implicit 1005 * Privacy-conscious users, that make an explicit trust choice 1007 (this may prove relevant in the context of e.g. the GDPR as it 1008 relates to consent) 1010 6.2. Current policy and privacy statements 1012 A tabular comparison of existing policy and privacy statements from 1013 various DNS Privacy service operators based on the proposed DPPPS 1014 structure can be found on dnsprivacy.org [14]. 1016 We note that the existing set of policies vary widely in style, 1017 content and detail and it is not uncommon for the full text for a 1018 given operator to equate to more than 10 pages of moderate font sized 1019 A4 text. It is a non-trivial task today for a user to extract a 1020 meaningful overview of the different services on offer. 1022 It is also noted that Mozilla have published a Security/DoH-resolver 1023 policy [15], which describes the minimum set of policy requirements 1024 that a party must satisfy to be considered as a potential partner for 1025 Mozilla's Trusted Recursive Resolver (TRR) program. 1027 6.3. Enforcement/accountability 1029 Transparency reports may help with building user trust that operators 1030 adhere to their policies and practices. 1032 Independent monitoring or analysis could be performed where possible 1033 of: 1035 o ECS, QNAME minimization, EDNS(0) padding, etc. 1037 o Filtering 1039 o Uptime 1041 This is by analogy with e.g. several TLS or website analysis tools 1042 that are currently available e.g. SSL Labs [16] or Internet.nl [17]. 1044 Additionally operators could choose to engage the services of a third 1045 party auditor to verify their compliance with their published DPPPS. 1047 7. IANA considerations 1049 None 1051 8. Security considerations 1053 Security considerations for DNS-over-TCP are given in [RFC7766], many 1054 of which are generally applicable to session based DNS. 1056 TODO: e.g. New issues for DoS defence, server admin policies 1058 9. Acknowledgements 1060 Many thanks to Amelia Andersdotter for a very thorough review of the 1061 first draft of this document. Thanks to John Todd for discussions on 1062 this topic, and to Stephane Bortzmeyer, Puneet Sood and Vittorio 1063 Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul 1064 Hoffman, Dan York, John Reed, Lorenzo Colitti for comments at the 1065 mic. Thanks to Loganaden Velvindron for useful updates to the text. 1067 Sara Dickinson thanks the Open Technology Fund for a grant to support 1068 the work on this document. 1070 10. Contributors 1072 The below individuals contributed significantly to the document: 1074 John Dickinson 1075 Sinodun Internet Technologies 1076 Magdalen Centre 1077 Oxford Science Park 1078 Oxford OX4 4GA 1079 United Kingdom 1081 Jim Hague 1082 Sinodun Internet Technologies 1083 Magdalen Centre 1084 Oxford Science Park 1085 Oxford OX4 4GA 1086 United Kingdom 1088 11. Changelog 1090 draft-ietf-dprive-bcp-op-03 1092 o Add paragraph about operational impact 1093 o Move DNSSEC requirement out of the Appendix into main text as a 1094 privacy threat that should be mitigated 1096 o Add TLS version/Cipher suite as tracking threat 1098 o Add reference to Mozilla TRR policy 1100 o Remove several TODOs and QUESTIONS. 1102 draft-ietf-dprive-bcp-op-02 1104 o Change 'open resolver' for 'public resolver' 1106 o Minor editorial changes 1108 o Remove recommendation to run a separate TLS 1.3 service 1110 o Move TLSA to purely a optimisation in Section 5.2.1 1112 o Update reference on minimal DoH headers. 1114 o Add reference on user switching provider after service issues in 1115 Section 5.1.4 1117 o Add text in Section 5.1.6 on impact on operators. 1119 o Add text on additional threat to TLS proxy use (Section 5.1.7) 1121 o Add reference in Section 5.3.1 on example policies. 1123 draft-ietf-dprive-bcp-op-01 1125 o Many minor editorial fixes 1127 o Update DoH reference to RFC8484 and add more text on DoH 1129 o Split threat descriptions into ones directly referencing RFC6973 1130 and other DNS Privacy threats 1132 o Improve threat descriptions throughout 1134 o Remove reference to the DNSSEC TLS Chain Extension draft until new 1135 version submitted. 1137 o Clarify use of whitelisting for ECS 1139 o Re-structure the DPPPS, add Result filtering section. 1141 o Remove the direct inclusion of privacy policy comparison, now just 1142 reference dnsprivacy.org and an example of such work. 1144 o Add an appendix briefly discussing DNSSEC 1146 o Update affiliation of 1 author 1148 draft-ietf-dprive-bcp-op-00 1150 o Initial commit of re-named document after adoption to replace 1151 draft-dickinson-dprive-bcp-op-01 1153 12. References 1155 12.1. Normative References 1157 [I-D.ietf-dnsop-session-signal] 1158 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1159 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1160 draft-ietf-dnsop-session-signal-20 (work in progress), 1161 December 2018. 1163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1164 Requirement Levels", BCP 14, RFC 2119, 1165 DOI 10.17487/RFC2119, March 1997, . 1168 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1169 "Transport Layer Security (TLS) Session Resumption without 1170 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1171 January 2008, . 1173 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1174 DOI 10.17487/RFC6265, April 2011, . 1177 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1178 Morris, J., Hansen, M., and R. Smith, "Privacy 1179 Considerations for Internet Protocols", RFC 6973, 1180 DOI 10.17487/RFC6973, July 2013, . 1183 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1184 "Recommendations for Secure Use of Transport Layer 1185 Security (TLS) and Datagram Transport Layer Security 1186 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1187 2015, . 1189 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1190 D. Wessels, "DNS Transport over TCP - Implementation 1191 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1192 . 1194 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1195 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1196 . 1198 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1199 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1200 DOI 10.17487/RFC7828, April 2016, . 1203 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1204 DOI 10.17487/RFC7830, May 2016, . 1207 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1208 and P. Hoffman, "Specification for DNS over Transport 1209 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1210 2016, . 1212 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1213 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1214 DOI 10.17487/RFC7871, May 2016, . 1217 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1218 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1219 . 1221 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1222 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1223 May 2017, . 1225 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1226 for DNS over TLS and DNS over DTLS", RFC 8310, 1227 DOI 10.17487/RFC8310, March 2018, . 1230 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 1231 Pervasive Encryption on Operators", RFC 8404, 1232 DOI 10.17487/RFC8404, July 2018, . 1235 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1236 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1237 October 2018, . 1239 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1240 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1241 . 1243 12.2. Informative References 1245 [I-D.bellis-dnsop-xpf] 1246 Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", 1247 draft-bellis-dnsop-xpf-04 (work in progress), March 2018. 1249 [I-D.bortzmeyer-dprive-rfc7626-bis] 1250 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 1251 Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02 1252 (work in progress), January 2019. 1254 [I-D.ietf-dnsop-dns-capture-format] 1255 Dickinson, J., Hague, J., Dickinson, S., Manderson, T., 1256 and J. Bond, "C-DNS: A DNS Packet Capture Format", draft- 1257 ietf-dnsop-dns-capture-format-10 (work in progress), 1258 December 2018. 1260 [I-D.ietf-dnsop-dns-tcp-requirements] 1261 Kristoff, J. and D. Wessels, "DNS Transport over TCP - 1262 Operational Requirements", draft-ietf-dnsop-dns-tcp- 1263 requirements-04 (work in progress), June 2019. 1265 [I-D.ietf-dnsop-terminology-bis] 1266 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1267 Terminology", draft-ietf-dnsop-terminology-bis-14 (work in 1268 progress), September 2018. 1270 [I-D.ietf-httpbis-bcp56bis] 1271 Nottingham, M., "Building Protocols with HTTP", draft- 1272 ietf-httpbis-bcp56bis-08 (work in progress), November 1273 2018. 1275 [pcap] tcpdump.org, "PCAP", 2016, . 1277 [Pitfalls-of-DNS-Encryption] 1278 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS 1279 Encryption", 2014, . 1282 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1283 Rose, "DNS Security Introduction and Requirements", 1284 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1285 . 1287 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1288 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1289 . 1291 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 1292 Framework for DNSSEC Policies and DNSSEC Practice 1293 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 1294 . 1296 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1297 Known Attacks on Transport Layer Security (TLS) and 1298 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1299 February 2015, . 1301 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 1302 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 1303 2015, . 1305 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 1306 Servers by Running One on Loopback", RFC 7706, 1307 DOI 10.17487/RFC7706, November 2015, . 1310 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1311 Transport Layer Security (DTLS)", RFC 8094, 1312 DOI 10.17487/RFC8094, February 2017, . 1315 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 1316 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 1317 July 2017, . 1319 12.3. URIs 1321 [1] https://www.ietf.org/mail-archive/web/dns-privacy/current/ 1322 pdfWqAIUmEl47.pdf 1324 [2] https://petsymposium.org/2018/files/hotpets/4-siby.pdf 1326 [3] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/ 1327 tma2018_paper30.pdf 1329 [4] http://dnstap.info 1331 [5] https://nginx.org/ 1333 [6] https://www.haproxy.org/ 1335 [7] https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html 1337 [8] https://dnsdist.org 1339 [9] https://doi.org/10.1145/3182660 1341 [10] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/ 1342 draft-00/ip_techniques_table.svg 1344 [11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16 1345 4fb2138a44.pdf 1347 [12] https://kb.isc.org/docs/aa-00482 1349 [13] https://surf.nl/datasharing 1351 [14] https://dnsprivacy.org/wiki/display/DP/ 1352 Comparison+of+policy+and+privacy+statements 1354 [15] https://wiki.mozilla.org/Security/DOH-resolver-policy 1356 [16] https://www.ssllabs.com/ssltest/ 1358 [17] https://internet.nl 1360 [18] https://support.google.com/analytics/answer/2763052?hl=en 1362 [19] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip- 1363 geo-impact-test/ 1365 [20] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc 1367 [21] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html 1369 [22] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn- 1370 anon.pdf 1372 [23] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ 1374 [24] http://mharvan.net/talks/noms-ip_anon.pdf 1376 [25] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf 1378 [26] https://medium.com/@bert.hubert/on-ip-address-encryption- 1379 security-analysis-with-respect-for-privacy-dabe1201b476 1381 [27] https://github.com/PowerDNS/ipcipher 1383 [28] https://github.com/veorq/ipcrypt 1385 [29] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html 1387 [30] http://dl.ifip.org/db/conf/im/im2019/189282.pdf 1389 Appendix A. Documents 1391 This section provides an overview of some DNS privacy related 1392 documents, however, this is neither an exhaustive list nor a 1393 definitive statement on the characteristic of the document. 1395 A.1. Potential increases in DNS privacy 1397 These documents are limited in scope to communications between stub 1398 clients and recursive resolvers: 1400 o 'Specification for DNS over Transport Layer Security (TLS)' 1401 [RFC7858], referred to here as 'DNS-over-TLS'. 1403 o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094], 1404 referred to here as 'DNS-over-DTLS'. Note that this document has 1405 the Category of Experimental. 1407 o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH. 1409 o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310] 1411 o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for 1412 EDNS(0)' [RFC8467] 1414 These documents apply to recursive to authoritative DNS but are 1415 relevant when considering the operation of a recursive server: 1417 o 'DNS Query Name minimization to Improve Privacy' [RFC7816] 1418 referred to here as 'QNAME minimization' 1420 A.2. Potential decreases in DNS privacy 1422 These documents relate to functionality that could provide increased 1423 tracking of user activity as a side effect: 1425 o 'Client Subnet in DNS Queries' [RFC7871] 1426 o 'Domain Name System (DNS) Cookies' [RFC7873]) 1428 o 'Transport Layer Security (TLS) Session Resumption without Server- 1429 Side State' [RFC5077] referred to here as simply TLS session 1430 resumption. 1432 o 'A DNS Packet Capture Format' [I-D.ietf-dnsop-dns-capture-format] 1434 o Passive DNS [I-D.ietf-dnsop-terminology-bis] 1436 Note that depending on the specifics of the implementation [RFC8484] 1437 may also provide increased tracking. 1439 A.3. Related operational documents 1441 o 'DNS Transport over TCP - Implementation Requirements' [RFC7766] 1443 o 'Operational requirements for DNS-over-TCP' 1444 [I-D.ietf-dnsop-dns-tcp-requirements] 1446 o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828] 1448 o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal] 1450 Appendix B. IP address techniques 1452 Data minimization methods may be categorized by the processing used 1453 and the properties of their outputs. The following builds on the 1454 categorization employed in [RFC6235]: 1456 o Format-preserving. Normally when encrypting, the original data 1457 length and patterns in the data should be hidden from an attacker. 1458 Some applications of de-identification, such as network capture 1459 de-identification, require that the de-identified data is of the 1460 same form as the original data, to allow the data to be parsed in 1461 the same way as the original. 1463 o Prefix preservation. Values such as IP addresses and MAC 1464 addresses contain prefix information that can be valuable in 1465 analysis, e.g. manufacturer ID in MAC addresses, subnet in IP 1466 addresses. Prefix preservation ensures that prefixes are de- 1467 identified consistently; e.g. if two IP addresses are from the 1468 same subnet, a prefix preserving de-identification will ensure 1469 that their de-identified counterparts will also share a subnet. 1470 Prefix preservation may be fixed (i.e. based on a user selected 1471 prefix length identified in advance to be preserved ) or general. 1473 o Replacement. A one-to-one replacement of a field to a new value 1474 of the same type, for example using a regular expression. 1476 o Filtering. Removing (and thus truncating) or replacing data in a 1477 field. Field data can be overwritten, often with zeros, either 1478 partially (grey marking) or completely (black marking). 1480 o Generalization. Data is replaced by more general data with 1481 reduced specificity. One example would be to replace all TCP/UDP 1482 port numbers with one of two fixed values indicating whether the 1483 original port was ephemeral (>=1024) or non-ephemeral (>1024). 1484 Another example, precision degradation, reduces the accuracy of 1485 e.g. a numeric value or a timestamp. 1487 o Enumeration. With data from a well-ordered set, replace the first 1488 data item data using a random initial value and then allocate 1489 ordered values for subsequent data items. When used with 1490 timestamp data, this preserves ordering but loses precision and 1491 distance. 1493 o Reordering/shuffling. Preserving the original data, but 1494 rearranging its order, often in a random manner. 1496 o Random substitution. As replacement, but using randomly generated 1497 replacement values. 1499 o Cryptographic permutation. Using a permutation function, such as 1500 a hash function or cryptographic block cipher, to generate a 1501 replacement de-identified value. 1503 B.1. Google Analytics non-prefix filtering 1505 Since May 2010, Google Analytics has provided a facility [18] that 1506 allows website owners to request that all their users IP addresses 1507 are anonymized within Google Analytics processing. This very basic 1508 anonymization simply sets to zero the least significant 8 bits of 1509 IPv4 addresses, and the least significant 80 bits of IPv6 addresses. 1510 The level of anonymization this produces is perhaps questionable. 1511 There are some analysis results [19] which suggest that the impact of 1512 this on reducing the accuracy of determining the user's location from 1513 their IP address is less than might be hoped; the average discrepancy 1514 in identification of the user city for UK users is no more than 17%. 1516 Anonymization: Format-preserving, Filtering (grey marking). 1518 B.2. dnswasher 1520 Since 2006, PowerDNS have included a de-identification tool dnswasher 1521 [20] with their PowerDNS product. This is a PCAP filter that 1522 performs a one-to-one mapping of end user IP addresses with an 1523 anonymized address. A table of user IP addresses and their de- 1524 identified counterparts is kept; the first IPv4 user addresses is 1525 translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de- 1526 identified address therefore depends on the order that addresses 1527 arrive in the input, and running over a large amount of data the 1528 address translation tables can grow to a significant size. 1530 Anonymization: Format-preserving, Enumeration. 1532 B.3. Prefix-preserving map 1534 Used in TCPdpriv [21], this algorithm stores a set of original and 1535 anonymised IP address pairs. When a new IP address arrives, it is 1536 compared with previous addresses to determine the longest prefix 1537 match. The new address is anonymized by using the same prefix, with 1538 the remainder of the address anonymized with a random value. The use 1539 of a random value means that TCPdrpiv is not deterministic; different 1540 anonymized values will be generated on each run. The need to store 1541 previous addresses means that TCPdpriv has significant and unbounded 1542 memory requirements, and because of the need to allocated anonymized 1543 addresses sequentially cannot be used in parallel processing. 1545 Anonymization: Format-preserving, prefix preservation (general). 1547 B.4. Cryptographic Prefix-Preserving Pseudonymisation 1549 Cryptographic prefix-preserving pseudonymisation was originally 1550 proposed as an improvement to the prefix-preserving map implemented 1551 in TCPdpriv, described in Xu et al. [22] and implemented in the 1552 Crypto-PAn tool [23]. Crypto-PAn is now frequently used as an 1553 acronym for the algorithm. Initially it was described for IPv4 1554 addresses only; extension for IPv6 addresses was proposed in Harvan & 1555 Schoenwaelder [24] and implemented in snmpdump. This uses a 1556 cryptographic algorithm rather than a random value, and thus 1557 pseudonymity is determined uniquely by the encryption key, and is 1558 deterministic. It requires a separate AES encryption for each output 1559 bit, so has a non-trivial calculation overhead. This can be 1560 mitigated to some extent (for IPv4, at least) by pre-calculating 1561 results for some number of prefix bits. 1563 Pseudonymization: Format-preserving, prefix preservation (general). 1565 B.5. Top-hash Subtree-replicated Anonymisation 1567 Proposed in Ramaswamy & Wolf [25], Top-hash Subtree-replicated 1568 Anonymisation (TSA) originated in response to the requirement for 1569 faster processing than Crypto-PAn. It used hashing for the most 1570 significant byte of an IPv4 address, and a pre-calculated binary tree 1571 structure for the remainder of the address. To save memory space, 1572 replication is used within the tree structure, reducing the size of 1573 the pre-calculated structures to a few Mb for IPv4 addresses. 1574 Address pseudonymization is done via hash and table lookup, and so 1575 requires minimal computation. However, due to the much increased 1576 address space for IPv6, TSA is not memory efficient for IPv6. 1578 Pseudonymization: Format-preserving, prefix preservation (general). 1580 B.6. ipcipher 1582 A recently-released proposal from PowerDNS [26], ipcipher [27] is a 1583 simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6 1584 addresses are encrypted directly with AES-128 using a key (which may 1585 be derived from a passphrase). IPv4 addresses are similarly 1586 encrypted, but using a recently proposed encryption ipcrypt [28] 1587 suitable for 32bit block lengths. However, the author of ipcrypt has 1588 since indicated [29] that it has low security, and further analysis 1589 has revealed it is vulnerable to attack. 1591 Pseudonymization: Format-preserving, cryptographic permutation. 1593 B.7. Bloom filters 1595 van Rijswijk-Deij et al. [30] have recently described work using 1596 Bloom filters to categorize query traffic and record the traffic as 1597 the state of multiple filters. The goal of this work is to allow 1598 operators to identify so-called Indicators of Compromise (IOCs) 1599 originating from specific subnets without storing information about, 1600 or be able to monitor the DNS queries of an individual user. By 1601 using a Bloom filter, it is possible to determine with a high 1602 probability if, for example, a particular query was made, but the set 1603 of queries made cannot be recovered from the filter. Similarly, by 1604 mixing queries from a sufficient number of users in a single filter, 1605 it becomes practically impossible to determine if a particular user 1606 performed a particular query. Large numbers of queries can be 1607 tracked in a memory-efficient way. As filter status is stored, this 1608 approach cannot be used to regenerate traffic, and so cannot be used 1609 with tools used to process live traffic. 1611 Anonymized: Generalization. 1613 Authors' Addresses 1615 Sara Dickinson 1616 Sinodun IT 1617 Magdalen Centre 1618 Oxford Science Park 1619 Oxford OX4 4GA 1620 United Kingdom 1622 Email: sara@sinodun.com 1624 Benno J. Overeinder 1625 NLnet Labs 1626 Science Park 400 1627 Amsterdam 1098 XH 1628 The Netherlands 1630 Email: benno@nlnetLabs.nl 1632 Roland M. van Rijswijk-Deij 1633 NLnet Labs 1634 Science Park 400 1635 Amsterdam 1098 XH 1636 The Netherlands 1638 Email: roland@nlnetLabs.nl 1640 Allison Mankin 1641 Salesforce 1643 Email: allison.mankin@gmail.com