idnits 2.17.1 draft-ietf-dprive-bcp-op-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 date (December 18, 2019) is 1590 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) == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-03 ** Downref: Normative reference to an Informational draft: draft-ietf-dprive-rfc7626-bis (ref. 'I-D.ietf-dprive-rfc7626-bis') ** 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-05 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: June 20, 2020 R. van Rijswijk-Deij 6 NLnet Labs 7 A. Mankin 8 Salesforce 9 December 18, 2019 11 Recommendations for DNS Privacy Service Operators 12 draft-ietf-dprive-bcp-op-07 14 Abstract 16 This document presents operational, policy and security 17 considerations for DNS recursive resolver operators who choose to 18 offer DNS Privacy services. With these recommendations, the operator 19 can make deliberate decisions regarding which services to provide, 20 and how the decisions and alternatives impact the privacy of users. 22 This document also presents a framework to assist writers of a DNS 23 Recursive Operator Privacy Statement (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 June 20, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 of Encryption on DNS Monitoring . . . . . . . 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 . . . . . . . . . . . . . . . 17 81 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 82 5.3. Data sent onwards from the server . . . . . . . . . . . . 18 83 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18 84 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19 85 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 86 6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 20 87 6.1. Recommended contents of a DROP statement . . . . . . . . 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 . . . . . . . . . . . . . . . 23 92 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 93 8. Security considerations . . . . . . . . . . . . . . . . . . . 23 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 96 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 99 12.2. Informative References . . . . . . . . . . . . . . . . . 28 100 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 32 101 A.1. Potential increases in DNS privacy . . . . . . . . . . . 32 102 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 33 103 A.3. Related operational documents . . . . . . . . . . . . . . 33 104 Appendix B. IP address techniques . . . . . . . . . . . . . . . 34 105 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 35 106 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 35 107 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 35 108 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 36 109 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 36 110 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 36 111 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 37 112 Appendix C. Example DROP statement . . . . . . . . . . . . . . . 37 113 C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 37 114 C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 40 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 117 1. Introduction 119 The Domain Name System (DNS) is at the core of the Internet; almost 120 every activity on the Internet starts with a DNS query (and often 121 several). However the DNS was not originally designed with strong 122 security or privacy mechanisms. A number of developments have taken 123 place in recent years which aim to increase the privacy of the DNS 124 system and these are now seeing some deployment. This latest 125 evolution of the DNS presents new challenges to operators and this 126 document attempts to provide an overview of considerations for 127 privacy focused DNS services. 129 In recent years there has also been an increase in the availability 130 of "public resolvers" [RFC8499] which users may prefer to use instead 131 of the default network resolver because they offer a specific feature 132 (e.g. good reachability, encrypted transport, strong privacy policy, 133 filtering (or lack of), etc.). These open resolvers have tended to 134 be at the forefront of adoption of privacy related enhancements but 135 it is anticipated that operators of other resolver services will 136 follow. 138 Whilst protocols that encrypt DNS messages on the wire provide 139 protection against certain attacks, the resolver operator still has 140 (in principle) full visibility of the query data and transport 141 identifiers for each user. Therefore, a trust relationship exists. 142 The ability of the operator to provide a transparent, well 143 documented, and secure privacy service will likely serve as a major 144 differentiating factor for privacy conscious users if they make an 145 active selection of which resolver to use. 147 It should also be noted that the choice of a user to configure a 148 single resolver (or a fixed set of resolvers) and an encrypted 149 transport to use in all network environments has both advantages and 150 disadvantages. For example the user has a clear expectation of which 151 resolvers have visibility of their query data however this resolver/ 152 transport selection may provide an added mechanism to track them as 153 they move across network environments. Commitments from operators to 154 minimize such tracking are also likely to play a role in user 155 selection of resolvers. 157 More recently the global legislative landscape with regard to 158 personal data collection, retention, and pseudonymization has seen 159 significant activity. It is an untested area that simply using a DNS 160 resolution service constitutes consent from the user for the operator 161 to process their query data. The impact of recent legislative 162 changes on data pertaining to the users of both Internet Service 163 Providers and public DNS resolvers is not fully understood at the 164 time of writing. 166 This document has two main goals: 168 o To provide operational and policy guidance related to DNS over 169 encrypted transports and to outline recommendations for data 170 handling for operators of DNS privacy services. 172 o To introduce the DNS Recursive Operator Privacy (DROP) statement 173 and present a framework to assist writers of this document. A 174 DROP statement is a document that an operator can publish 175 outlining their operational practices and commitments with regard 176 to privacy thereby providing a means for clients to evaluate the 177 privacy properties of a given DNS privacy service. In particular, 178 the framework identifies the elements that should be considered in 179 formulating a DROP statement. This document does not, however, 180 define a particular Privacy statement, nor does it seek to provide 181 legal advice or recommendations as to the contents. 183 A desired operational impact is that all operators (both those 184 providing resolvers within networks and those operating large public 185 services) can demonstrate their commitment to user privacy thereby 186 driving all DNS resolution services to a more equitable footing. 187 Choices for users would (in this ideal world) be driven by other 188 factors e.g. differing security policies or minor difference in 189 operator policy rather than gross disparities in privacy concerns. 191 Community insight [or judgment?] about operational practices can 192 change quickly, and experience shows that a Best Current Practice 193 (BCP) document about privacy and security is a point-in-time 194 statement. Readers are advised to seek out any errata or updates 195 that apply to this document. 197 2. Scope 199 "DNS Privacy Considerations" [I-D.ietf-dprive-rfc7626-bis] describes 200 the general privacy issues and threats associated with the use of the 201 DNS by Internet users and much of the threat analysis here is lifted 202 from that document and from [RFC6973]. However this document is 203 limited in scope to best practice considerations for the provision of 204 DNS privacy services by servers (recursive resolvers) to clients 205 (stub resolvers or forwarders). Privacy considerations specifically 206 from the perspective of an end user, or those for operators of 207 authoritative nameservers are out of scope. 209 This document includes (but is not limited to) considerations in the 210 following areas (taken from [I-D.ietf-dprive-rfc7626-bis]): 212 1. Data "on the wire" between a client and a server. 214 2. Data "at rest" on a server (e.g. in logs). 216 3. Data "sent onwards" from the server (either on the wire or shared 217 with a third party). 219 Whilst the issues raised here are targeted at those operators who 220 choose to offer a DNS privacy service, considerations for areas 2 and 221 3 could equally apply to operators who only offer DNS over 222 unencrypted transports but who would like to align with privacy best 223 practice. 225 3. Privacy related documents 227 There are various documents that describe protocol changes that have 228 the potential to either increase or decrease the privacy of the DNS. 229 Note this does not imply that some documents are good or bad, better 230 or worse, just that (for example) some features may bring functional 231 benefits at the price of a reduction in privacy and conversely some 232 features increase privacy with an accompanying increase in 233 complexity. A selection of the most relevant documents are listed in 234 Appendix A for reference. 236 4. Terminology 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 240 "OPTIONAL" in this document are to be interpreted as described in BCP 241 14 [RFC2119] [RFC8174] when, and only when, they appear in all 242 capitals, as shown here. 244 DNS terminology is as described in [RFC8499] with one modification: 245 we restate the clause in the original definition of Privacy-enabling 246 DNS server in [RFC8310] to include the requirement that a DNS over 247 (D)TLS server should also offer at least one of the credentials 248 described in Section 8 of [RFC8310] and implement the (D)TLS profile 249 described in Section 9 of [RFC8310]. 251 Other Terms: 253 o DROP: DNS Recursive Operator Privacy statement, see Section 6. 255 o DNS privacy service: The service that is offered via a privacy- 256 enabling DNS server and is documented either in an informal 257 statement of policy and practice with regard to users privacy or a 258 formal DROP statement. 260 5. Recommendations for DNS privacy services 262 We describe two classes of threats: 264 o Threats described in [RFC6973] 'Privacy Considerations for 265 Internet Protocols' 267 * Privacy terminology, threats to privacy and mitigations as 268 described in Sections 3, 5 and 6 of [RFC6973]. 270 o DNS Privacy Threats 272 * These are threats to the users and operators of DNS privacy 273 services that are not directly covered by [RFC6973]. These may 274 be more operational in nature such as certificate management or 275 service availability issues. 277 We describe three classes of actions that operators of DNS privacy 278 services can take: 280 o Threat mitigation for well understood and documented privacy 281 threats to the users of the service and in some cases to the 282 operators of the service. 284 o Optimization of privacy services from an operational or management 285 perspective. 287 o Additional options that could further enhance the privacy and 288 usability of the service. 290 This document does not specify policy - only best practice, however 291 for DNS Privacy services to be considered compliant with these best 292 practice guidelines they SHOULD implement (where appropriate) all: 294 o Threat mitigations to be minimally compliant. 296 o Optimizations to be moderately compliant. 298 o Additional options to be maximally compliant. 300 5.1. On the wire between client and server 302 In this section we consider both data on the wire and the service 303 provided to the client. 305 5.1.1. Transport recommendations 307 [RFC6973] Threats: 309 o Surveillance: 311 * Passive surveillance of traffic on the wire 312 [I-D.ietf-dprive-rfc7626-bis] Section 2.4.2. 314 DNS Privacy Threats: 316 o Active injection of spurious data or traffic. 318 Mitigations: 320 A DNS privacy service can mitigate these threats by providing service 321 over one or more of the following transports 323 o DNS-over-TLS [RFC7858] and [RFC8310]. 325 o DoH [RFC8484]. 327 It is noted that a DNS privacy service can also be provided over DNS- 328 over-DTLS [RFC8094], however this is an Experimental specification 329 and there are no known implementations at the time of writing. 331 It is also noted that DNS privacy service might be provided over 332 IPSec, DNSCrypt or VPNs. However, use of these transports for DNS 333 are not standardized and any discussion of best practice for 334 providing such a service is out of scope for this document. 336 Whilst encryption of DNS traffic can protect against active injection 337 this does not diminish the need for DNSSEC, see Section 5.1.4. 339 5.1.2. Authentication of DNS privacy services 341 [RFC6973] Threats: 343 o Surveillance: 345 * Active attacks that can redirect traffic to rogue servers 346 [I-D.ietf-dprive-rfc7626-bis] Section 2.5.3. 348 Mitigations: 350 DNS privacy services should ensure clients can authenticate the 351 server. Note that this, in effect, commits the DNS privacy service 352 to a public identity users will trust. 354 When using DNS-over-TLS clients that select a 'Strict Privacy' usage 355 profile [RFC8310] (to mitigate the threat of active attack on the 356 client) require the ability to authenticate the DNS server. To 357 enable this, DNS privacy services that offer DNS-over-TLS should 358 provide credentials in the form of either X.509 certificates 359 [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310]. 361 When offering DoH [RFC8484], HTTPS requires authentication of the 362 server as part of the protocol. 364 5.1.2.1. Certificate management 366 Anecdotal evidence to date highlights the management of certificates 367 as one of the more challenging aspects for operators of traditional 368 DNS resolvers that choose to additionally provide a DNS privacy 369 service as management of such credentials is new to those DNS 370 operators. 372 It is noted that SPKI pin set management is described in [RFC7858] 373 but that key pinning mechanisms in general have fallen out of favor 374 operationally for various reasons such as the logistical overhead of 375 rolling keys. 377 DNS Privacy Threats: 379 o Invalid certificates, resulting in an unavailable service. 381 o Mis-identification of a server by a client e.g. typos in URLs or 382 authentication domain names. 384 Mitigations: 386 It is recommended that operators: 388 o Follow the guidance in Section 6.5 of [RFC7525] with regards to 389 certificate revocation . 391 o Automate the generation, publication and renewal of certificates. 392 For example, ACME [RFC8555] provides a mechanism to actively 393 manage certificates through automation and has been implemented by 394 a number of certificate authorities. 396 o Monitor certificates to prevent accidental expiration of 397 certificates. 399 o Choose a short, memorable authentication name for the service. 401 5.1.3. Protocol recommendations 403 5.1.3.1. DNS-over-TLS 405 DNS Privacy Threats: 407 o Known attacks on TLS such as those described in [RFC7457]. 409 o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption]. 411 o Potential for client tracking via transport identifiers. 413 o Blocking of well known ports (e.g. 853 for DNS-over-TLS). 415 Mitigations: 417 In the case of DNS-over-TLS, TLS profiles from Section 9 and the 418 Countermeasures to DNS Traffic Analysis from section 11.1 of 419 [RFC8310] provide strong mitigations. This includes but is not 420 limited to: 422 o Adhering to [RFC7525]. 424 o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]. 426 o Implementing EDNS(0) Padding [RFC7830] using the guidelines in 427 [RFC8467] or a successor specification. 429 o Servers should not degrade in any way the query service level 430 provided to clients that do not use any form of session resumption 431 mechanism, such as TLS session resumption [RFC5077] with TLS 1.2, 432 section 2.2 of RFC8446, or Domain Name System (DNS) Cookies 433 [RFC7873]. 435 o A DNS-over-TLS privacy service on both port 853 and 443. This 436 practice may not be possible if e.g. the operator deploys DoH on 437 the same IP address. 439 Optimizations: 441 o Concurrent processing of pipelined queries, returning responses as 442 soon as available, potentially out of order as specified in 443 [RFC7766]. This is often called 'OOOR' - out-of-order responses 444 (providing processing performance similar to HTTP multiplexing). 446 o Management of TLS connections to optimize performance for clients 447 using either: 449 * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or 451 * DNS Stateful Operations [RFC8490]. 453 5.1.3.2. DoH 455 DNS Privacy Threats: 457 o Known attacks on TLS such as those described in [RFC7457]. 459 o Traffic analysis, for example: [DNS-Privacy-not-so-private]. 461 o Potential for client tracking via transport identifiers. 463 Mitigations: 465 o Clients must be able to forego the use of HTTP Cookies [RFC6265] 466 and still use the service. 468 o Clients should not be required to include any headers beyond the 469 absolute minimum to obtain service from a DoH server. (See 470 Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) 472 5.1.4. DNSSEC 474 DNS Privacy Threats: 476 o Users may be directed to bogus IP addresses for e.g. websites 477 where they might reveal personal information to attackers. 479 Mitigations: 481 o All DNS privacy services must offer a DNS privacy service that 482 performs DNSSEC validation. In addition they must be able to 483 provide the DNSSEC RRs to the client so that it can perform its 484 own validation. 486 The addition of encryption to DNS does not remove the need for DNSSEC 487 [RFC4033] - they are independent and fully compatible protocols, each 488 solving different problems. The use of one does not diminish the 489 need nor the usefulness of the other. 491 While the use of an authenticated and encrypted transport protects 492 origin authentication and data integrity between a client and a DNS 493 privacy service it provides no proof (for a non-validating client) 494 that the data provided by the DNS privacy service was actually DNSSEC 495 authenticated. As with cleartext DNS the user is still solely 496 trusting the AD bit (if present) set by the resolver. 498 It should also be noted that the use of an encrypted transport for 499 DNS actually solves many of the practical issues encountered by DNS 500 validating clients e.g. interference by middleboxes with cleartext 501 DNS payloads is completely avoided. In this sense a validating 502 client that uses a DNS privacy service which supports DNSSEC has a 503 far simpler task in terms of DNS Roadblock avoidance. 505 5.1.5. Availability 507 DNS Privacy Threats: 509 o A failed DNS privacy service could force the user to switch 510 providers, fallback to cleartext or accept no DNS service for the 511 outage. 513 Mitigations: 515 A DNS privacy service should strive to engineer encrypted services to 516 the same availability level as any unencrypted services they provide. 517 Particular care should to be taken to protect DNS privacy services 518 against denial-of-service attacks, as experience has shown that 519 unavailability of DNS resolving because of attacks is a significant 520 motivation for users to switch services. See, for example 521 Section IV-C of [Passive-Observations-of-a-Large-DNS]. 523 Techniques such as those described in Section 10 of [RFC7766] can be 524 of use to operators to defend against such attacks. 526 5.1.6. Service options 528 DNS Privacy Threats: 530 o Unfairly disadvantaging users of the privacy service with respect 531 to the services available. This could force the user to switch 532 providers, fallback to cleartext or accept no DNS service for the 533 outage. 535 Mitigations: 537 A DNS privacy service should deliver the same level of service as 538 offered on un-encrypted channels in terms of such options as 539 filtering (or lack thereof), DNSSEC validation, etc. 541 5.1.7. Impact of Encryption on DNS Monitoring 543 DNS Privacy Threats: 545 o Increased use of encryption impacts operator ability to manage 546 their network [RFC8404]. 548 Many monitoring solutions for DNS traffic rely on the plain text 549 nature of this traffic and work by intercepting traffic on the wire, 550 either using a separate view on the connection between clients and 551 the resolver, or as a separate process on the resolver system that 552 inspects network traffic. Such solutions will no longer function 553 when traffic between clients and resolvers is encrypted. There are, 554 however, legitimate reasons for operators to inspect DNS traffic, 555 e.g. to monitor for network security threats. Operators may 556 therefore need to invest in alternative means of monitoring that 557 relies on either the resolver software directly, or exporting DNS 558 traffic from the resolver using e.g. [dnstap]. 560 Optimization: 562 When implementing alternative means for traffic monitoring, operators 563 of a DNS privacy service should consider using privacy conscious 564 means to do so (see section Section 5.2 for more details on data 565 handling and also the discussion on the use of Bloom Filters in 566 Appendix A. 568 5.1.8. Limitations of using a pure TLS proxy 570 DNS Privacy Threats: 572 o Limited ability to manage or monitor incoming connections using 573 DNS specific techniques. 575 o Misconfiguration of the target server could lead to data leakage 576 if the proxy to target server path is not encrypted. 578 Optimization: 580 Some operators may choose to implement DNS-over-TLS using a TLS proxy 581 (e.g. [nginx], [haproxy] or [stunnel]) in front of a DNS nameserver 582 because of proven robustness and capacity when handling large numbers 583 of client connections, load balancing capabilities and good tooling. 584 Currently, however, because such proxies typically have no specific 585 handling of DNS as a protocol over TLS or DTLS using them can 586 restrict traffic management at the proxy layer and at the DNS server. 587 For example, all traffic received by a nameserver behind such a proxy 588 will appear to originate from the proxy and DNS techniques such as 589 ACLs, RRL or DNS64 will be hard or impossible to implement in the 590 nameserver. 592 Operators may choose to use a DNS aware proxy such as [dnsdist] which 593 offer custom options (similar to that proposed in 594 [I-D.bellis-dnsop-xpf]) to add source information to packets to 595 address this shortcoming. It should be noted that such options 596 potentially significantly increase the leaked information in the 597 event of a misconfiguration. 599 5.2. Data at rest on the server 601 5.2.1. Data handling 603 [RFC6973] Threats: 605 o Surveillance. 607 o Stored data compromise. 609 o Correlation. 611 o Identification. 613 o Secondary use. 615 o Disclosure. 617 Other Threats 619 o Contravention of legal requirements not to process user data. 621 Mitigations: 623 The following are common activities for DNS service operators and in 624 all cases should be minimized or completely avoided if possible for 625 DNS privacy services. If data is retained it should be encrypted and 626 either aggregated, pseudonymized or anonymized whenever possible. In 627 general the principle of data minimization described in [RFC6973] 628 should be applied. 630 o Transient data (e.g. that is used for real time monitoring and 631 threat analysis which might be held only in memory) should be 632 retained for the shortest possible period deemed operationally 633 feasible. 635 o The retention period of DNS traffic logs should be only those 636 required to sustain operation of the service and, to the extent 637 that such exists, meet regulatory requirements. 639 o DNS privacy services should not track users except for the 640 particular purpose of detecting and remedying technically 641 malicious (e.g. DoS) or anomalous use of the service. 643 o Data access should be minimized to only those personnel who 644 require access to perform operational duties. It should also be 645 limited to anonymized or pseudonymized data were operationally 646 feasible, with access to full logs (if any are held) only 647 permitted when necessary. 649 Optimizations: 651 o Consider use of full disk encryption for logs and data capture 652 storage. 654 5.2.2. Data minimization of network traffic 656 Data minimization refers to collecting, using, disclosing, and 657 storing the minimal data necessary to perform a task, and this can be 658 achieved by removing or obfuscating privacy-sensitive information in 659 network traffic logs. This is typically personal data, or data that 660 can be used to link a record to an individual, but may also include 661 revealing other confidential information, for example on the 662 structure of an internal corporate network. 664 The problem of effectively ensuring that DNS traffic logs contain no 665 or minimal privacy-sensitive information is not one that currently 666 has a generally agreed solution or any Standards to inform this 667 discussion. This section presents and overview of current techniques 668 to simply provide reference on the current status of this work. 670 Research into data minimization techniques (and particularly IP 671 address pseudonymization/anonymization) was sparked in the late 672 1990s/early 2000s, partly driven by the desire to share significant 673 corpuses of traffic captures for research purposes. Several 674 techniques reflecting different requirements in this area and 675 different performance/resource tradeoffs emerged over the course of 676 the decade. Developments over the last decade have been both a 677 blessing and a curse; the large increase in size between an IPv4 and 678 an IPv6 address, for example, renders some techniques impractical, 679 but also makes available a much larger amount of input entropy, the 680 better to resist brute force re-identification attacks that have 681 grown in practicality over the period. 683 Techniques employed may be broadly categorized as either 684 anonymization or pseudonymization. The following discussion uses the 685 definitions from [RFC6973] Section 3, with additional observations 686 from [van-Dijkhuizen-et-al.] 688 o Anonymization. To enable anonymity of an individual, there must 689 exist a set of individuals that appear to have the same 690 attribute(s) as the individual. To the attacker or the observer, 691 these individuals must appear indistinguishable from each other. 693 o Pseudonymization. The true identity is deterministically replaced 694 with an alternate identity (a pseudonym). When the 695 pseudonymization schema is known, the process can be reversed, so 696 the original identity becomes known again. 698 In practice there is a fine line between the two; for example, how to 699 categorize a deterministic algorithm for data minimization of IP 700 addresses that produces a group of pseudonyms for a single given 701 address. 703 5.2.3. IP address pseudonymization and anonymization methods 705 As [I-D.ietf-dprive-rfc7626-bis] makes clear, the big privacy risk in 706 DNS is connecting DNS queries to an individual and the major vector 707 for this in DNS traffic is the client IP address. 709 There is active discussion in the space of effective pseudonymization 710 of IP addresses in DNS traffic logs, however there seems to be no 711 single solution that is widely recognized as suitable for all or most 712 use cases. There are also as yet no standards for this that are 713 unencumbered by patents. 715 The following table presents a high level comparison of various 716 techniques employed or under development in 2019 and classifies them 717 according to categorization of technique and other properties. 718 Appendix B provides a more detailed survey of these techniques and 719 definitions for the categories and properties listed below. The list 720 of techniques includes the main techniques in current use, but does 721 not claim to be comprehensive. 723 +---------------------------+----+---+----+---+----+---+---+ 724 | Categorisation/Property | GA | d | TC | C | TS | i | B | 725 +---------------------------+----+---+----+---+----+---+---+ 726 | Anonymisation | X | X | X | | | | X | 727 | Pseudoanonymisation | | | | X | X | X | | 728 | Format preserving | X | X | X | X | X | X | | 729 | Prefix preserving | | | X | X | X | | | 730 | Replacement | | | X | | | | | 731 | Filtering | X | | | | | | | 732 | Generalisation | | | | | | | X | 733 | Enumeration | | X | | | | | | 734 | Reordering/Shuffling | | | X | | | | | 735 | Random substitution | | | X | | | | | 736 | Crytpographic permutation | | | | X | X | X | | 737 | IPv6 issues | | | | | X | | | 738 | CPU intensive | | | | X | | | | 739 | Memory intensive | | | X | | | | | 740 | Security concerns | | | | | | X | | 741 +---------------------------+----+---+----+---+----+---+---+ 743 Table 1: Classification of techniques 745 GA = Google Analytics, d = dnswasher, TC = TCPdpriv, C = CryptoPAn, 746 TS = TSA, i = ipcipher, B = Bloom filter 748 The choice of which method to use for a particular application will 749 depend on the requirements of that application and consideration of 750 the threat analysis of the particular situation. 752 For example, a common goal is that distributed packet captures must 753 be in an existing data format such as PCAP [pcap] or C-DNS [RFC8618] 754 that can be used as input to existing analysis tools. In that case, 755 use of a format-preserving technique is essential. This, though, is 756 not cost-free - several authors (e.g. [Brenker-and-Arnes] have 757 observed that, as the entropy in an IPv4 address is limited, given a 758 de-identified log from a target, if an attacker is capable of 759 ensuring packets are captured by the target and the attacker can send 760 forged traffic with arbitrary source and destination addresses to 761 that target, any format-preserving pseudonymization is vulnerable to 762 an attack along the lines of a cryptographic chosen plaintext attack. 764 5.2.4. Pseudonymization, anonymization or discarding of other 765 correlation data 767 DNS Privacy Threats: 769 o Fingerprinting of the client OS via various means including: IP 770 TTL/Hoplimit, TCP parameters (e.g. window size, ECN support, 771 SACK), OS specific DNS query patterns (e.g. for network 772 connectivity, captive portal detection or OS specific updates). 774 o Fingerprinting of the client application or TLS library by e.g. 775 TLS version/Cipher suite combinations or other connection 776 parameters. 778 o Correlation of queries on multiple TCP session originating from 779 the same IP address. 781 o Correlating of queries on multiple TLS sessions originating from 782 the same client, including via session resumption mechanisms. 784 o Resolvers _might_ receive client identifiers e.g. MAC addresses 785 in EDNS(0) options - some CPE devices are known to add them. 787 o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding). 789 Mitigations: 791 o Data minimization or discarding of such correlation data. 793 5.2.5. Cache snooping 795 [RFC6973] Threats: 797 o Surveillance: 799 * Profiling of client queries by malicious third parties. 801 Mitigations: 803 o See [ISC-Knowledge-database-on-cache-snooping] for an example 804 discussion on defending against cache snooping. 806 5.3. Data sent onwards from the server 808 In this section we consider both data sent on the wire in upstream 809 queries and data shared with third parties. 811 5.3.1. Protocol recommendations 813 [RFC6973] Threats: 815 o Surveillance: 817 * Transmission of identifying data upstream. 819 Mitigations: 821 As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS 822 Privacy services the server should: 824 o Implement QNAME minimization [RFC7816]. 826 o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the 827 EDNS(0) Client Subnet (ECS) option and not send an ECS option in 828 upstream queries. 830 Optimizations: 832 o The server should either: 834 * not use the ECS option in upstream queries at all, or 836 * offer alternative services, one that sends ECS and one that 837 does not. 839 If operators do offer a service that sends the ECS options upstream 840 they should use the shortest prefix that is operationally feasible 841 and ideally use a policy of whitelisting upstream servers to send ECS 842 to in order to minimize data leakage. Operators should make clear in 843 any policy statement what prefix length they actually send and the 844 specific policy used. 846 Whitelisting has the benefit that not only does the operator know 847 which upstream servers can use ECS but also allows the operator to 848 decide which upstream servers apply privacy policies that the 849 operator is happy with. However some operators consider whitelisting 850 to incur significant operational overhead compared to dynamic 851 detection of ECS on authoritative servers. 853 Additional options: 855 o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020] 856 (NXDOMAIN: There Really Is Nothing Underneath) to reduce the 857 number of queries to authoritative servers to increase privacy. 859 o Run a copy of the root zone on loopback [RFC7706] to avoid making 860 queries to the root servers that might leak information. 862 5.3.2. Client query obfuscation 864 Additional options: 866 Since queries from recursive resolvers to authoritative servers are 867 performed using cleartext (at the time of writing), resolver services 868 need to consider the extent to which they may be directly leaking 869 information about their client community via these upstream queries 870 and what they can do to mitigate this further. Note, that even when 871 all the relevant techniques described above are employed there may 872 still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For 873 example, a resolver with a very small community of users risks 874 exposing data in this way and OUGHT obfuscate this traffic by mixing 875 it with 'generated' traffic to make client characterization harder. 876 The resolver could also employ aggressive pre-fetch techniques as a 877 further measure to counter traffic analysis. 879 At the time of writing there are no standardized or widely recognized 880 techniques to perform such obfuscation or bulk pre-fetches. 882 Another technique that particularly small operators may consider is 883 forwarding local traffic to a larger resolver (with a privacy policy 884 that aligns with their own practices) over an encrypted protocol so 885 that the upstream queries are obfuscated among those of the large 886 resolver. 888 5.3.3. Data sharing 890 [RFC6973] Threats: 892 o Surveillance. 894 o Stored data compromise. 896 o Correlation. 898 o Identification. 900 o Secondary use. 902 o Disclosure. 904 DNS Privacy Threats: 906 o Contravention of legal requirements not to process user data. 908 Mitigations: 910 Operators should not provide identifiable data to third-parties 911 without explicit consent from clients (we take the stance here that 912 simply using the resolution service itself does not constitute 913 consent). 915 Operators should consider including specific guidelines for the 916 collection of aggregated and/or anonymized data for research 917 purposes, within or outside of their own organization. This can 918 benefit not only the operator (through inclusion in novel research) 919 but also the wider Internet community. See the policy published by 920 SURFnet [SURFnet-policy] on data sharing for research as an example. 922 6. DNS Recursive Operator Privacy (DROP) statement 924 The following section outlines the recommended contents of a DROP 925 statement an operator might choose to publish. An example statement 926 for a specific scenario is provided for guidance only in Appendix C. 928 6.1. Recommended contents of a DROP statement 930 6.1.1. Policy 932 1. Treatment of IP addresses. Make an explicit statement that IP 933 addresses are treated as PII. 935 2. Data collection and sharing. Specify clearly what data 936 (including IP addresses) is: 938 * Collected and retained by the operator, and for what period it 939 is retained. 941 * Shared with partners. 943 * Shared, sold or rented to third-parties. 945 and in each case whether it is aggregated, pseudonymized or 946 anonymized and the conditions of data transfer. 948 3. Exceptions. Specify any exceptions to the above, for example 949 technically malicious or anomalous behavior. 951 4. Associated entities. Declare any partners, third-party 952 affiliations or sources of funding. 954 5. Correlation. Whether user DNS data is correlated or combined 955 with any other personal information held by the operator. 957 6. Result filtering. This section should explain whether the 958 operator filters, edits or alters in any way the replies that it 959 receives from the authoritative servers for each DNS zone, before 960 forwarding them to the clients. For each category listed below, 961 the operator should also specify how the filtering lists are 962 created and managed, whether it employs any third-party sources 963 for such lists, and which ones. 965 * Specify if any replies are being filtered out or altered for 966 network and computer security reasons (e.g. preventing 967 connections to malware-spreading websites or botnet control 968 servers). 970 * Specify if any replies are being filtered out or altered for 971 mandatory legal reasons, due to applicable legislation or 972 binding orders by courts and other public authorities. 974 * Specify if any replies are being filtered out or altered for 975 voluntary legal reasons, due to an internal policy by the 976 operator aiming at reducing potential legal risks. 978 * Specify if any replies are being filtered out or altered for 979 any other reason, including commercial ones. 981 6.1.2. Practice 983 This section should explain the current operational practices of the 984 service. 986 1. Deviations. Specify any temporary or permanent deviations from 987 the policy for operational reasons. 989 2. Client facing capabilities. With reference to section Section 5 990 provide specific details of which capabilities are provided on 991 which client facing addresses and ports: 993 1. For DoT, specify the authentication name to be used (if any). 995 2. For DoT, specify the SPKI pin sets to be used (if any) and 996 policy for rolling keys. 998 3. Upstream capabilities. With reference to section Section 5.3 999 provide specific details of which capabilities are provided 1000 upstream for data sent to authoritative servers. 1002 4. Support. Provide contact/support information for the service. 1004 5. Jurisdiction. This section should communicate the applicable 1005 jurisdictions and law enforcement regimes under which the service 1006 is being provided. 1008 1. Specify the operator entity or entities that will control the 1009 data and be responsible for their treatment, and their legal 1010 place of business. 1012 2. Specify, either directly or by pointing to the applicable 1013 privacy policy, the relevant privacy laws that apply to the 1014 treatment of the data, the rights that users enjoy in regard 1015 to their own personal information that is treated by the 1016 service, and how they can contact the operator to enforce 1017 them. 1019 3. Additionally specify the countries in which the servers 1020 handling the DNS requests and the data are located (if the 1021 operator applies a geolocation policy so that requests from 1022 certain countries are only served by certain servers, this 1023 should be specified as well). 1025 4. Specify whether the operator has any agreement in place with 1026 law enforcement agencies, or other public and private parties 1027 dealing with security and intelligence, to give them access 1028 to the servers and/or to the data. 1030 6.2. Current policy and privacy statements 1032 A tabular comparison of policy and privacy statements from various 1033 DNS Privacy service operators based loosely on the proposed DROP 1034 structure can be found at [policy-comparison]. The analysis is based 1035 on the data available in December 2019. 1037 We note that the existing set of policies vary widely in style, 1038 content and detail and it is not uncommon for the full text for a 1039 given operator to equate to more than 10 pages of moderate font sized 1040 A4 text. It is a non-trivial task today for a user to extract a 1041 meaningful overview of the different services on offer. 1043 It is also noted that Mozilla have published a DoH resolver policy 1044 [DoH-resolver-policy], which describes the minimum set of policy 1045 requirements that a party must satisfy to be considered as a 1046 potential partner for Mozilla's Trusted Recursive Resolver (TRR) 1047 program. 1049 6.3. Enforcement/accountability 1051 Transparency reports may help with building user trust that operators 1052 adhere to their policies and practices. 1054 Independent monitoring or analysis could be performed where possible 1055 of: 1057 o ECS, QNAME minimization, EDNS(0) padding, etc. 1059 o Filtering. 1061 o Uptime. 1063 This is by analogy with e.g. several TLS or website analysis tools 1064 that are currently available e.g. [SSL-Labs] or [Internet.nl]. 1066 Additionally operators could choose to engage the services of a third 1067 party auditor to verify their compliance with their published DROP 1068 statement. 1070 7. IANA considerations 1072 None 1074 8. Security considerations 1076 Security considerations for DNS-over-TCP are given in [RFC7766], many 1077 of which are generally applicable to session based DNS. Guidance on 1078 operational requirements for DNS-over-TCP are also available in [I- 1079 D.dnsop-dns-tcp-requirements]. 1081 9. Acknowledgements 1083 Many thanks to Amelia Andersdotter for a very thorough review of the 1084 first draft of this document and Stephen Farrell for a thorough 1085 review at WGLC and for suggesting the inclusion of an example DROP 1086 statement. Thanks to John Todd for discussions on this topic, and to 1087 Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review. 1088 Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, 1089 John Reed, Lorenzo Colitti for comments at the mic. Thanks to 1090 Loganaden Velvindron for useful updates to the text. 1092 Sara Dickinson thanks the Open Technology Fund for a grant to support 1093 the work on this document. 1095 10. Contributors 1097 The below individuals contributed significantly to the document: 1099 John Dickinson 1100 Sinodun Internet Technologies 1101 Magdalen Centre 1102 Oxford Science Park 1103 Oxford OX4 4GA 1104 United Kingdom 1106 Jim Hague 1107 Sinodun Internet Technologies 1108 Magdalen Centre 1109 Oxford Science Park 1110 Oxford OX4 4GA 1111 United Kingdom 1113 11. Changelog 1115 draft-ietf-dprive-bcp-op-07 1117 o Editorial changes following AD review. 1119 o Change all URIs to Informational References. 1121 draft-ietf-dprive-bcp-op-06 1123 o Final minor changes from second WGLC. 1125 draft-ietf-dprive-bcp-op-05 1127 o Remove some text on consent: 1129 * Paragraph 2 in section 5.3.3 1131 * Item 6 in the DROP Practice statement (and example) 1133 o Remove .onion and TLSA options 1135 o Include ACME as a reference for certificate management 1137 o Update text on session resumption usage 1139 o Update section 5.2.4 on client fingerprinting 1141 draft-ietf-dprive-bcp-op-04 1142 o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement 1144 o Update structure of DROP slightly 1146 o Add example DROP statement 1148 o Add text about restricting access to full logs 1150 o Move table in section 5.2.3 from SVG to inline table 1152 o Fix many editorial and reference nits 1154 draft-ietf-dprive-bcp-op-03 1156 o Add paragraph about operational impact 1158 o Move DNSSEC requirement out of the Appendix into main text as a 1159 privacy threat that should be mitigated 1161 o Add TLS version/Cipher suite as tracking threat 1163 o Add reference to Mozilla TRR policy 1165 o Remove several TODOs and QUESTIONS. 1167 draft-ietf-dprive-bcp-op-02 1169 o Change 'open resolver' for 'public resolver' 1171 o Minor editorial changes 1173 o Remove recommendation to run a separate TLS 1.3 service 1175 o Move TLSA to purely a optimisation in Section 5.2.1 1177 o Update reference on minimal DoH headers. 1179 o Add reference on user switching provider after service issues in 1180 Section 5.1.4 1182 o Add text in Section 5.1.6 on impact on operators. 1184 o Add text on additional threat to TLS proxy use (Section 5.1.7) 1186 o Add reference in Section 5.3.1 on example policies. 1188 draft-ietf-dprive-bcp-op-01 1189 o Many minor editorial fixes 1191 o Update DoH reference to RFC8484 and add more text on DoH 1193 o Split threat descriptions into ones directly referencing RFC6973 1194 and other DNS Privacy threats 1196 o Improve threat descriptions throughout 1198 o Remove reference to the DNSSEC TLS Chain Extension draft until new 1199 version submitted. 1201 o Clarify use of whitelisting for ECS 1203 o Re-structure the DPPPS, add Result filtering section. 1205 o Remove the direct inclusion of privacy policy comparison, now just 1206 reference dnsprivacy.org and an example of such work. 1208 o Add an appendix briefly discussing DNSSEC 1210 o Update affiliation of 1 author 1212 draft-ietf-dprive-bcp-op-00 1214 o Initial commit of re-named document after adoption to replace 1215 draft-dickinson-dprive-bcp-op-01 1217 12. References 1219 12.1. Normative References 1221 [I-D.ietf-dprive-rfc7626-bis] 1222 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 1223 Considerations", draft-ietf-dprive-rfc7626-bis-03 (work in 1224 progress), November 2019. 1226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1227 Requirement Levels", BCP 14, RFC 2119, 1228 DOI 10.17487/RFC2119, March 1997, . 1231 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1232 DOI 10.17487/RFC6265, April 2011, . 1235 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1236 Morris, J., Hansen, M., and R. Smith, "Privacy 1237 Considerations for Internet Protocols", RFC 6973, 1238 DOI 10.17487/RFC6973, July 2013, . 1241 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1242 "Recommendations for Secure Use of Transport Layer 1243 Security (TLS) and Datagram Transport Layer Security 1244 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1245 2015, . 1247 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1248 D. Wessels, "DNS Transport over TCP - Implementation 1249 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1250 . 1252 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1253 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1254 . 1256 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1257 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1258 DOI 10.17487/RFC7828, April 2016, . 1261 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1262 DOI 10.17487/RFC7830, May 2016, . 1265 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1266 and P. Hoffman, "Specification for DNS over Transport 1267 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1268 2016, . 1270 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1271 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1272 DOI 10.17487/RFC7871, May 2016, . 1275 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 1276 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 1277 . 1279 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1280 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1281 May 2017, . 1283 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1284 for DNS over TLS and DNS over DTLS", RFC 8310, 1285 DOI 10.17487/RFC8310, March 2018, . 1288 [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of 1289 Pervasive Encryption on Operators", RFC 8404, 1290 DOI 10.17487/RFC8404, July 2018, . 1293 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 1294 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 1295 October 2018, . 1297 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1298 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1299 . 1301 12.2. Informative References 1303 [Bloom-filter] 1304 van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L. 1305 Allodi, "Privacy-Conscious Threat Intelligence Using 1306 DNSBLOOM", 2019, 1307 . 1309 [Brenker-and-Arnes] 1310 Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS 1311 PSEUDONYMIZATION", 2005, . 1314 [Crypto-PAn] 1315 CESNET, "Crypto-PAn", 2015, 1316 . 1319 [DNS-Privacy-not-so-private] 1320 Silby, S., Juarez, M., Vallina-Rodriguez, N., and C. 1321 Troncosol, "DNS Privacy not so private: the traffic 1322 analysis perspective.", 2019, 1323 . 1325 [dnsdist] PowerDNS, "dnsdist Overview", 2019, . 1327 [dnstap] dnstap.info, "DNSTAP", 2019, . 1329 [DoH-resolver-policy] 1330 Mozilla, "Security/DOH-resolver-policy", 2019, 1331 . 1333 [Geolocation-Impact-Assessement] 1334 Conversion Works, "Anonymize IP Geolocation Accuracy 1335 Impact Assessment", 2017, 1336 . 1339 [haproxy] haproxy.org, "HAPROXY", 2019, . 1341 [Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving 1342 IP Address Anonymization", 2006, 1343 . 1345 [I-D.bellis-dnsop-xpf] 1346 Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", 1347 draft-bellis-dnsop-xpf-04 (work in progress), March 2018. 1349 [I-D.ietf-dnsop-dns-tcp-requirements] 1350 Kristoff, J. and D. Wessels, "DNS Transport over TCP - 1351 Operational Requirements", draft-ietf-dnsop-dns-tcp- 1352 requirements-05 (work in progress), November 2019. 1354 [I-D.ietf-httpbis-bcp56bis] 1355 Nottingham, M., "Building Protocols with HTTP", draft- 1356 ietf-httpbis-bcp56bis-09 (work in progress), November 1357 2019. 1359 [Internet.nl] 1360 Internet.nl, "Internet.nl Is Your Internet Up To Date?", 1361 2019, . 1363 [IP-Anonymization-in-Analytics] 1364 Google, "IP Anonymization in Analytics", 2019, 1365 . 1368 [ipcipher1] 1369 Hubert, B., "On IP address encryption: security analysis 1370 with respect for privacy", 2017, 1371 . 1374 [ipcipher2] 1375 PowerDNS, "ipcipher", 2017, . 1378 [ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption", 2015, 1379 . 1381 [ipcrypt-analysis] 1382 Aumasson, J., "Analysis of ipcrypt?", 2018, 1383 . 1386 [ISC-Knowledge-database-on-cache-snooping] 1387 ISC Knowledge Database, "DNS Cache snooping - should I be 1388 concerned?", 2018, . 1390 [nginx] nginx.org, "NGINX", 2019, . 1392 [Passive-Observations-of-a-Large-DNS] 1393 de Vries, W., van Rijswijk-Deij, R., de Boer, P., and A. 1394 Pras, "Passive Observations of a Large DNS Service: 2.5 1395 Years in the Life of Google", 2018, 1396 . 1399 [pcap] tcpdump.org, "PCAP", 2016, . 1401 [Pitfalls-of-DNS-Encryption] 1402 Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS 1403 Encryption", 2014, . 1406 [policy-comparison] 1407 dnsprivacy.org, "Comparison of policy and privacy 1408 statements 2019", 2019, 1409 . 1412 [Ramaswamy-and-Wolf] 1413 Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving 1414 IP Address Anonymization for Passive Measurement Systems", 1415 2007, 1416 . 1418 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1419 Rose, "DNS Security Introduction and Requirements", 1420 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1421 . 1423 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1424 "Transport Layer Security (TLS) Session Resumption without 1425 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1426 January 2008, . 1428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1429 Housley, R., and W. Polk, "Internet X.509 Public Key 1430 Infrastructure Certificate and Certificate Revocation List 1431 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1432 . 1434 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1435 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1436 . 1438 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1439 Known Attacks on Transport Layer Security (TLS) and 1440 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1441 February 2015, . 1443 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 1444 Servers by Running One on Loopback", RFC 7706, 1445 DOI 10.17487/RFC7706, November 2015, . 1448 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 1449 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 1450 November 2016, . 1452 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1453 Transport Layer Security (DTLS)", RFC 8094, 1454 DOI 10.17487/RFC8094, February 2017, . 1457 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 1458 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 1459 July 2017, . 1461 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1462 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1463 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1464 . 1466 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1467 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1468 January 2019, . 1470 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1471 Kasten, "Automatic Certificate Management Environment 1472 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1473 . 1475 [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., 1476 and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS 1477 Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September 1478 2019, . 1480 [SSL-Labs] 1481 SSL Labs, "SSL Server Test", 2019, 1482 . 1484 [stunnel] ISC Knowledge Database, "DNS-over-TLS", 2018, 1485 . 1487 [SURFnet-policy] 1488 SURFnet, "SURFnet Data Sharing Policy", 2016, 1489 . 1491 [TCPdpriv] 1492 Ipsilon Networks, Inc., "TCPdpriv", 2005, 1493 . 1495 [van-Dijkhuizen-et-al.] 1496 Van Dijkhuizen , N. and J. Van Der Ham, "A Survey of 1497 Network Traffic Anonymisation Techniques and 1498 Implementations", 2018, . 1500 [Xu-et-al.] 1501 Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix- 1502 preserving IP address anonymization: measurement-based 1503 security evaluation and a new cryptography-based scheme", 1504 2004, . 1507 Appendix A. Documents 1509 This section provides an overview of some DNS privacy related 1510 documents, however, this is neither an exhaustive list nor a 1511 definitive statement on the characteristic of the document. 1513 A.1. Potential increases in DNS privacy 1515 These documents are limited in scope to communications between stub 1516 clients and recursive resolvers: 1518 o 'Specification for DNS over Transport Layer Security (TLS)' 1519 [RFC7858], referred to here as 'DNS-over-TLS'. 1521 o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094], 1522 referred to here as 'DNS-over-DTLS'. Note that this document has 1523 the Category of Experimental. 1525 o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH. 1527 o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310]. 1529 o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for 1530 EDNS(0)' [RFC8467]. 1532 These documents apply to recursive to authoritative DNS but are 1533 relevant when considering the operation of a recursive server: 1535 o 'DNS Query Name minimization to Improve Privacy' [RFC7816] 1536 referred to here as 'QNAME minimization'. 1538 A.2. Potential decreases in DNS privacy 1540 These documents relate to functionality that could provide increased 1541 tracking of user activity as a side effect: 1543 o 'Client Subnet in DNS Queries' [RFC7871]. 1545 o 'Domain Name System (DNS) Cookies' [RFC7873]). 1547 o 'Transport Layer Security (TLS) Session Resumption without Server- 1548 Side State' [RFC5077] referred to here as simply TLS session 1549 resumption. 1551 o 'A DNS Packet Capture Format' [RFC8618]. 1553 o Passive DNS [RFC8499]. 1555 Note that depending on the specifics of the implementation [RFC8484] 1556 may also provide increased tracking. 1558 A.3. Related operational documents 1560 o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]. 1562 o 'Operational requirements for DNS-over-TCP' 1563 [I-D.ietf-dnsop-dns-tcp-requirements]. 1565 o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]. 1567 o 'DNS Stateful Operations' [RFC8490]. 1569 Appendix B. IP address techniques 1571 Data minimization methods may be categorized by the processing used 1572 and the properties of their outputs. The following builds on the 1573 categorization employed in [RFC6235]: 1575 o Format-preserving. Normally when encrypting, the original data 1576 length and patterns in the data should be hidden from an attacker. 1577 Some applications of de-identification, such as network capture 1578 de-identification, require that the de-identified data is of the 1579 same form as the original data, to allow the data to be parsed in 1580 the same way as the original. 1582 o Prefix preservation. Values such as IP addresses and MAC 1583 addresses contain prefix information that can be valuable in 1584 analysis, e.g. manufacturer ID in MAC addresses, subnet in IP 1585 addresses. Prefix preservation ensures that prefixes are de- 1586 identified consistently; e.g. if two IP addresses are from the 1587 same subnet, a prefix preserving de-identification will ensure 1588 that their de-identified counterparts will also share a subnet. 1589 Prefix preservation may be fixed (i.e. based on a user selected 1590 prefix length identified in advance to be preserved ) or general. 1592 o Replacement. A one-to-one replacement of a field to a new value 1593 of the same type, for example using a regular expression. 1595 o Filtering. Removing (and thus truncating) or replacing data in a 1596 field. Field data can be overwritten, often with zeros, either 1597 partially (grey marking) or completely (black marking). 1599 o Generalization. Data is replaced by more general data with 1600 reduced specificity. One example would be to replace all TCP/UDP 1601 port numbers with one of two fixed values indicating whether the 1602 original port was ephemeral (>=1024) or non-ephemeral (>1024). 1603 Another example, precision degradation, reduces the accuracy of 1604 e.g. a numeric value or a timestamp. 1606 o Enumeration. With data from a well-ordered set, replace the first 1607 data item data using a random initial value and then allocate 1608 ordered values for subsequent data items. When used with 1609 timestamp data, this preserves ordering but loses precision and 1610 distance. 1612 o Reordering/shuffling. Preserving the original data, but 1613 rearranging its order, often in a random manner. 1615 o Random substitution. As replacement, but using randomly generated 1616 replacement values. 1618 o Cryptographic permutation. Using a permutation function, such as 1619 a hash function or cryptographic block cipher, to generate a 1620 replacement de-identified value. 1622 B.1. Google Analytics non-prefix filtering 1624 Since May 2010, Google Analytics has provided a facility 1625 [IP-Anonymization-in-Analytics] that allows website owners to request 1626 that all their users IP addresses are anonymized within Google 1627 Analytics processing. This very basic anonymization simply sets to 1628 zero the least significant 8 bits of IPv4 addresses, and the least 1629 significant 80 bits of IPv6 addresses. The level of anonymization 1630 this produces is perhaps questionable. There are some analysis 1631 results [Geolocation-Impact-Assessement] which suggest that the 1632 impact of this on reducing the accuracy of determining the user's 1633 location from their IP address is less than might be hoped; the 1634 average discrepancy in identification of the user city for UK users 1635 is no more than 17%. 1637 Anonymization: Format-preserving, Filtering (grey marking). 1639 B.2. dnswasher 1641 Since 2006, PowerDNS have included a de-identification tool 1642 Appendix B.2 with their PowerDNS product. This is a PCAP filter that 1643 performs a one-to-one mapping of end user IP addresses with an 1644 anonymized address. A table of user IP addresses and their de- 1645 identified counterparts is kept; the first IPv4 user addresses is 1646 translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de- 1647 identified address therefore depends on the order that addresses 1648 arrive in the input, and running over a large amount of data the 1649 address translation tables can grow to a significant size. 1651 Anonymization: Format-preserving, Enumeration. 1653 B.3. Prefix-preserving map 1655 Used in [TCPdpriv], this algorithm stores a set of original and 1656 anonymised IP address pairs. When a new IP address arrives, it is 1657 compared with previous addresses to determine the longest prefix 1658 match. The new address is anonymized by using the same prefix, with 1659 the remainder of the address anonymized with a random value. The use 1660 of a random value means that TCPdrpiv is not deterministic; different 1661 anonymized values will be generated on each run. The need to store 1662 previous addresses means that TCPdpriv has significant and unbounded 1663 memory requirements, and because of the need to allocated anonymized 1664 addresses sequentially cannot be used in parallel processing. 1666 Anonymization: Format-preserving, prefix preservation (general). 1668 B.4. Cryptographic Prefix-Preserving Pseudonymisation 1670 Cryptographic prefix-preserving pseudonymisation was originally 1671 proposed as an improvement to the prefix-preserving map implemented 1672 in TCPdpriv, described in [Xu-et-al.] and implemented in the 1673 [Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym 1674 for the algorithm. Initially it was described for IPv4 addresses 1675 only; extension for IPv6 addresses was proposed in [Harvan]. This 1676 uses a cryptographic algorithm rather than a random value, and thus 1677 pseudonymity is determined uniquely by the encryption key, and is 1678 deterministic. It requires a separate AES encryption for each output 1679 bit, so has a non-trivial calculation overhead. This can be 1680 mitigated to some extent (for IPv4, at least) by pre-calculating 1681 results for some number of prefix bits. 1683 Pseudonymization: Format-preserving, prefix preservation (general). 1685 B.5. Top-hash Subtree-replicated Anonymisation 1687 Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated 1688 Anonymisation (TSA) originated in response to the requirement for 1689 faster processing than Crypto-PAn. It used hashing for the most 1690 significant byte of an IPv4 address, and a pre-calculated binary tree 1691 structure for the remainder of the address. To save memory space, 1692 replication is used within the tree structure, reducing the size of 1693 the pre-calculated structures to a few Mb for IPv4 addresses. 1694 Address pseudonymization is done via hash and table lookup, and so 1695 requires minimal computation. However, due to the much increased 1696 address space for IPv6, TSA is not memory efficient for IPv6. 1698 Pseudonymization: Format-preserving, prefix preservation (general). 1700 B.6. ipcipher 1702 A recently-released proposal from PowerDNS, ipcipher [ipcipher1] 1703 [ipcipher2] is a simple pseudonymization technique for IPv4 and IPv6 1704 addresses. IPv6 addresses are encrypted directly with AES-128 using 1705 a key (which may be derived from a passphrase). IPv4 addresses are 1706 similarly encrypted, but using a recently proposed encryption 1707 [ipcrypt] suitable for 32bit block lengths. However, the author of 1708 ipcrypt has since indicated [ipcrypt-analysis] that it has low 1709 security, and further analysis has revealed it is vulnerable to 1710 attack. 1712 Pseudonymization: Format-preserving, cryptographic permutation. 1714 B.7. Bloom filters 1716 van Rijswijk-Deij et al. have recently described work using Bloom 1717 filters [Bloom-filter] to categorize query traffic and record the 1718 traffic as the state of multiple filters. The goal of this work is 1719 to allow operators to identify so-called Indicators of Compromise 1720 (IOCs) originating from specific subnets without storing information 1721 about, or be able to monitor the DNS queries of an individual user. 1722 By using a Bloom filter, it is possible to determine with a high 1723 probability if, for example, a particular query was made, but the set 1724 of queries made cannot be recovered from the filter. Similarly, by 1725 mixing queries from a sufficient number of users in a single filter, 1726 it becomes practically impossible to determine if a particular user 1727 performed a particular query. Large numbers of queries can be 1728 tracked in a memory-efficient way. As filter status is stored, this 1729 approach cannot be used to regenerate traffic, and so cannot be used 1730 with tools used to process live traffic. 1732 Anonymized: Generalization. 1734 Appendix C. Example DROP statement 1736 The following example DROP statement is very loosely based on some 1737 elements of published privacy statements for some public resolvers, 1738 with additional fields populated to illustrate the what the full 1739 contents of a DROP statement might look like. This should not be 1740 interpreted as 1742 o having been reviewed or approved by any operator in any way 1744 o having any legal standing or validity at all 1746 o being complete or exhaustive 1748 This is a purely hypothetical example of a DROP statement to outline 1749 example contents - in this case for a public resolver operator 1750 providing a basic DNS Privacy service via one IP address and one DoH 1751 URI with security based filtering. It does aim to meet minimal 1752 compliance as specified in Section 5. 1754 C.1. Policy 1756 1. Treatment of IP addresses. Many nations classify IP addresses as 1757 Personally-Identifiable Information (PII), and we take a 1758 conservative approach in treating IP addresses as PII in all 1759 jurisdictions in which our systems reside. 1761 2. Data collection and sharing. 1763 1. IP addresses. Our normal course of data management does not 1764 have any IP address information or other PII logged to disk 1765 or transmitted out of the location in which the query was 1766 received. We may aggregate certain counters to larger 1767 network block levels for statistical collection purposes, but 1768 those counters do not maintain specific IP address data nor 1769 is the format or model of data stored capable of being 1770 reverse-engineered to ascertain what specific IP addresses 1771 made what queries. 1773 2. Data collected in logs. We do keep some generalized location 1774 information (at the city/metropolitan area level) so that we 1775 can conduct debugging and analyze abuse phenomena. We also 1776 use the collected information for the creation and sharing of 1777 telemetry (timestamp, geolocation, number of hits, first 1778 seen, last seen) for contributors, public publishing of 1779 general statistics of use of system (protections, threat 1780 types, counts, etc.) When you use our DNS Services, here is 1781 the full list of items that are 1782 included in our logs: 1784 + Request domain name, e.g. example.net 1786 + Record type of requested domain, e.g. A, AAAA, NS, MX, 1787 TXT, etc. 1789 + Transport protocol on which the request arrived, i.e. UDP, 1790 TCP, DoT, 1791 DoH 1793 + Origin IP general geolocation information: i.e. geocode, 1794 region ID, city ID, and metro code 1796 + IP protocol version - IPv4 or IPv6 1798 + Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, 1799 etc. 1801 + Absolute arrival time 1803 + Name of the specific instance that processed this request 1805 + IP address of the specific instance to which this request 1806 was addressed (no relation to the requestor's IP address) 1808 We may keep the following data as summary information, 1809 including all the above EXCEPT for data about the DNS record 1810 requested: 1812 + Currently-advertised BGP-summarized IP prefix/netmask of 1813 apparent client origin 1815 + Autonomous system number (BGP ASN) of apparent client 1816 origin 1818 All the above data may be kept in full or partial form in 1819 permanent archives. 1821 3. Sharing of data. Except as described in this document, we do 1822 not intentionally share, sell, or rent individual personal 1823 information associated with the requestor (i.e. source IP 1824 address or any other information that can positively identify 1825 the client using our infrastructure) with anyone without your 1826 consent. We generate and share high level anonymized 1827 aggregate statistics including threat metrics on threat type, 1828 geolocation, and if available, sector, as well as other 1829 vertical metrics including performance metrics on our DNS 1830 Services (i.e. number of threats blocked, infrastructure 1831 uptime) when available with the our threat intelligence (TI) 1832 partners, academic researchers, or the public. Our DNS 1833 Services share anonymized data on specific domains queried 1834 (records such as domain, timestamp, geolocation, number of 1835 hits, first seen, last seen) with its threat intelligence 1836 partners. Our DNS Services also builds, stores, and may 1837 share certain DNS data streams which store high level 1838 information about domain resolved, query types, result codes, 1839 and timestamp. These streams do not contain IP address 1840 information of requestor and cannot be correlated to IP 1841 address or other PII. We do not and never will share any of 1842 its data with marketers, nor will it use this data for 1843 demographic analysis. 1845 3. Exceptions. There are exceptions to this storage model: In the 1846 event of events or observed behaviors which we deem malicious or 1847 anomalous, we may utilize more detailed logging to collect more 1848 specific IP address data in the process of normal network defence 1849 and mitigation. This collection and transmission off-site will 1850 be limited to IP addresses that we determine are involved in the 1851 event. 1853 4. Associated entities. Details of our Threat Intelligence partners 1854 can be found at our website page (insert link). 1856 5. Correlation of Data. We do not correlate or combine information 1857 from our logs with any personal information that you have 1858 provided us for other services, or with your specific IP address. 1860 6. Result filtering. 1862 1. Filtering. We utilise cyber threat intelligence about 1863 malicious domains from a variety of public and private 1864 sources and blocks access to those malicious domains when 1865 your system attempts to contact them. An NXDOMAIN is 1866 returned for blocked sites. 1868 1. Censorship. We will not provide a censoring component 1869 and will limit our actions solely to the blocking of 1870 malicious domains around phishing, malware, and exploit 1871 kit domains. 1873 2. Accidental blocking. We implement whitelisting 1874 algorithms to make sure legitimate domains are not 1875 blocked by accident. However, in the rare case of 1876 blocking a legitimate domain, we work with the users to 1877 quickly whitelist that domain. Please use our support 1878 form (insert link) if you believe we are blocking a 1879 domain in error. 1881 C.2. Practice 1883 1. Deviations from Policy. None currently in place. 1885 2. Client facing capabilities. 1887 1. We offer UDP and TCP DNS on port 53 on (insert IP address) 1889 2. We offer DNS-over-TLS as specified in RFC7858 on (insert IP 1890 address). It is available on port 853 and port 443. We also 1891 implement RFC7766. 1893 1. The DoT authentication name used is (insert domain name). 1895 2. We do not publish SPKI pin sets. 1897 3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert 1898 URI template). Both POST and GET are supported. 1900 4. Both services offer TLS 1.2 and TLS 1.3. 1902 5. Both services pad DNS responses according to RFC8467. 1904 6. Both services provide DNSSEC validation. 1906 3. Upstream capabilities. 1908 1. Our servers implement QNAME minimisation. 1910 2. Our servers do not send ECS upstream. 1912 4. Support. Support information for this service is available at 1913 (insert link). 1915 5. Jurisdiction. 1917 1. We operate as the legal entity (insert entity) registered in 1918 (insert country) as (insert company identifier e.g Company 1919 Number). Our Headquarters are located at (insert address). 1921 2. As such we operate under (insert country) law. For details 1922 of our company privacy policy see (insert link). For 1923 questions on this policy and enforcement contact our Data 1924 Protection Officer on (insert email address). 1926 3. We operate servers in the following countries (insert list). 1928 4. We have no agreements in place with law enforcement agencies 1929 to give them access to the data. Apart from as stated in the 1930 Policy section of this document with regard to cyber threat 1931 intelligence, we have no agreements in place with other 1932 public and private parties dealing with security and 1933 intelligence, to give them access to the servers and/or to 1934 the data. 1936 Authors' Addresses 1938 Sara Dickinson 1939 Sinodun IT 1940 Magdalen Centre 1941 Oxford Science Park 1942 Oxford OX4 4GA 1943 United Kingdom 1945 Email: sara@sinodun.com 1946 Benno J. Overeinder 1947 NLnet Labs 1948 Science Park 400 1949 Amsterdam 1098 XH 1950 The Netherlands 1952 Email: benno@nlnetLabs.nl 1954 Roland M. van Rijswijk-Deij 1955 NLnet Labs 1956 Science Park 400 1957 Amsterdam 1098 XH 1958 The Netherlands 1960 Email: roland@nlnetLabs.nl 1962 Allison Mankin 1963 Salesforce 1965 Email: allison.mankin@gmail.com