< draft-ietf-dprive-bcp-op-02.txt   draft-ietf-dprive-bcp-op-03.txt >
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun IT Internet-Draft Sinodun IT
Intended status: Best Current Practice B. Overeinder Intended status: Best Current Practice B. Overeinder
Expires: September 12, 2019 R. van Rijswijk-Deij Expires: January 9, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
March 11, 2019 July 8, 2019
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-02 draft-ietf-dprive-bcp-op-03
Abstract Abstract
This document presents operational, policy and security This document presents operational, policy and security
considerations for DNS operators who choose to offer DNS Privacy considerations for DNS operators who choose to offer DNS Privacy
services. With these recommendations, the operator can make services. With these recommendations, the operator can make
deliberate decisions regarding which services to provide, and how the deliberate decisions regarding which services to provide, and how the
decisions and alternatives impact the privacy of users. decisions and alternatives impact the privacy of users.
This document also presents a framework to assist writers of DNS This document also presents a framework to assist writers of DNS
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Privacy related documents . . . . . . . . . . . . . . . . . . 5 3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Recommendations for DNS privacy services . . . . . . . . . . 6 5. Recommendations for DNS privacy services . . . . . . . . . . 6
5.1. On the wire between client and server . . . . . . . . . . 7 5.1. On the wire between client and server . . . . . . . . . . 7
5.1.1. Transport recommendations . . . . . . . . . . . . . . 7 5.1.1. Transport recommendations . . . . . . . . . . . . . . 7
5.1.2. Authentication of DNS privacy services . . . . . . . 7 5.1.2. Authentication of DNS privacy services . . . . . . . 8
5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
5.1.4. Availability . . . . . . . . . . . . . . . . . . . . 10 5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.5. Service options . . . . . . . . . . . . . . . . . . . 11 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11
5.1.6. Impact on Operators . . . . . . . . . . . . . . . . . 11 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
5.1.7. Limitations of using a pure TLS proxy . . . . . . . . 12 5.1.7. Impact on Operators . . . . . . . . . . . . . . . . . 12
5.2. Data at rest on the server . . . . . . . . . . . . . . . 12 5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 12 5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
5.2.2. Data minimization of network traffic . . . . . . . . 13 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
5.2.3. IP address pseudonymization and anonymization methods 14 5.2.2. Data minimization of network traffic . . . . . . . . 14
5.2.3. IP address pseudonymization and anonymization methods 15
5.2.4. Pseudonymization, anonymization or discarding of 5.2.4. Pseudonymization, anonymization or discarding of
other correlation data . . . . . . . . . . . . . . . 15 other correlation data . . . . . . . . . . . . . . . 16
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 16 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 16 5.3. Data sent onwards from the server . . . . . . . . . . . . 17
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 16 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 17 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 18 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
6. DNS privacy policy and practice statement . . . . . . . . . . 19 6. DNS privacy policy and practice statement . . . . . . . . . . 19
6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 19 6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 20
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 19 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Current policy and privacy statements . . . . . . . . . . 21 6.2. Current policy and privacy statements . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 21 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 22
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 22 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 30
A.1. Potential increases in DNS privacy . . . . . . . . . . . 29 A.1. Potential increases in DNS privacy . . . . . . . . . . . 30
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 29 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 30
A.3. Related operational documents . . . . . . . . . . . . . . 30 A.3. Related operational documents . . . . . . . . . . . . . . 31
Appendix B. Encryption and DNSSEC . . . . . . . . . . . . . . . 30 Appendix B. IP address techniques . . . . . . . . . . . . . . . 31
Appendix C. IP address techniques . . . . . . . . . . . . . . . 30 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 32
C.1. Google Analytics non-prefix filtering . . . . . . . . . . 31 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33
C.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 32 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 33
C.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 32 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 33
C.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 32 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34
C.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 33 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 34
C.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 33 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 34
C.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The Domain Name System (DNS) is at the core of the Internet; almost The Domain Name System (DNS) is at the core of the Internet; almost
every activity on the Internet starts with a DNS query (and often every activity on the Internet starts with a DNS query (and often
several). However the DNS was not originally designed with strong several). However the DNS was not originally designed with strong
security or privacy mechanisms. A number of developments have taken security or privacy mechanisms. A number of developments have taken
place in recent years which aim to increase the privacy of the DNS place in recent years which aim to increase the privacy of the DNS
system and these are now seeing some deployment. This latest system and these are now seeing some deployment. This latest
evolution of the DNS presents new challenges to operators and this evolution of the DNS presents new challenges to operators and this
skipping to change at page 4, line 41 skipping to change at page 4, line 41
and present a framework to assist writers of this document. A and present a framework to assist writers of this document. A
DPPPS is a document that an operator can publish outlining their DPPPS is a document that an operator can publish outlining their
operational practices and commitments with regard to privacy operational practices and commitments with regard to privacy
thereby providing a means for clients to evaluate the privacy thereby providing a means for clients to evaluate the privacy
properties of a given DNS privacy service. In particular, the properties of a given DNS privacy service. In particular, the
framework identifies the elements that should be considered in framework identifies the elements that should be considered in
formulating a DPPPS. This document does not, however, define a formulating a DPPPS. This document does not, however, define a
particular Policy or Practice Statement, nor does it seek to particular Policy or Practice Statement, nor does it seek to
provide legal advice or recommendations as to the contents. provide legal advice or recommendations as to the contents.
A desired operational impact is that all operators (both those
providing resolvers within networks and those operating large anycast
services) can demonstrate their commitment to user privacy thereby
driving all DNS resolution services to a more equitable footing.
Choices for users would (in this ideal world) be driven by other
factors e.g. differing security policies or minor difference in
operator policy rather than gross disparities in privacy concerns.
Community insight [or judgment?] about operational practices can Community insight [or judgment?] about operational practices can
change quickly, and experience shows that a Best Current Practice change quickly, and experience shows that a Best Current Practice
(BCP) document about privacy and security is a point-in-time (BCP) document about privacy and security is a point-in-time
statement. Readers are advised to seek out any errata or updates statement. Readers are advised to seek out any errata or updates
that apply to this document. that apply to this document.
2. Scope 2. Scope
"DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis] "DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis]
describes the general privacy issues and threats associated with the describes the general privacy issues and threats associated with the
skipping to change at page 7, line 42 skipping to change at page 7, line 52
It is noted that a DNS privacy service can also be provided over DNS- It is noted that a DNS privacy service can also be provided over DNS-
over-DTLS [RFC8094], however this is an Experimental specification over-DTLS [RFC8094], however this is an Experimental specification
and there are no known implementations at the time of writing. and there are no known implementations at the time of writing.
It is also noted that DNS privacy service might be provided over It is also noted that DNS privacy service might be provided over
IPSec, DNSCrypt or VPNs. However, use of these transports for DNS IPSec, DNSCrypt or VPNs. However, use of these transports for DNS
are not standardized and any discussion of best practice for are not standardized and any discussion of best practice for
providing such a service is out of scope for this document. providing such a service is out of scope for this document.
Whilst encryption of DNS traffic can protect against active injection Whilst encryption of DNS traffic can protect against active injection
this does not diminish the need for DNSSEC, see Appendix B. this does not diminish the need for DNSSEC, see Section 5.1.4.
5.1.2. Authentication of DNS privacy services 5.1.2. Authentication of DNS privacy services
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Active attacks that can redirect traffic to rogue servers * Active attacks that can redirect traffic to rogue servers
[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3. [I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3.
skipping to change at page 10, line 47 skipping to change at page 11, line 9
Mitigations: Mitigations:
o Clients must be able to forego the use of HTTP Cookies [RFC6265] o Clients must be able to forego the use of HTTP Cookies [RFC6265]
and still use the service and still use the service
o Clients should not be required to include any headers beyond the o Clients should not be required to include any headers beyond the
absolute minimum to obtain service from a DoH server. (See absolute minimum to obtain service from a DoH server. (See
Section 6.1 of [I-D.ietf-httpbis-bcp56bis].) Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)
5.1.4. Availability 5.1.4. DNSSEC
DNS Privacy Threats:
o Users may be directed to bogus IP addresses for e.g. websites
where they might reveal personal information to attackers.
Mitigations:
o All DNS privacy services must offer a DNS privacy service that
performs DNSSEC validation. In addition they must be able to
provide the DNSSEC RRs to the client so that it can perform its
own validation.
The addition of encryption to DNS does not remove the need for DNSSEC
[RFC4033] - they are independent and fully compatible protocols, each
solving different problems. The use of one does not diminish the
need nor the usefulness of the other.
While the use of an authenticated and encrypted transport protects
origin authentication and data integrity between a client and a DNS
privacy service it provides no proof (for a non-validating client)
that the data provided by the DNS privacy service was actually DNSSEC
authenticated. As with cleartext DNS the user is still solely
trusting the AD bit (if present) set by the resolver.
It should also be noted that the use of an encrypted transport for
DNS actually solves many of the practical issues encountered by DNS
validating clients e.g. interference by middleboxes with cleartext
DNS payloads is completely avoided. In this sense a validating
client that uses a DNS privacy service which supports DNSSEC has a
far simpler task in terms of DNS Roadblock avoidance.
5.1.5. Availability
DNS Privacy Threats: DNS Privacy Threats:
o A failed DNS privacy service could force the user to switch o A failed DNS privacy service could force the user to switch
providers, fallback to cleartext or accept no DNS service for the providers, fallback to cleartext or accept no DNS service for the
outage. outage.
Mitigations: Mitigations:
A DNS privacy service must be engineered for high availability. A DNS privacy service must be engineered for high availability.
Particular care should to be taken to protect DNS privacy services Particular care should to be taken to protect DNS privacy services
against denial-of-service attacks, as experience has shown that against denial-of-service attacks, as experience has shown that
unavailability of DNS resolving because of attacks is a significant unavailability of DNS resolving because of attacks is a significant
motivation for users to switch services. See, for example motivation for users to switch services. See, for example
Section IV-C of Passive Observations of a Large DNS Service: 2.5 Section IV-C of Passive Observations of a Large DNS Service: 2.5
Years in the Life of Google [3]. Years in the Life of Google [3].
5.1.5. Service options Techniques such as those described in Section 10 of [RFC7766] can be
of use to operators to defend against such attacks.
5.1.6. Service options
DNS Privacy Threats: DNS Privacy Threats:
o Unfairly disadvantaging users of the privacy service with respect o Unfairly disadvantaging users of the privacy service with respect
to the services available. This could force the user to switch to the services available. This could force the user to switch
providers, fallback to cleartext or accept no DNS service for the providers, fallback to cleartext or accept no DNS service for the
outage. outage.
Mitigations: Mitigations:
A DNS privacy service should deliver the same level of service as A DNS privacy service should deliver the same level of service as
offered on un-encrypted channels in terms of such options as offered on un-encrypted channels in terms of such options as
filtering (or lack thereof), DNSSEC validation, etc. filtering (or lack thereof), DNSSEC validation, etc.
5.1.6. Impact on Operators 5.1.7. Impact on Operators
DNS Privacy Threats: DNS Privacy Threats:
o Increased use of encryption impacts operator ability to manage o Increased use of encryption impacts operator ability to manage
their network [RFC8404] their network [RFC8404]
Many monitoring solutions for DNS traffic rely on the plain text Many monitoring solutions for DNS traffic rely on the plain text
nature of this traffic and work by intercepting traffic on the wire, nature of this traffic and work by intercepting traffic on the wire,
either using a separate view on the connection between clients and either using a separate view on the connection between clients and
the resolver, or as a separate process on the resolver system that the resolver, or as a separate process on the resolver system that
skipping to change at page 12, line 12 skipping to change at page 13, line 10
relies on either the resolver software directly, or exporting DNS relies on either the resolver software directly, or exporting DNS
traffic from the resolver using e.g. dnstap [4]. traffic from the resolver using e.g. dnstap [4].
Optimization: Optimization:
When implementing alternative means for traffic monitoring, operators When implementing alternative means for traffic monitoring, operators
of a DNS privacy service should consider using privacy conscious of a DNS privacy service should consider using privacy conscious
means to do so (see, for example, the discussion on the use of Bloom means to do so (see, for example, the discussion on the use of Bloom
Filters in the #documents appendix in this document). Filters in the #documents appendix in this document).
5.1.7. Limitations of using a pure TLS proxy 5.1.8. Limitations of using a pure TLS proxy
DNS Privacy Threats: DNS Privacy Threats:
o Limited ability to manage or monitor incoming connections using o Limited ability to manage or monitor incoming connections using
DNS specific techniques DNS specific techniques
o Misconfiguration of the target server could lead to data leakage o Misconfiguration of the target server could lead to data leakage
if the proxy to target server path is not encrypted. if the proxy to target server path is not encrypted.
Optimization: Optimization:
skipping to change at page 13, line 4 skipping to change at page 13, line 50
5.2. Data at rest on the server 5.2. Data at rest on the server
5.2.1. Data handling 5.2.1. Data handling
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance o Surveillance
o Stored data compromise o Stored data compromise
o Correlation
o Correlation
o Identification o Identification
o Secondary use o Secondary use
o Disclosure o Disclosure
Other Threats Other Threats
o Contravention of legal requirements not to process user data? o Contravention of legal requirements not to process user data?
skipping to change at page 15, line 14 skipping to change at page 16, line 14
There is active discussion in the space of effective pseudonymization There is active discussion in the space of effective pseudonymization
of IP addresses in DNS traffic logs, however there seems to be no of IP addresses in DNS traffic logs, however there seems to be no
single solution that is widely recognized as suitable for all or most single solution that is widely recognized as suitable for all or most
use cases. There are also as yet no standards for this that are use cases. There are also as yet no standards for this that are
unencumbered by patents. The following table presents a high level unencumbered by patents. The following table presents a high level
comparison of various techniques employed or under development today comparison of various techniques employed or under development today
and classifies them according to categorization of technique and and classifies them according to categorization of technique and
other properties. The list of techniques includes the main other properties. The list of techniques includes the main
techniques in current use, but does not claim to be comprehensive. techniques in current use, but does not claim to be comprehensive.
Appendix C provides a more detailed survey of these techniques and Appendix B provides a more detailed survey of these techniques and
definitions for the categories and properties listed below. definitions for the categories and properties listed below.
Figure showing comparison of IP address techniques (SVG) [10] Figure showing comparison of IP address techniques (SVG) [10]
The choice of which method to use for a particular application will The choice of which method to use for a particular application will
depend on the requirements of that application and consideration of depend on the requirements of that application and consideration of
the threat analysis of the particular situation. the threat analysis of the particular situation.
For example, a common goal is that distributed packet captures must For example, a common goal is that distributed packet captures must
be in an existing data format such as PCAP [pcap] or C-DNS be in an existing data format such as PCAP [pcap] or C-DNS
skipping to change at page 15, line 43 skipping to change at page 16, line 43
preserving pseudonymization is vulnerable to an attack along the preserving pseudonymization is vulnerable to an attack along the
lines of a cryptographic chosen plaintext attack. lines of a cryptographic chosen plaintext attack.
5.2.4. Pseudonymization, anonymization or discarding of other 5.2.4. Pseudonymization, anonymization or discarding of other
correlation data correlation data
DNS Privacy Threats: DNS Privacy Threats:
o IP TTL/Hoplimit can be used to fingerprint client OS o IP TTL/Hoplimit can be used to fingerprint client OS
o TLS version/Cipher suite combinations can be used to fingerprint
the client application or TLS library
o Tracking of TCP sessions o Tracking of TCP sessions
o Tracking of TLS sessions and session resumption mechanisms o Tracking of TLS sessions and session resumption mechanisms
o Resolvers _might_ receive client identifiers e.g. MAC addresses o Resolvers _might_ receive client identifiers e.g. MAC addresses
in EDNS(0) options - some CPE devices are known to add them. in EDNS(0) options - some CPE devices are known to add them.
o HTTP headers o HTTP headers
Mitigations: Mitigations:
o Data minimization or discarding of such correlation data o Data minimization or discarding of such correlation data.
TODO: More analysis here.
5.2.5. Cache snooping 5.2.5. Cache snooping
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Profiling of client queries by malicious third parties * Profiling of client queries by malicious third parties
Mitigations: Mitigations:
o See ISC Knowledge database on cache snooping [12] for an example o See ISC Knowledge database on cache snooping [12] for an example
discussion on defending against cache snooping discussion on defending against cache snooping
TODO: Describe other techniques to defend against cache snooping
5.3. Data sent onwards from the server 5.3. Data sent onwards from the server
In this section we consider both data sent on the wire in upstream In this section we consider both data sent on the wire in upstream
queries and data shared with third parties. queries and data shared with third parties.
5.3.1. Protocol recommendations 5.3.1. Protocol recommendations
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
skipping to change at page 18, line 26 skipping to change at page 19, line 26
o Correlation o Correlation
o Identification o Identification
o Secondary use o Secondary use
o Disclosure o Disclosure
DNS Privacy Threats: DNS Privacy Threats:
o Contravention of legal requirements not to process user data? o Contravention of legal requirements not to process user data
Mitigations: Mitigations:
Operators should not provide identifiable data to third-parties Operators should not provide identifiable data to third-parties
without explicit consent from clients (we take the stance here that without explicit consent from clients (we take the stance here that
simply using the resolution service itself does not constitute simply using the resolution service itself does not constitute
consent). consent).
Even when consent is granted operators should employ data Even when consent is granted operators should employ data
minimization techniques such as those described in Section 5.2.1 if minimization techniques such as those described in Section 5.2.1 if
data is shared with third-parties. data is shared with third-parties.
Operators should consider including specific guidelines for the Operators should consider including specific guidelines for the
collection of aggregated and/or anonymized data for research collection of aggregated and/or anonymized data for research
purposes, within or outside of their own organization. See SURFnet's purposes, within or outside of their own organization. This can
policy [13] on data sharing for research as an example. benefit not only the operator (through inclusion in novel research)
but also the wider Internet community. See SURFnet's policy [13] on
TODO: More on data for research vs operations... how to still data sharing for research as an example.
motivate operators to share anonymized data?
TODO: Guidelines for when consent is granted?
TODO: Applies to server data handling too.. could operators offer
alternatives services one that implies consent for data processing,
one that doesn't?
6. DNS privacy policy and practice statement 6. DNS privacy policy and practice statement
6.1. Recommended contents of a DPPPS 6.1. Recommended contents of a DPPPS
6.1.1. Policy 6.1.1. Policy
1. Make an explicit statement that IP addressses are treated as PII 1. Make an explicit statement that IP addressses are treated as PII
2. State if IP addresses are being logged 2. State if IP addresses are being logged
3. Specify clearly what data (including whether it is aggregated, 3. Specify clearly what data (including whether it is aggregated,
pseudonymized or anonymized and the conditions of data transfer) pseudonymized or anonymized and the conditions of data transfer)
skipping to change at page 21, line 32 skipping to change at page 22, line 27
A tabular comparison of existing policy and privacy statements from A tabular comparison of existing policy and privacy statements from
various DNS Privacy service operators based on the proposed DPPPS various DNS Privacy service operators based on the proposed DPPPS
structure can be found on dnsprivacy.org [14]. structure can be found on dnsprivacy.org [14].
We note that the existing set of policies vary widely in style, We note that the existing set of policies vary widely in style,
content and detail and it is not uncommon for the full text for a content and detail and it is not uncommon for the full text for a
given operator to equate to more than 10 pages of moderate font sized given operator to equate to more than 10 pages of moderate font sized
A4 text. It is a non-trivial task today for a user to extract a A4 text. It is a non-trivial task today for a user to extract a
meaningful overview of the different services on offer. meaningful overview of the different services on offer.
It is also noted that Mozilla have published a Security/DoH-resolver
policy [15], which describes the minimum set of policy requirements
that a party must satisfy to be considered as a potential partner for
Mozilla's Trusted Recursive Resolver (TRR) program.
6.3. Enforcement/accountability 6.3. Enforcement/accountability
Transparency reports may help with building user trust that operators Transparency reports may help with building user trust that operators
adhere to their policies and practices. adhere to their policies and practices.
Independent monitoring or analysis could be performed where possible Independent monitoring or analysis could be performed where possible
of: of:
o ECS, QNAME minimization, EDNS(0) padding, etc. o ECS, QNAME minimization, EDNS(0) padding, etc.
o Filtering o Filtering
o Uptime o Uptime
This is by analogy with e.g. several TLS or website analysis tools This is by analogy with e.g. several TLS or website analysis tools
that are currently available e.g. SSL Labs [15] or Internet.nl [16]. that are currently available e.g. SSL Labs [16] or Internet.nl [17].
Additionally operators could choose to engage the services of a third Additionally operators could choose to engage the services of a third
party auditor to verify their compliance with their published DPPPS. party auditor to verify their compliance with their published DPPPS.
7. IANA considerations 7. IANA considerations
None None
8. Security considerations 8. Security considerations
skipping to change at page 22, line 48 skipping to change at page 23, line 48
Jim Hague Jim Hague
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
11. Changelog 11. Changelog
draft-ietf-dprive-bcp-op-03
o Add paragraph about operational impact
o Move DNSSEC requirement out of the Appendix into main text as a
privacy threat that should be mitigated
o Add TLS version/Cipher suite as tracking threat
o Add reference to Mozilla TRR policy
o Remove several TODOs and QUESTIONS.
draft-ietf-dprive-bcp-op-02 draft-ietf-dprive-bcp-op-02
o Change 'open resolver' for 'public resolver' o Change 'open resolver' for 'public resolver'
o Minor editorial changes o Minor editorial changes
o Remove recommendation to run a separate TLS 1.3 service o Remove recommendation to run a separate TLS 1.3 service
o Move TLSA to purely a optimisation in Section 5.2.1 o Move TLSA to purely a optimisation in Section 5.2.1
o Update reference on minimal DoH headers. o Update reference on minimal DoH headers.
o Add reference on user switching provider after service issues in o Add reference on user switching provider after service issues in
Section 5.1.4 Section 5.1.4
o Add text in Section 5.1.6 on impact on operators. o Add text in Section 5.1.6 on impact on operators.
skipping to change at page 26, line 25 skipping to change at page 27, line 33
[I-D.ietf-dnsop-dns-capture-format] [I-D.ietf-dnsop-dns-capture-format]
Dickinson, J., Hague, J., Dickinson, S., Manderson, T., Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "C-DNS: A DNS Packet Capture Format", draft- and J. Bond, "C-DNS: A DNS Packet Capture Format", draft-
ietf-dnsop-dns-capture-format-10 (work in progress), ietf-dnsop-dns-capture-format-10 (work in progress),
December 2018. December 2018.
[I-D.ietf-dnsop-dns-tcp-requirements] [I-D.ietf-dnsop-dns-tcp-requirements]
Kristoff, J. and D. Wessels, "DNS Transport over TCP - Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", draft-ietf-dnsop-dns-tcp- Operational Requirements", draft-ietf-dnsop-dns-tcp-
requirements-03 (work in progress), January 2019. requirements-04 (work in progress), June 2019.
[I-D.ietf-dnsop-terminology-bis] [I-D.ietf-dnsop-terminology-bis]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-terminology-bis-14 (work in Terminology", draft-ietf-dnsop-terminology-bis-14 (work in
progress), September 2018. progress), September 2018.
[I-D.ietf-httpbis-bcp56bis] [I-D.ietf-httpbis-bcp56bis]
Nottingham, M., "Building Protocols with HTTP", draft- Nottingham, M., "Building Protocols with HTTP", draft-
ietf-httpbis-bcp56bis-08 (work in progress), November ietf-httpbis-bcp56bis-08 (work in progress), November
2018. 2018.
skipping to change at page 28, line 20 skipping to change at page 29, line 28
[11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16 [11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16
4fb2138a44.pdf 4fb2138a44.pdf
[12] https://kb.isc.org/docs/aa-00482 [12] https://kb.isc.org/docs/aa-00482
[13] https://surf.nl/datasharing [13] https://surf.nl/datasharing
[14] https://dnsprivacy.org/wiki/display/DP/ [14] https://dnsprivacy.org/wiki/display/DP/
Comparison+of+policy+and+privacy+statements Comparison+of+policy+and+privacy+statements
[15] https://www.ssllabs.com/ssltest/ [15] https://wiki.mozilla.org/Security/DOH-resolver-policy
[16] https://internet.nl [16] https://www.ssllabs.com/ssltest/
[17] https://support.google.com/analytics/answer/2763052?hl=en [17] https://internet.nl
[18] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip- [18] https://support.google.com/analytics/answer/2763052?hl=en
[19] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-
geo-impact-test/ geo-impact-test/
[19] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc [20] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc
[20] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html [21] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html
[21] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn- [22] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
anon.pdf anon.pdf
[22] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ [23] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/
[23] http://mharvan.net/talks/noms-ip_anon.pdf [24] http://mharvan.net/talks/noms-ip_anon.pdf
[24] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf [25] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf
[25] https://medium.com/@bert.hubert/on-ip-address-encryption- [26] https://medium.com/@bert.hubert/on-ip-address-encryption-
security-analysis-with-respect-for-privacy-dabe1201b476 security-analysis-with-respect-for-privacy-dabe1201b476
[26] https://github.com/PowerDNS/ipcipher [27] https://github.com/PowerDNS/ipcipher
[27] https://github.com/veorq/ipcrypt [28] https://github.com/veorq/ipcrypt
[28] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html [29] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html
[29] https://tnc18.geant.org/core/presentation/127 [30] http://dl.ifip.org/db/conf/im/im2019/189282.pdf
Appendix A. Documents Appendix A. Documents
This section provides an overview of some DNS privacy related This section provides an overview of some DNS privacy related
documents, however, this is neither an exhaustive list nor a documents, however, this is neither an exhaustive list nor a
definitive statement on the characteristic of the document. definitive statement on the characteristic of the document.
A.1. Potential increases in DNS privacy A.1. Potential increases in DNS privacy
These documents are limited in scope to communications between stub These documents are limited in scope to communications between stub
skipping to change at page 30, line 18 skipping to change at page 31, line 28
o 'DNS Transport over TCP - Implementation Requirements' [RFC7766] o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]
o 'Operational requirements for DNS-over-TCP' o 'Operational requirements for DNS-over-TCP'
[I-D.ietf-dnsop-dns-tcp-requirements] [I-D.ietf-dnsop-dns-tcp-requirements]
o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828] o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]
o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal] o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal]
Appendix B. Encryption and DNSSEC Appendix B. IP address techniques
The addition of encryption to DNS does not remove the need for DNSSEC
[RFC4033] - they are independent and fully compatible protocols, each
solving different problems. The use of one does not diminish the
need nor the usefulness of the other.
All DNS privacy services SHOULD offer a DNS privacy service that
performs DNSSEC validation. In addition they SHOULD be able to
provide the DNSSEC RRs to the client so that it can perform its own
validation.
While the use of an authenticated and encrypted transport protects
origin authentication and data integrity between a client and a DNS
privacy service it provides no proof (for a non-validating client)
that the data provided by the DNS privacy service was actually DNSSEC
authenticated.
Appendix C. IP address techniques
Data minimization methods may be categorized by the processing used Data minimization methods may be categorized by the processing used
and the properties of their outputs. The following builds on the and the properties of their outputs. The following builds on the
categorization employed in [RFC6235]: categorization employed in [RFC6235]:
o Format-preserving. Normally when encrypting, the original data o Format-preserving. Normally when encrypting, the original data
length and patterns in the data should be hidden from an attacker. length and patterns in the data should be hidden from an attacker.
Some applications of de-identification, such as network capture Some applications of de-identification, such as network capture
de-identification, require that the de-identified data is of the de-identification, require that the de-identified data is of the
same form as the original data, to allow the data to be parsed in same form as the original data, to allow the data to be parsed in
skipping to change at page 31, line 41 skipping to change at page 32, line 35
o Reordering/shuffling. Preserving the original data, but o Reordering/shuffling. Preserving the original data, but
rearranging its order, often in a random manner. rearranging its order, often in a random manner.
o Random substitution. As replacement, but using randomly generated o Random substitution. As replacement, but using randomly generated
replacement values. replacement values.
o Cryptographic permutation. Using a permutation function, such as o Cryptographic permutation. Using a permutation function, such as
a hash function or cryptographic block cipher, to generate a a hash function or cryptographic block cipher, to generate a
replacement de-identified value. replacement de-identified value.
C.1. Google Analytics non-prefix filtering B.1. Google Analytics non-prefix filtering
Since May 2010, Google Analytics has provided a facility [17] that Since May 2010, Google Analytics has provided a facility [18] that
allows website owners to request that all their users IP addresses allows website owners to request that all their users IP addresses
are anonymized within Google Analytics processing. This very basic are anonymized within Google Analytics processing. This very basic
anonymization simply sets to zero the least significant 8 bits of anonymization simply sets to zero the least significant 8 bits of
IPv4 addresses, and the least significant 80 bits of IPv6 addresses. IPv4 addresses, and the least significant 80 bits of IPv6 addresses.
The level of anonymization this produces is perhaps questionable. The level of anonymization this produces is perhaps questionable.
There are some analysis results [18] which suggest that the impact of There are some analysis results [19] which suggest that the impact of
this on reducing the accuracy of determining the user's location from this on reducing the accuracy of determining the user's location from
their IP address is less than might be hoped; the average discrepancy their IP address is less than might be hoped; the average discrepancy
in identification of the user city for UK users is no more than 17%. in identification of the user city for UK users is no more than 17%.
Anonymization: Format-preserving, Filtering (grey marking). Anonymization: Format-preserving, Filtering (grey marking).
C.2. dnswasher B.2. dnswasher
Since 2006, PowerDNS have included a de-identification tool dnswasher Since 2006, PowerDNS have included a de-identification tool dnswasher
[19] with their PowerDNS product. This is a PCAP filter that [20] with their PowerDNS product. This is a PCAP filter that
performs a one-to-one mapping of end user IP addresses with an performs a one-to-one mapping of end user IP addresses with an
anonymized address. A table of user IP addresses and their de- anonymized address. A table of user IP addresses and their de-
identified counterparts is kept; the first IPv4 user addresses is identified counterparts is kept; the first IPv4 user addresses is
translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de- translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de-
identified address therefore depends on the order that addresses identified address therefore depends on the order that addresses
arrive in the input, and running over a large amount of data the arrive in the input, and running over a large amount of data the
address translation tables can grow to a significant size. address translation tables can grow to a significant size.
Anonymization: Format-preserving, Enumeration. Anonymization: Format-preserving, Enumeration.
C.3. Prefix-preserving map B.3. Prefix-preserving map
Used in TCPdpriv [20], this algorithm stores a set of original and Used in TCPdpriv [21], this algorithm stores a set of original and
anonymised IP address pairs. When a new IP address arrives, it is anonymised IP address pairs. When a new IP address arrives, it is
compared with previous addresses to determine the longest prefix compared with previous addresses to determine the longest prefix
match. The new address is anonymized by using the same prefix, with match. The new address is anonymized by using the same prefix, with
the remainder of the address anonymized with a random value. The use the remainder of the address anonymized with a random value. The use
of a random value means that TCPdrpiv is not deterministic; different of a random value means that TCPdrpiv is not deterministic; different
anonymized values will be generated on each run. The need to store anonymized values will be generated on each run. The need to store
previous addresses means that TCPdpriv has significant and unbounded previous addresses means that TCPdpriv has significant and unbounded
memory requirements, and because of the need to allocated anonymized memory requirements, and because of the need to allocated anonymized
addresses sequentially cannot be used in parallel processing. addresses sequentially cannot be used in parallel processing.
Anonymization: Format-preserving, prefix preservation (general). Anonymization: Format-preserving, prefix preservation (general).
C.4. Cryptographic Prefix-Preserving Pseudonymisation B.4. Cryptographic Prefix-Preserving Pseudonymisation
Cryptographic prefix-preserving pseudonymisation was originally Cryptographic prefix-preserving pseudonymisation was originally
proposed as an improvement to the prefix-preserving map implemented proposed as an improvement to the prefix-preserving map implemented
in TCPdpriv, described in Xu et al. [21] and implemented in the in TCPdpriv, described in Xu et al. [22] and implemented in the
Crypto-PAn tool [22]. Crypto-PAn is now frequently used as an Crypto-PAn tool [23]. Crypto-PAn is now frequently used as an
acronym for the algorithm. Initially it was described for IPv4 acronym for the algorithm. Initially it was described for IPv4
addresses only; extension for IPv6 addresses was proposed in Harvan & addresses only; extension for IPv6 addresses was proposed in Harvan &
Schoenwaelder [23] and implemented in snmpdump. This uses a Schoenwaelder [24] and implemented in snmpdump. This uses a
cryptographic algorithm rather than a random value, and thus cryptographic algorithm rather than a random value, and thus
pseudonymity is determined uniquely by the encryption key, and is pseudonymity is determined uniquely by the encryption key, and is
deterministic. It requires a separate AES encryption for each output deterministic. It requires a separate AES encryption for each output
bit, so has a non-trivial calculation overhead. This can be bit, so has a non-trivial calculation overhead. This can be
mitigated to some extent (for IPv4, at least) by pre-calculating mitigated to some extent (for IPv4, at least) by pre-calculating
results for some number of prefix bits. results for some number of prefix bits.
Pseudonymization: Format-preserving, prefix preservation (general). Pseudonymization: Format-preserving, prefix preservation (general).
C.5. Top-hash Subtree-replicated Anonymisation B.5. Top-hash Subtree-replicated Anonymisation
Proposed in Ramaswamy & Wolf [24], Top-hash Subtree-replicated Proposed in Ramaswamy & Wolf [25], Top-hash Subtree-replicated
Anonymisation (TSA) originated in response to the requirement for Anonymisation (TSA) originated in response to the requirement for
faster processing than Crypto-PAn. It used hashing for the most faster processing than Crypto-PAn. It used hashing for the most
significant byte of an IPv4 address, and a pre-calculated binary tree significant byte of an IPv4 address, and a pre-calculated binary tree
structure for the remainder of the address. To save memory space, structure for the remainder of the address. To save memory space,
replication is used within the tree structure, reducing the size of replication is used within the tree structure, reducing the size of
the pre-calculated structures to a few Mb for IPv4 addresses. the pre-calculated structures to a few Mb for IPv4 addresses.
Address pseudonymization is done via hash and table lookup, and so Address pseudonymization is done via hash and table lookup, and so
requires minimal computation. However, due to the much increased requires minimal computation. However, due to the much increased
address space for IPv6, TSA is not memory efficient for IPv6. address space for IPv6, TSA is not memory efficient for IPv6.
Pseudonymization: Format-preserving, prefix preservation (general). Pseudonymization: Format-preserving, prefix preservation (general).
C.6. ipcipher B.6. ipcipher
A recently-released proposal from PowerDNS [25], ipcipher [26] is a A recently-released proposal from PowerDNS [26], ipcipher [27] is a
simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6 simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6
addresses are encrypted directly with AES-128 using a key (which may addresses are encrypted directly with AES-128 using a key (which may
be derived from a passphrase). IPv4 addresses are similarly be derived from a passphrase). IPv4 addresses are similarly
encrypted, but using a recently proposed encryption ipcrypt [27] encrypted, but using a recently proposed encryption ipcrypt [28]
suitable for 32bit block lengths. However, the author of ipcrypt has suitable for 32bit block lengths. However, the author of ipcrypt has
since indicated [28] that it has low security, and further analysis since indicated [29] that it has low security, and further analysis
has revealed it is vulnerable to attack. has revealed it is vulnerable to attack.
Pseudonymization: Format-preserving, cryptographic permutation. Pseudonymization: Format-preserving, cryptographic permutation.
C.7. Bloom filters B.7. Bloom filters
van Rijswijk-Deij et al. [29] have recently described work using van Rijswijk-Deij et al. [30] have recently described work using
Bloom filters to categorize query traffic and record the traffic as Bloom filters to categorize query traffic and record the traffic as
the state of multiple filters. The goal of this work is to allow the state of multiple filters. The goal of this work is to allow
operators to identify so-called Indicators of Compromise (IOCs) operators to identify so-called Indicators of Compromise (IOCs)
originating from specific subnets without storing information about, originating from specific subnets without storing information about,
or be able to monitor the DNS queries of an individual user. By or be able to monitor the DNS queries of an individual user. By
using a Bloom filter, it is possible to determine with a high using a Bloom filter, it is possible to determine with a high
probability if, for example, a particular query was made, but the set probability if, for example, a particular query was made, but the set
of queries made cannot be recovered from the filter. Similarly, by of queries made cannot be recovered from the filter. Similarly, by
mixing queries from a sufficient number of users in a single filter, mixing queries from a sufficient number of users in a single filter,
it becomes practically impossible to determine if a particular user it becomes practically impossible to determine if a particular user
 End of changes. 63 change blocks. 
128 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/