idnits 2.17.1 draft-ietf-dprive-bcp-op-02.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 (March 11, 2019) is 1873 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 1269 -- Looks like a reference, but probably isn't: '2' on line 1272 -- Looks like a reference, but probably isn't: '3' on line 1274 -- Looks like a reference, but probably isn't: '4' on line 1277 -- Looks like a reference, but probably isn't: '5' on line 1279 -- Looks like a reference, but probably isn't: '6' on line 1281 -- Looks like a reference, but probably isn't: '7' on line 1283 -- Looks like a reference, but probably isn't: '8' on line 1285 -- Looks like a reference, but probably isn't: '9' on line 1287 -- Looks like a reference, but probably isn't: '10' on line 1289 -- Looks like a reference, but probably isn't: '11' on line 1292 -- Looks like a reference, but probably isn't: '12' on line 1295 -- Looks like a reference, but probably isn't: '13' on line 1297 -- Looks like a reference, but probably isn't: '14' on line 1299 -- Looks like a reference, but probably isn't: '15' on line 1302 -- Looks like a reference, but probably isn't: '16' on line 1304 -- Looks like a reference, but probably isn't: '17' on line 1469 -- Looks like a reference, but probably isn't: '18' on line 1475 -- Looks like a reference, but probably isn't: '19' on line 1485 -- Looks like a reference, but probably isn't: '20' on line 1498 -- Looks like a reference, but probably isn't: '21' on line 1515 -- Looks like a reference, but probably isn't: '22' on line 1516 -- Looks like a reference, but probably isn't: '23' on line 1519 -- Looks like a reference, but probably isn't: '24' on line 1531 -- Looks like a reference, but probably isn't: '25' on line 1546 -- Looks like a reference, but probably isn't: '26' on line 1546 -- Looks like a reference, but probably isn't: '27' on line 1550 -- Looks like a reference, but probably isn't: '28' on line 1552 -- Looks like a reference, but probably isn't: '29' on line 1559 ** 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-03 == 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 (==), 31 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: September 12, 2019 R. van Rijswijk-Deij 6 NLnet Labs 7 A. Mankin 8 Salesforce 9 March 11, 2019 11 Recommendations for DNS Privacy Service Operators 12 draft-ietf-dprive-bcp-op-02 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 September 12, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . 7 69 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 70 5.1.4. Availability . . . . . . . . . . . . . . . . . . . . 10 71 5.1.5. Service options . . . . . . . . . . . . . . . . . . . 11 72 5.1.6. Impact on Operators . . . . . . . . . . . . . . . . . 11 73 5.1.7. Limitations of using a pure TLS proxy . . . . . . . . 12 74 5.2. Data at rest on the server . . . . . . . . . . . . . . . 12 75 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 12 76 5.2.2. Data minimization of network traffic . . . . . . . . 13 77 5.2.3. IP address pseudonymization and anonymization methods 14 78 5.2.4. Pseudonymization, anonymization or discarding of 79 other correlation data . . . . . . . . . . . . . . . 15 80 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 16 81 5.3. Data sent onwards from the server . . . . . . . . . . . . 16 82 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 16 83 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 17 84 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 18 85 6. DNS privacy policy and practice statement . . . . . . . . . . 19 86 6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 19 87 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 19 88 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 20 89 6.2. Current policy and privacy statements . . . . . . . . . . 21 90 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 21 91 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 92 8. Security considerations . . . . . . . . . . . . . . . . . . . 22 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 94 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 95 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 98 12.2. Informative References . . . . . . . . . . . . . . . . . 26 99 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 29 101 A.1. Potential increases in DNS privacy . . . . . . . . . . . 29 102 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 29 103 A.3. Related operational documents . . . . . . . . . . . . . . 30 104 Appendix B. Encryption and DNSSEC . . . . . . . . . . . . . . . 30 105 Appendix C. IP address techniques . . . . . . . . . . . . . . . 30 106 C.1. Google Analytics non-prefix filtering . . . . . . . . . . 31 107 C.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 32 108 C.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 32 109 C.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 32 110 C.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 33 111 C.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 33 112 C.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 33 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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 Community insight [or judgment?] about operational practices can 182 change quickly, and experience shows that a Best Current Practice 183 (BCP) document about privacy and security is a point-in-time 184 statement. Readers are advised to seek out any errata or updates 185 that apply to this document. 187 2. Scope 189 "DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis] 190 describes the general privacy issues and threats associated with the 191 use of the DNS by Internet users and much of the threat analysis here 192 is lifted from that document and from [RFC6973]. However this 193 document is limited in scope to best practice considerations for the 194 provision of DNS privacy services by servers (recursive resolvers) to 195 clients (stub resolvers or forwarders). Privacy considerations 196 specifically from the perspective of an end user, or those for 197 operators of authoritative nameservers are out of scope. 199 This document includes (but is not limited to) considerations in the 200 following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]): 202 1. Data "on the wire" between a client and a server 204 2. Data "at rest" on a server (e.g. in logs) 206 3. Data "sent onwards" from the server (either on the wire or shared 207 with a third party) 209 Whilst the issues raised here are targeted at those operators who 210 choose to offer a DNS privacy service, considerations for areas 2 and 211 3 could equally apply to operators who only offer DNS over 212 unencrypted transports but who would like to align with privacy best 213 practice. 215 3. Privacy related documents 217 There are various documents that describe protocol changes that have 218 the potential to either increase or decrease the privacy of the DNS. 219 Note this does not imply that some documents are good or bad, better 220 or worse, just that (for example) some features may bring functional 221 benefits at the price of a reduction in privacy and conversely some 222 features increase privacy with an accompanying increase in 223 complexity. A selection of the most relevant documents are listed in 224 Appendix A for reference. 226 4. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in BCP 231 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 DNS terminology is as described in [I-D.ietf-dnsop-terminology-bis] 235 with one modification: we restate the clause in the original 236 definition of Privacy-enabling DNS server in [RFC8310] to include the 237 requirement that a DNS over (D)TLS server should also offer at least 238 one of the credentials described in Section 8 and implement the 239 (D)TLS profile described in Section 9 of [RFC8310]. 241 Other Terms: 243 o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6. 245 o DNS privacy service: The service that is offered via a privacy- 246 enabling DNS server and is documented either in an informal 247 statement of policy and practice with regard to users privacy or a 248 formal DPPPS. 250 5. Recommendations for DNS privacy services 252 We describe two classes of threats: 254 o 'Privacy Considerations for Internet Protocols' [RFC6973] Threats 256 * Privacy terminology, threats to privacy and mitigations as 257 described in Sections 3, 5 and 6 of [RFC6973]. 259 o DNS Privacy Threats 261 * These are threats to the users and operators of DNS privacy 262 services that are not directly covered by [RFC6973]. These may 263 be more operational in nature such as certificate management or 264 service availability issues. 266 We describe three classes of actions that operators of DNS privacy 267 services can take: 269 o Threat mitigation for well understood and documented privacy 270 threats to the users of the service and in some cases to the 271 operators of the service. 273 o Optimization of privacy services from an operational or management 274 perspective 276 o Additional options that could further enhance the privacy and 277 usability of the service 279 This document does not specify policy only best practice, however for 280 DNS Privacy services to be considered compliant with these best 281 practice guidelines they SHOULD implement (where appropriate) all: 283 o Threat mitigations to be minimally compliant 285 o Optimizations to be moderately compliant 287 o Additional options to be maximally compliant 289 5.1. On the wire between client and server 291 In this section we consider both data on the wire and the service 292 provided to the client. 294 5.1.1. Transport recommendations 296 [RFC6973] Threats: 298 o Surveillance: 300 * Passive surveillance of traffic on the wire 301 [I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.4.2. 303 DNS Privacy Threats: 305 o Active injection of spurious data or traffic 307 Mitigations: 309 A DNS privacy service can mitigate these threats by providing service 310 over one or more of the following transports 312 o DNS-over-TLS [RFC7858] and [RFC8310] 314 o DoH [RFC8484] 316 It is noted that a DNS privacy service can also be provided over DNS- 317 over-DTLS [RFC8094], however this is an Experimental specification 318 and there are no known implementations at the time of writing. 320 It is also noted that DNS privacy service might be provided over 321 IPSec, DNSCrypt or VPNs. However, use of these transports for DNS 322 are not standardized and any discussion of best practice for 323 providing such a service is out of scope for this document. 325 Whilst encryption of DNS traffic can protect against active injection 326 this does not diminish the need for DNSSEC, see Appendix B. 328 5.1.2. Authentication of DNS privacy services 330 [RFC6973] Threats: 332 o Surveillance: 334 * Active attacks that can redirect traffic to rogue servers 335 [I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3. 337 Mitigations: 339 DNS privacy services should ensure clients can authenticate the 340 server. Note that this, in effect, commits the DNS privacy service 341 to a public identity users will trust. 343 When using DNS-over-TLS clients that select a 'Strict Privacy' usage 344 profile [RFC8310] (to mitigate the threat of active attack on the 345 client) require the ability to authenticate the DNS server. To 346 enable this, DNS privacy services that offer DNS-over-TLS should 347 provide credentials in the form of either X.509 certificates or SPKI 348 pinsets. 350 When offering DoH [RFC8484], HTTPS requires authentication of the 351 server as part of the protocol. 353 NOTE: At this time the reference to the TLS DNSSEC chain extension 354 draft has been removed as it is no longer considered an active TLS WG 355 document. 357 Optimizations: 359 DNS privacy services can also consider the following capabilities/ 360 options: 362 o As recommended in [RFC8310] providing DANE TLSA records for the 363 nameserver 365 * In particular, the service could provide TLSA records such that 366 authenticating solely via the PKIX infrastructure can be 367 avoided. 369 5.1.2.1. Certificate management 371 Anecdotal evidence to date highlights the management of certificates 372 as one of the more challenging aspects for operators of traditional 373 DNS resolvers that choose to additionally provide a DNS privacy 374 service as management of such credentials is new to those DNS 375 operators. 377 It is noted that SPKI pinset management is described in [RFC7858] but 378 that key pinning mechanisms in general have fallen out of favor 379 operationally for various reasons such as the logistical overhead of 380 rolling keys. 382 DNS Privacy Threats: 384 o Invalid certificates, resulting in an unavailable service. 386 o Mis-identification of a server by a client e.g. typos in URLs or 387 authentication domain names 389 Mitigations: 391 It is recommended that operators: 393 o Follow the guidance in Section 6.5 of [RFC7525] with regards to 394 certificate revocation 396 o Choose a short, memorable authentication name for the service 398 o Automate the generation and publication of certificates 400 o Monitor certificates to prevent accidental expiration of 401 certificates 403 5.1.3. Protocol recommendations 405 5.1.3.1. DNS-over-TLS 407 DNS Privacy Threats: 409 o Known attacks on TLS such as those described in [RFC7457] 411 o Traffic analysis, for example: Pitfalls of DNS Encryption [1] 413 o Potential for client tracking via transport identifiers 415 o Blocking of well known ports (e.g. 853 for DNS-over-TLS) 417 Mitigations: 419 In the case of DNS-over-TLS, TLS profiles from Section 9 and the 420 Countermeasures to DNS Traffic Analysis from section 11.1 of 421 [RFC8310] provide strong mitigations. This includes but is not 422 limited to: 424 o Adhering to [RFC7525] 426 o Implementing only (D)TLS 1.2 or later as specified in [RFC8310] 428 o Implementing EDNS(0) Padding [RFC7830] using the guidelines in 429 [RFC8467] 431 o Clients should not be required to use TLS session resumption 432 [RFC5077] or Domain Name System (DNS) Cookies [RFC7873]. 434 o A DNS-over-TLS privacy service on both port 853 and 443. This 435 practice may not be possible if e.g. the operator deploys DoH on 436 the same IP address. 438 Optimizations: 440 o Concurrent processing of pipelined queries, returning responses as 441 soon as available, potentially out of order as specified in 442 [RFC7766]. This is often called 'OOOR' - out-of-order responses. 443 (Providing processing performance similar to HTTP multiplexing) 445 o Management of TLS connections to optimize performance for clients 446 using either 448 * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or 450 * DNS Stateful Operations [I-D.ietf-dnsop-session-signal] 452 Additional options that providers may consider: 454 o Offer a .onion [RFC7686] service endpoint 456 5.1.3.2. DoH 458 DNS Privacy Threats: 460 o Known attacks on TLS such as those described in [RFC7457] 462 o Traffic analysis, for example: DNS Privacy not so private: the 463 traffic analysis perspective [2] 465 o Potential for client tracking via transport identifiers 467 Mitigations: 469 o Clients must be able to forego the use of HTTP Cookies [RFC6265] 470 and still use the service 472 o Clients should not be required to include any headers beyond the 473 absolute minimum to obtain service from a DoH server. (See 474 Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) 476 5.1.4. Availability 478 DNS Privacy Threats: 480 o A failed DNS privacy service could force the user to switch 481 providers, fallback to cleartext or accept no DNS service for the 482 outage. 484 Mitigations: 486 A DNS privacy service must be engineered for high availability. 487 Particular care should to be taken to protect DNS privacy services 488 against denial-of-service attacks, as experience has shown that 489 unavailability of DNS resolving because of attacks is a significant 490 motivation for users to switch services. See, for example 491 Section IV-C of Passive Observations of a Large DNS Service: 2.5 492 Years in the Life of Google [3]. 494 5.1.5. Service options 496 DNS Privacy Threats: 498 o Unfairly disadvantaging users of the privacy service with respect 499 to the services available. This could force the user to switch 500 providers, fallback to cleartext or accept no DNS service for the 501 outage. 503 Mitigations: 505 A DNS privacy service should deliver the same level of service as 506 offered on un-encrypted channels in terms of such options as 507 filtering (or lack thereof), DNSSEC validation, etc. 509 5.1.6. Impact on Operators 511 DNS Privacy Threats: 513 o Increased use of encryption impacts operator ability to manage 514 their network [RFC8404] 516 Many monitoring solutions for DNS traffic rely on the plain text 517 nature of this traffic and work by intercepting traffic on the wire, 518 either using a separate view on the connection between clients and 519 the resolver, or as a separate process on the resolver system that 520 inspects network traffic. Such solutions will no longer function 521 when traffic between clients and resolvers is encrypted. There are, 522 however, legitimate reasons for operators to inspect DNS traffic, 523 e.g. to monitor for network security threats. Operators may 524 therefore need to invest in alternative means of monitoring that 525 relies on either the resolver software directly, or exporting DNS 526 traffic from the resolver using e.g. dnstap [4]. 528 Optimization: 530 When implementing alternative means for traffic monitoring, operators 531 of a DNS privacy service should consider using privacy conscious 532 means to do so (see, for example, the discussion on the use of Bloom 533 Filters in the #documents appendix in this document). 535 5.1.7. Limitations of using a pure TLS proxy 537 DNS Privacy Threats: 539 o Limited ability to manage or monitor incoming connections using 540 DNS specific techniques 542 o Misconfiguration of the target server could lead to data leakage 543 if the proxy to target server path is not encrypted. 545 Optimization: 547 Some operators may choose to implement DNS-over-TLS using a TLS proxy 548 (e.g. nginx [5], haproxy [6] or stunnel [7]) in front of a DNS 549 nameserver because of proven robustness and capacity when handling 550 large numbers of client connections, load balancing capabilities and 551 good tooling. Currently, however, because such proxies typically 552 have no specific handling of DNS as a protocol over TLS or DTLS using 553 them can restrict traffic management at the proxy layer and at the 554 DNS server. For example, all traffic received by a nameserver behind 555 such a proxy will appear to originate from the proxy and DNS 556 techniques such as ACLs, RRL or DNS64 will be hard or impossible to 557 implement in the nameserver. 559 Operators may choose to use a DNS aware proxy such as dnsdist [8] 560 which offer custom options (similar to that proposed in 561 [I-D.bellis-dnsop-xpf]) to add source information to packets to 562 address this shortcoming. It should be noted that such options 563 potentially significantly increase the leaked information in the 564 event of a misconfiguration. 566 5.2. Data at rest on the server 568 5.2.1. Data handling 570 [RFC6973] Threats: 572 o Surveillance 574 o Stored data compromise 575 o Correlation 577 o Identification 579 o Secondary use 581 o Disclosure 583 Other Threats 585 o Contravention of legal requirements not to process user data? 587 Mitigations: 589 The following are common activities for DNS service operators and in 590 all cases should be minimized or completely avoided if possible for 591 DNS privacy services. If data is retained it should be encrypted and 592 either aggregated, pseudonymized or anonymized whenever possible. In 593 general the principle of data minimization described in [RFC6973] 594 should be applied. 596 o Transient data (e.g. that is used for real time monitoring and 597 threat analysis which might be held only memory) should be 598 retained for the shortest possible period deemed operationally 599 feasible. 601 o The retention period of DNS traffic logs should be only those 602 required to sustain operation of the service and, to the extent 603 that such exists, meet regulatory requirements. 605 o DNS privacy services should not track users except for the 606 particular purpose of detecting and remedying technically 607 malicious (e.g. DoS) or anomalous use of the service. 609 o Data access should be minimized to only those personnel who 610 require access to perform operational duties. 612 Optimizations: 614 o Consider use of full disk encryption for logs and data capture 615 storage. 617 5.2.2. Data minimization of network traffic 619 Data minimization refers to collecting, using, disclosing, and 620 storing the minimal data necessary to perform a task, and this can be 621 achieved by removing or obfuscating privacy-sensitive information in 622 network traffic logs. This is typically personal data, or data that 623 can be used to link a record to an individual, but may also include 624 revealing other confidential information, for example on the 625 structure of an internal corporate network. 627 The problem of effectively ensuring that DNS traffic logs contain no 628 or minimal privacy-sensitive information is not one that currently 629 has a generally agreed solution or any Standards to inform this 630 discussion. This section presents and overview of current techniques 631 to simply provide reference on the current status of this work. 633 Research into data minimization techniques (and particularly IP 634 address pseudonymization/anonymization) was sparked in the late 635 1990s/early 2000s, partly driven by the desire to share significant 636 corpuses of traffic captures for research purposes. Several 637 techniques reflecting different requirements in this area and 638 different performance/resource tradeoffs emerged over the course of 639 the decade. Developments over the last decade have been both a 640 blessing and a curse; the large increase in size between an IPv4 and 641 an IPv6 address, for example, renders some techniques impractical, 642 but also makes available a much larger amount of input entropy, the 643 better to resist brute force re-identification attacks that have 644 grown in practicality over the period. 646 Techniques employed may be broadly categorized as either 647 anonymization or pseudonymization. The following discussion uses the 648 definitions from [RFC6973] Section 3, with additional observations 649 from van Dijkhuizen et al. [9] 651 o Anonymization. To enable anonymity of an individual, there must 652 exist a set of individuals that appear to have the same 653 attribute(s) as the individual. To the attacker or the observer, 654 these individuals must appear indistinguishable from each other. 656 o Pseudonymization. The true identity is deterministically replaced 657 with an alternate identity (a pseudonym). When the 658 pseudonymization schema is known, the process can be reversed, so 659 the original identity becomes known again. 661 In practice there is a fine line between the two; for example, how to 662 categorize a deterministic algorithm for data minimization of IP 663 addresses that produces a group of pseudonyms for a single given 664 address. 666 5.2.3. IP address pseudonymization and anonymization methods 668 As [I-D.bortzmeyer-dprive-rfc7626-bis] makes clear, the big privacy 669 risk in DNS is connecting DNS queries to an individual and the major 670 vector for this in DNS traffic is the client IP address. 672 There is active discussion in the space of effective pseudonymization 673 of IP addresses in DNS traffic logs, however there seems to be no 674 single solution that is widely recognized as suitable for all or most 675 use cases. There are also as yet no standards for this that are 676 unencumbered by patents. The following table presents a high level 677 comparison of various techniques employed or under development today 678 and classifies them according to categorization of technique and 679 other properties. The list of techniques includes the main 680 techniques in current use, but does not claim to be comprehensive. 681 Appendix C provides a more detailed survey of these techniques and 682 definitions for the categories and properties listed below. 684 Figure showing comparison of IP address techniques (SVG) [10] 686 The choice of which method to use for a particular application will 687 depend on the requirements of that application and consideration of 688 the threat analysis of the particular situation. 690 For example, a common goal is that distributed packet captures must 691 be in an existing data format such as PCAP [pcap] or C-DNS 692 [I-D.ietf-dnsop-dns-capture-format] that can be used as input to 693 existing analysis tools. In that case, use of a format-preserving 694 technique is essential. This, though, is not cost-free - several 695 authors (e.g. Brenker & Arnes [11]) have observed that, as the 696 entropy in an IPv4 address is limited, given a de-identified log from 697 a target, if an attacker is capable of ensuring packets are captured 698 by the target and the attacker can send forged traffic with arbitrary 699 source and destination addresses to that target, any format- 700 preserving pseudonymization is vulnerable to an attack along the 701 lines of a cryptographic chosen plaintext attack. 703 5.2.4. Pseudonymization, anonymization or discarding of other 704 correlation data 706 DNS Privacy Threats: 708 o IP TTL/Hoplimit can be used to fingerprint client OS 710 o Tracking of TCP sessions 712 o Tracking of TLS sessions and session resumption mechanisms 714 o Resolvers _might_ receive client identifiers e.g. MAC addresses 715 in EDNS(0) options - some CPE devices are known to add them. 717 o HTTP headers 719 Mitigations: 721 o Data minimization or discarding of such correlation data 723 TODO: More analysis here. 725 5.2.5. Cache snooping 727 [RFC6973] Threats: 729 o Surveillance: 731 * Profiling of client queries by malicious third parties 733 Mitigations: 735 o See ISC Knowledge database on cache snooping [12] for an example 736 discussion on defending against cache snooping 738 TODO: Describe other techniques to defend against cache snooping 740 5.3. Data sent onwards from the server 742 In this section we consider both data sent on the wire in upstream 743 queries and data shared with third parties. 745 5.3.1. Protocol recommendations 747 [RFC6973] Threats: 749 o Surveillance: 751 * Transmission of identifying data upstream. 753 Mitigations: 755 As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS 756 Privacy services the server should: 758 o Implement QNAME minimization [RFC7816] 760 o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the 761 EDNS(0) Client Subnet (ECS) option and not send an ECS option in 762 upstream queries. 764 Optimizations: 766 o The server should either 768 * not use the ECS option in upstream queries at all, or 769 * offer alternative services, one that sends ECS and one that 770 does not. 772 If operators do offer a service that sends the ECS options upstream 773 they should use the shortest prefix that is operationally feasible 774 (NOTE: the authors believe they will be able to add a reference for 775 advice here soon) and ideally use a policy of whitelisting upstream 776 servers to send ECS to in order to minimize data leakage. Operators 777 should make clear in any policy statement what prefix length they 778 actually send and the specific policy used. 780 Whitelisting has the benefit that not only does the operator know 781 which upstream servers can use ECS but also allows the operator to 782 decide which upstream servers apply privacy policies that the 783 operator is happy with. However some operators consider whitelisting 784 to incur significant operational overhead compared to dynamic 785 detection of ECS on authoritative servers. 787 Additional options: 789 o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the 790 number of queries to authoritative servers to increase privacy. 792 o Run a copy of the root zone on loopback [RFC7706] to avoid making 793 queries to the root servers that might leak information. 795 5.3.2. Client query obfuscation 797 Additional options: 799 Since queries from recursive resolvers to authoritative servers are 800 performed using cleartext (at the time of writing), resolver services 801 need to consider the extent to which they may be directly leaking 802 information about their client community via these upstream queries 803 and what they can do to mitigate this further. Note, that even when 804 all the relevant techniques described above are employed there may 805 still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For 806 example, a resolver with a very small community of users risks 807 exposing data in this way and OUGHT obfuscate this traffic by mixing 808 it with 'generated' traffic to make client characterization harder. 809 The resolver could also employ aggressive pre-fetch techniques as a 810 further measure to counter traffic analysis. 812 At the time of writing there are no standardized or widely recognized 813 techniques to perform such obfuscation or bulk pre-fetches. 815 Another technique that particularly small operators may consider is 816 forwarding local traffic to a larger resolver (with a privacy policy 817 that aligns with their own practices) over an encrypted protocol so 818 that the upstream queries are obfuscated among those of the large 819 resolver. 821 5.3.3. Data sharing 823 [RFC6973] Threats: 825 o Surveillance 827 o Stored data compromise 829 o Correlation 831 o Identification 833 o Secondary use 835 o Disclosure 837 DNS Privacy Threats: 839 o Contravention of legal requirements not to process user data? 841 Mitigations: 843 Operators should not provide identifiable data to third-parties 844 without explicit consent from clients (we take the stance here that 845 simply using the resolution service itself does not constitute 846 consent). 848 Even when consent is granted operators should employ data 849 minimization techniques such as those described in Section 5.2.1 if 850 data is shared with third-parties. 852 Operators should consider including specific guidelines for the 853 collection of aggregated and/or anonymized data for research 854 purposes, within or outside of their own organization. See SURFnet's 855 policy [13] on data sharing for research as an example. 857 TODO: More on data for research vs operations... how to still 858 motivate operators to share anonymized data? 860 TODO: Guidelines for when consent is granted? 862 TODO: Applies to server data handling too.. could operators offer 863 alternatives services one that implies consent for data processing, 864 one that doesn't? 866 6. DNS privacy policy and practice statement 868 6.1. Recommended contents of a DPPPS 870 6.1.1. Policy 872 1. Make an explicit statement that IP addressses are treated as PII 874 2. State if IP addresses are being logged 876 3. Specify clearly what data (including whether it is aggregated, 877 pseudonymized or anonymized and the conditions of data transfer) 878 is: 880 * Collected and retained by the operator, and for what period it 881 is retained 883 * Shared with partners 885 * Shared, sold or rented to third-parties 887 4. Specify any exceptions to the above, for example technically 888 malicious or anomalous behavior 890 5. Declare any partners, third-party affiliations or sources of 891 funding 893 6. Whether user DNS data is correlated or combined with any other 894 personal information held by the operator 896 7. Result filtering. This section should explain whether the 897 operator filters, edits or alters in any way the replies that it 898 receives from the authoritative servers for each DNS zone, before 899 forwarding them to the clients. For each category listed below, 900 the operator should also specify how the filtering lists are 901 created and managed, whether it employs any third-party sources 902 for such lists, and which ones. 904 * Specify if any replies are being filtered out or altered for 905 network and computer security reasons (e.g. preventing 906 connections to malware-spreading websites or botnet control 907 servers) 909 * Specify if any replies are being filtered out or altered for 910 mandatory legal reasons, due to applicable legislation or 911 binding orders by courts and other public authorities 913 * Specify if any replies are being filtered out or altered for 914 voluntary legal reasons, due to an internal policy by the 915 operator aiming at reducing potential legal risks 917 * Specify if any replies are being filtered out or altered for 918 any other reason, including commercial ones 920 6.1.2. Practice 922 This section should explain the current operational practices of the 923 service. 925 1. Specify any temporary or permanent deviations from the policy for 926 operational reasons 928 2. With reference to section Section 5 provide specific details of 929 which capabilities are provided on which client facing addresses 930 and ports 932 3. Specify the authentication name to be used (if any) and if TLSA 933 records are published (including options used in the TLSA 934 records) 936 4. Specify the SPKI pinsets to be used (if any) and policy for 937 rolling keys 939 5. Provide contact/support information for the service 941 6. Jurisdiction. This section should communicate the applicable 942 jurisdictions and law enforcement regimes under which the service 943 is being provided. 945 * Specify the entity or entities that will control the data and 946 be responsible for their treatment, and their legal place of 947 business 949 * Specify, either directly or by pointing to the applicable 950 privacy policy, the relevant privacy laws that apply to the 951 treatment of the data, the rights that users enjoy in regard 952 to their own personal information that is treated by the 953 service, and how they can contact the operator to enforce them 955 * Specify the countries in which the servers handling the DNS 956 requests and the data are located (if the operator applies a 957 geolocation policy so that requests from certain countries are 958 only served by certain servers, this should be specified as 959 well) 961 * Specify whether the operator has any agreement in place with 962 law enforcement agencies, or other public and private parties 963 dealing with security and intelligence, to give them access to 964 the servers and/or to the data 966 7. Describe how consent is obtained from the user of the DNS privacy 967 service differentiating 969 * Uninformed users for whom this trust relationship is implicit 971 * Privacy-conscious users, that make an explicit trust choice 973 (this may prove relevant in the context of e.g. the GDPR as it 974 relates to consent) 976 6.2. Current policy and privacy statements 978 A tabular comparison of existing policy and privacy statements from 979 various DNS Privacy service operators based on the proposed DPPPS 980 structure can be found on dnsprivacy.org [14]. 982 We note that the existing set of policies vary widely in style, 983 content and detail and it is not uncommon for the full text for a 984 given operator to equate to more than 10 pages of moderate font sized 985 A4 text. It is a non-trivial task today for a user to extract a 986 meaningful overview of the different services on offer. 988 6.3. Enforcement/accountability 990 Transparency reports may help with building user trust that operators 991 adhere to their policies and practices. 993 Independent monitoring or analysis could be performed where possible 994 of: 996 o ECS, QNAME minimization, EDNS(0) padding, etc. 998 o Filtering 1000 o Uptime 1002 This is by analogy with e.g. several TLS or website analysis tools 1003 that are currently available e.g. SSL Labs [15] or Internet.nl [16]. 1005 Additionally operators could choose to engage the services of a third 1006 party auditor to verify their compliance with their published DPPPS. 1008 7. IANA considerations 1010 None 1012 8. Security considerations 1014 Security considerations for DNS-over-TCP are given in [RFC7766], many 1015 of which are generally applicable to session based DNS. 1017 TODO: e.g. New issues for DoS defence, server admin policies 1019 9. Acknowledgements 1021 Many thanks to Amelia Andersdotter for a very thorough review of the 1022 first draft of this document. Thanks to John Todd for discussions on 1023 this topic, and to Stephane Bortzmeyer, Puneet Sood and Vittorio 1024 Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul 1025 Hoffman, Dan York, John Reed, Lorenzo Colitti for comments at the 1026 mic. Thanks to Loganaden Velvindron for useful updates to the text. 1028 Sara Dickinson thanks the Open Technology Fund for a grant to support 1029 the work on this document. 1031 10. Contributors 1033 The below individuals contributed significantly to the document: 1035 John Dickinson 1036 Sinodun Internet Technologies 1037 Magdalen Centre 1038 Oxford Science Park 1039 Oxford OX4 4GA 1040 United Kingdom 1042 Jim Hague 1043 Sinodun Internet Technologies 1044 Magdalen Centre 1045 Oxford Science Park 1046 Oxford OX4 4GA 1047 United Kingdom 1049 11. Changelog 1051 draft-ietf-dprive-bcp-op-02 1053 o Change 'open resolver' for 'public resolver' 1055 o Minor editorial changes 1056 o Remove recommendation to run a separate TLS 1.3 service 1058 o Move TLSA to purely a optimisation in Section 5.2.1 1060 o Update reference on minimal DoH headers. 1062 o Add reference on user switching provider after service issues in 1063 Section 5.1.4 1065 o Add text in Section 5.1.6 on impact on operators. 1067 o Add text on additional threat to TLS proxy use (Section 5.1.7) 1069 o Add reference in Section 5.3.1 on example policies. 1071 draft-ietf-dprive-bcp-op-01 1073 o Many minor editorial fixes 1075 o Update DoH reference to RFC8484 and add more text on DoH 1077 o Split threat descriptions into ones directly referencing RFC6973 1078 and other DNS Privacy threats 1080 o Improve threat descriptions throughout 1082 o Remove reference to the DNSSEC TLS Chain Extension draft until new 1083 version submitted. 1085 o Clarify use of whitelisting for ECS 1087 o Re-structure the DPPPS, add Result filtering section. 1089 o Remove the direct inclusion of privacy policy comparison, now just 1090 reference dnsprivacy.org and an example of such work. 1092 o Add an appendix briefly discussing DNSSEC 1094 o Update affiliation of 1 author 1096 draft-ietf-dprive-bcp-op-00 1098 o Initial commit of re-named document after adoption to replace 1099 draft-dickinson-dprive-bcp-op-01 1101 12. References 1103 12.1. Normative References 1105 [I-D.ietf-dnsop-session-signal] 1106 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1107 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1108 draft-ietf-dnsop-session-signal-20 (work in progress), 1109 December 2018. 1111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1112 Requirement Levels", BCP 14, RFC 2119, 1113 DOI 10.17487/RFC2119, March 1997, . 1116 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1117 "Transport Layer Security (TLS) Session Resumption without 1118 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1119 January 2008, . 1121 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1122 DOI 10.17487/RFC6265, April 2011, . 1125 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1126 Morris, J., Hansen, M., and R. Smith, "Privacy 1127 Considerations for Internet Protocols", RFC 6973, 1128 DOI 10.17487/RFC6973, July 2013, . 1131 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1132 "Recommendations for Secure Use of Transport Layer 1133 Security (TLS) and Datagram Transport Layer Security 1134 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1135 2015, . 1137 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1138 D. Wessels, "DNS Transport over TCP - Implementation 1139 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1140 . 1142 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1143 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1144 . 1146 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1147 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1148 DOI 10.17487/RFC7828, April 2016, . 1151 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1152 DOI 10.17487/RFC7830, May 2016, . 1155 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1156 and P. Hoffman, "Specification for DNS over Transport 1157 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1158 2016, . 1160 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1161 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1162 DOI 10.17487/RFC7871, May 2016, . 1165 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1166 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1167 . 1169 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1170 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1171 May 2017, . 1173 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1174 for DNS over TLS and DNS over DTLS", RFC 8310, 1175 DOI 10.17487/RFC8310, March 2018, . 1178 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 1179 Pervasive Encryption on Operators", RFC 8404, 1180 DOI 10.17487/RFC8404, July 2018, . 1183 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1184 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1185 October 2018, . 1187 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1188 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1189 . 1191 12.2. Informative References 1193 [I-D.bellis-dnsop-xpf] 1194 Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", 1195 draft-bellis-dnsop-xpf-04 (work in progress), March 2018. 1197 [I-D.bortzmeyer-dprive-rfc7626-bis] 1198 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 1199 Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02 1200 (work in progress), January 2019. 1202 [I-D.ietf-dnsop-dns-capture-format] 1203 Dickinson, J., Hague, J., Dickinson, S., Manderson, T., 1204 and J. Bond, "C-DNS: A DNS Packet Capture Format", draft- 1205 ietf-dnsop-dns-capture-format-10 (work in progress), 1206 December 2018. 1208 [I-D.ietf-dnsop-dns-tcp-requirements] 1209 Kristoff, J. and D. Wessels, "DNS Transport over TCP - 1210 Operational Requirements", draft-ietf-dnsop-dns-tcp- 1211 requirements-03 (work in progress), January 2019. 1213 [I-D.ietf-dnsop-terminology-bis] 1214 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1215 Terminology", draft-ietf-dnsop-terminology-bis-14 (work in 1216 progress), September 2018. 1218 [I-D.ietf-httpbis-bcp56bis] 1219 Nottingham, M., "Building Protocols with HTTP", draft- 1220 ietf-httpbis-bcp56bis-08 (work in progress), November 1221 2018. 1223 [pcap] tcpdump.org, "PCAP", 2016, . 1225 [Pitfalls-of-DNS-Encryption] 1226 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS 1227 Encryption", 2014, . 1230 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1231 Rose, "DNS Security Introduction and Requirements", 1232 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1233 . 1235 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1236 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1237 . 1239 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 1240 Framework for DNSSEC Policies and DNSSEC Practice 1241 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 1242 . 1244 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1245 Known Attacks on Transport Layer Security (TLS) and 1246 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1247 February 2015, . 1249 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 1250 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 1251 2015, . 1253 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 1254 Servers by Running One on Loopback", RFC 7706, 1255 DOI 10.17487/RFC7706, November 2015, . 1258 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1259 Transport Layer Security (DTLS)", RFC 8094, 1260 DOI 10.17487/RFC8094, February 2017, . 1263 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 1264 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 1265 July 2017, . 1267 12.3. URIs 1269 [1] https://www.ietf.org/mail-archive/web/dns-privacy/current/ 1270 pdfWqAIUmEl47.pdf 1272 [2] https://petsymposium.org/2018/files/hotpets/4-siby.pdf 1274 [3] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/ 1275 tma2018_paper30.pdf 1277 [4] http://dnstap.info 1279 [5] https://nginx.org/ 1281 [6] https://www.haproxy.org/ 1283 [7] https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html 1285 [8] https://dnsdist.org 1287 [9] https://doi.org/10.1145/3182660 1289 [10] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/ 1290 draft-00/ip_techniques_table.svg 1292 [11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16 1293 4fb2138a44.pdf 1295 [12] https://kb.isc.org/docs/aa-00482 1297 [13] https://surf.nl/datasharing 1299 [14] https://dnsprivacy.org/wiki/display/DP/ 1300 Comparison+of+policy+and+privacy+statements 1302 [15] https://www.ssllabs.com/ssltest/ 1304 [16] https://internet.nl 1306 [17] https://support.google.com/analytics/answer/2763052?hl=en 1308 [18] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip- 1309 geo-impact-test/ 1311 [19] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc 1313 [20] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html 1315 [21] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn- 1316 anon.pdf 1318 [22] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ 1320 [23] http://mharvan.net/talks/noms-ip_anon.pdf 1322 [24] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf 1324 [25] https://medium.com/@bert.hubert/on-ip-address-encryption- 1325 security-analysis-with-respect-for-privacy-dabe1201b476 1327 [26] https://github.com/PowerDNS/ipcipher 1329 [27] https://github.com/veorq/ipcrypt 1331 [28] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html 1333 [29] https://tnc18.geant.org/core/presentation/127 1335 Appendix A. Documents 1337 This section provides an overview of some DNS privacy related 1338 documents, however, this is neither an exhaustive list nor a 1339 definitive statement on the characteristic of the document. 1341 A.1. Potential increases in DNS privacy 1343 These documents are limited in scope to communications between stub 1344 clients and recursive resolvers: 1346 o 'Specification for DNS over Transport Layer Security (TLS)' 1347 [RFC7858], referred to here as 'DNS-over-TLS'. 1349 o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094], 1350 referred to here as 'DNS-over-DTLS'. Note that this document has 1351 the Category of Experimental. 1353 o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH. 1355 o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310] 1357 o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for 1358 EDNS(0)' [RFC8467] 1360 These documents apply to recursive to authoritative DNS but are 1361 relevant when considering the operation of a recursive server: 1363 o 'DNS Query Name minimization to Improve Privacy' [RFC7816] 1364 referred to here as 'QNAME minimization' 1366 A.2. Potential decreases in DNS privacy 1368 These documents relate to functionality that could provide increased 1369 tracking of user activity as a side effect: 1371 o 'Client Subnet in DNS Queries' [RFC7871] 1373 o 'Domain Name System (DNS) Cookies' [RFC7873]) 1375 o 'Transport Layer Security (TLS) Session Resumption without Server- 1376 Side State' [RFC5077] referred to here as simply TLS session 1377 resumption. 1379 o 'A DNS Packet Capture Format' [I-D.ietf-dnsop-dns-capture-format] 1381 o Passive DNS [I-D.ietf-dnsop-terminology-bis] 1382 Note that depending on the specifics of the implementation [RFC8484] 1383 may also provide increased tracking. 1385 A.3. Related operational documents 1387 o 'DNS Transport over TCP - Implementation Requirements' [RFC7766] 1389 o 'Operational requirements for DNS-over-TCP' 1390 [I-D.ietf-dnsop-dns-tcp-requirements] 1392 o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828] 1394 o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal] 1396 Appendix B. Encryption and DNSSEC 1398 The addition of encryption to DNS does not remove the need for DNSSEC 1399 [RFC4033] - they are independent and fully compatible protocols, each 1400 solving different problems. The use of one does not diminish the 1401 need nor the usefulness of the other. 1403 All DNS privacy services SHOULD offer a DNS privacy service that 1404 performs DNSSEC validation. In addition they SHOULD be able to 1405 provide the DNSSEC RRs to the client so that it can perform its own 1406 validation. 1408 While the use of an authenticated and encrypted transport protects 1409 origin authentication and data integrity between a client and a DNS 1410 privacy service it provides no proof (for a non-validating client) 1411 that the data provided by the DNS privacy service was actually DNSSEC 1412 authenticated. 1414 Appendix C. IP address techniques 1416 Data minimization methods may be categorized by the processing used 1417 and the properties of their outputs. The following builds on the 1418 categorization employed in [RFC6235]: 1420 o Format-preserving. Normally when encrypting, the original data 1421 length and patterns in the data should be hidden from an attacker. 1422 Some applications of de-identification, such as network capture 1423 de-identification, require that the de-identified data is of the 1424 same form as the original data, to allow the data to be parsed in 1425 the same way as the original. 1427 o Prefix preservation. Values such as IP addresses and MAC 1428 addresses contain prefix information that can be valuable in 1429 analysis, e.g. manufacturer ID in MAC addresses, subnet in IP 1430 addresses. Prefix preservation ensures that prefixes are de- 1431 identified consistently; e.g. if two IP addresses are from the 1432 same subnet, a prefix preserving de-identification will ensure 1433 that their de-identified counterparts will also share a subnet. 1434 Prefix preservation may be fixed (i.e. based on a user selected 1435 prefix length identified in advance to be preserved ) or general. 1437 o Replacement. A one-to-one replacement of a field to a new value 1438 of the same type, for example using a regular expression. 1440 o Filtering. Removing (and thus truncating) or replacing data in a 1441 field. Field data can be overwritten, often with zeros, either 1442 partially (grey marking) or completely (black marking). 1444 o Generalization. Data is replaced by more general data with 1445 reduced specificity. One example would be to replace all TCP/UDP 1446 port numbers with one of two fixed values indicating whether the 1447 original port was ephemeral (>=1024) or non-ephemeral (>1024). 1448 Another example, precision degradation, reduces the accuracy of 1449 e.g. a numeric value or a timestamp. 1451 o Enumeration. With data from a well-ordered set, replace the first 1452 data item data using a random initial value and then allocate 1453 ordered values for subsequent data items. When used with 1454 timestamp data, this preserves ordering but loses precision and 1455 distance. 1457 o Reordering/shuffling. Preserving the original data, but 1458 rearranging its order, often in a random manner. 1460 o Random substitution. As replacement, but using randomly generated 1461 replacement values. 1463 o Cryptographic permutation. Using a permutation function, such as 1464 a hash function or cryptographic block cipher, to generate a 1465 replacement de-identified value. 1467 C.1. Google Analytics non-prefix filtering 1469 Since May 2010, Google Analytics has provided a facility [17] that 1470 allows website owners to request that all their users IP addresses 1471 are anonymized within Google Analytics processing. This very basic 1472 anonymization simply sets to zero the least significant 8 bits of 1473 IPv4 addresses, and the least significant 80 bits of IPv6 addresses. 1474 The level of anonymization this produces is perhaps questionable. 1475 There are some analysis results [18] which suggest that the impact of 1476 this on reducing the accuracy of determining the user's location from 1477 their IP address is less than might be hoped; the average discrepancy 1478 in identification of the user city for UK users is no more than 17%. 1480 Anonymization: Format-preserving, Filtering (grey marking). 1482 C.2. dnswasher 1484 Since 2006, PowerDNS have included a de-identification tool dnswasher 1485 [19] with their PowerDNS product. This is a PCAP filter that 1486 performs a one-to-one mapping of end user IP addresses with an 1487 anonymized address. A table of user IP addresses and their de- 1488 identified counterparts is kept; the first IPv4 user addresses is 1489 translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de- 1490 identified address therefore depends on the order that addresses 1491 arrive in the input, and running over a large amount of data the 1492 address translation tables can grow to a significant size. 1494 Anonymization: Format-preserving, Enumeration. 1496 C.3. Prefix-preserving map 1498 Used in TCPdpriv [20], this algorithm stores a set of original and 1499 anonymised IP address pairs. When a new IP address arrives, it is 1500 compared with previous addresses to determine the longest prefix 1501 match. The new address is anonymized by using the same prefix, with 1502 the remainder of the address anonymized with a random value. The use 1503 of a random value means that TCPdrpiv is not deterministic; different 1504 anonymized values will be generated on each run. The need to store 1505 previous addresses means that TCPdpriv has significant and unbounded 1506 memory requirements, and because of the need to allocated anonymized 1507 addresses sequentially cannot be used in parallel processing. 1509 Anonymization: Format-preserving, prefix preservation (general). 1511 C.4. Cryptographic Prefix-Preserving Pseudonymisation 1513 Cryptographic prefix-preserving pseudonymisation was originally 1514 proposed as an improvement to the prefix-preserving map implemented 1515 in TCPdpriv, described in Xu et al. [21] and implemented in the 1516 Crypto-PAn tool [22]. Crypto-PAn is now frequently used as an 1517 acronym for the algorithm. Initially it was described for IPv4 1518 addresses only; extension for IPv6 addresses was proposed in Harvan & 1519 Schoenwaelder [23] and implemented in snmpdump. This uses a 1520 cryptographic algorithm rather than a random value, and thus 1521 pseudonymity is determined uniquely by the encryption key, and is 1522 deterministic. It requires a separate AES encryption for each output 1523 bit, so has a non-trivial calculation overhead. This can be 1524 mitigated to some extent (for IPv4, at least) by pre-calculating 1525 results for some number of prefix bits. 1527 Pseudonymization: Format-preserving, prefix preservation (general). 1529 C.5. Top-hash Subtree-replicated Anonymisation 1531 Proposed in Ramaswamy & Wolf [24], Top-hash Subtree-replicated 1532 Anonymisation (TSA) originated in response to the requirement for 1533 faster processing than Crypto-PAn. It used hashing for the most 1534 significant byte of an IPv4 address, and a pre-calculated binary tree 1535 structure for the remainder of the address. To save memory space, 1536 replication is used within the tree structure, reducing the size of 1537 the pre-calculated structures to a few Mb for IPv4 addresses. 1538 Address pseudonymization is done via hash and table lookup, and so 1539 requires minimal computation. However, due to the much increased 1540 address space for IPv6, TSA is not memory efficient for IPv6. 1542 Pseudonymization: Format-preserving, prefix preservation (general). 1544 C.6. ipcipher 1546 A recently-released proposal from PowerDNS [25], ipcipher [26] is a 1547 simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6 1548 addresses are encrypted directly with AES-128 using a key (which may 1549 be derived from a passphrase). IPv4 addresses are similarly 1550 encrypted, but using a recently proposed encryption ipcrypt [27] 1551 suitable for 32bit block lengths. However, the author of ipcrypt has 1552 since indicated [28] that it has low security, and further analysis 1553 has revealed it is vulnerable to attack. 1555 Pseudonymization: Format-preserving, cryptographic permutation. 1557 C.7. Bloom filters 1559 van Rijswijk-Deij et al. [29] have recently described work using 1560 Bloom filters to categorize query traffic and record the traffic as 1561 the state of multiple filters. The goal of this work is to allow 1562 operators to identify so-called Indicators of Compromise (IOCs) 1563 originating from specific subnets without storing information about, 1564 or be able to monitor the DNS queries of an individual user. By 1565 using a Bloom filter, it is possible to determine with a high 1566 probability if, for example, a particular query was made, but the set 1567 of queries made cannot be recovered from the filter. Similarly, by 1568 mixing queries from a sufficient number of users in a single filter, 1569 it becomes practically impossible to determine if a particular user 1570 performed a particular query. Large numbers of queries can be 1571 tracked in a memory-efficient way. As filter status is stored, this 1572 approach cannot be used to regenerate traffic, and so cannot be used 1573 with tools used to process live traffic. 1575 Anonymized: Generalization. 1577 Authors' Addresses 1579 Sara Dickinson 1580 Sinodun IT 1581 Magdalen Centre 1582 Oxford Science Park 1583 Oxford OX4 4GA 1584 United Kingdom 1586 Email: sara@sinodun.com 1588 Benno J. Overeinder 1589 NLnet Labs 1590 Science Park 400 1591 Amsterdam 1098 XH 1592 The Netherlands 1594 Email: benno@nlnetLabs.nl 1596 Roland M. van Rijswijk-Deij 1597 NLnet Labs 1598 Science Park 400 1599 Amsterdam 1098 XH 1600 The Netherlands 1602 Email: roland@nlnetLabs.nl 1604 Allison Mankin 1605 Salesforce 1607 Email: allison.mankin@gmail.com