< draft-ietf-dprive-bcp-op-06.txt   draft-ietf-dprive-bcp-op-07.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: May 21, 2020 R. van Rijswijk-Deij Expires: June 20, 2020 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
November 18, 2019 December 18, 2019
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-06 draft-ietf-dprive-bcp-op-07
Abstract Abstract
This document presents operational, policy and security This document presents operational, policy and security
considerations for DNS recursive resolver operators who choose to considerations for DNS recursive resolver operators who choose to
offer DNS Privacy services. With these recommendations, the operator offer DNS Privacy services. With these recommendations, the operator
can make deliberate decisions regarding which services to provide, can make deliberate decisions regarding which services to provide,
and how the decisions and alternatives impact the privacy of users. and how the decisions and alternatives impact the privacy of users.
This document also presents a framework to assist writers of a DNS This document also presents a framework to assist writers of a 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 May 21, 2020. This Internet-Draft will expire on June 20, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. Privacy related documents . . . . . . . . . . . . . . . . . . 5 3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . 8 5.1.2. Authentication of DNS privacy services . . . . . . . 8
5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9 5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11
5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
5.1.7. Impact on DNS Privacy Service Operators . . . . . . . 12 5.1.7. Impact of Encryption on DNS Monitoring . . . . . . . 12
5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13 5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13
5.2. Data at rest on the server . . . . . . . . . . . . . . . 13 5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Data minimization of network traffic . . . . . . . . 14 5.2.2. Data minimization of network traffic . . . . . . . . 14
5.2.3. IP address pseudonymization and anonymization methods 15 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 . . . . . . . . . . . . . . . 17 other correlation data . . . . . . . . . . . . . . . 17
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 18 5.3. Data sent onwards from the server . . . . . . . . . . . . 18
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6.2. Current policy and privacy statements . . . . . . . . . . 22 6.2. Current policy and privacy statements . . . . . . . . . . 22
6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23 6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31 A.1. Potential increases in DNS privacy . . . . . . . . . . . 32
A.1. Potential increases in DNS privacy . . . . . . . . . . . 31 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 33
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 32 A.3. Related operational documents . . . . . . . . . . . . . . 33
A.3. Related operational documents . . . . . . . . . . . . . . 32 Appendix B. IP address techniques . . . . . . . . . . . . . . . 34
Appendix B. IP address techniques . . . . . . . . . . . . . . . 32 B.1. Google Analytics non-prefix filtering . . . . . . . . . . 35
B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33 B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 35
B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 34 B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 35
B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34 B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 36
B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34 B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 36
B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 35 B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 36
B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35 B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 37
B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Example DROP statement . . . . . . . . . . . . . . . 37
Appendix C. Example DROP statement . . . . . . . . . . . . . . . 36 C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 37
C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36 C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 40
C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 44 skipping to change at page 4, line 44
DROP statement is a document that an operator can publish DROP statement is a document that an operator can publish
outlining their operational practices and commitments with regard outlining their operational practices and commitments with regard
to privacy thereby providing a means for clients to evaluate the to privacy thereby providing a means for clients to evaluate the
privacy properties of a given DNS privacy service. In particular, privacy properties of a given DNS privacy service. In particular,
the framework identifies the elements that should be considered in the framework identifies the elements that should be considered in
formulating a DROP statement. This document does not, however, formulating a DROP statement. This document does not, however,
define a particular Privacy statement, nor does it seek to provide define a particular Privacy statement, nor does it seek to provide
legal advice or recommendations as to the contents. legal advice or recommendations as to the contents.
A desired operational impact is that all operators (both those A desired operational impact is that all operators (both those
providing resolvers within networks and those operating large anycast providing resolvers within networks and those operating large public
services) can demonstrate their commitment to user privacy thereby services) can demonstrate their commitment to user privacy thereby
driving all DNS resolution services to a more equitable footing. driving all DNS resolution services to a more equitable footing.
Choices for users would (in this ideal world) be driven by other Choices for users would (in this ideal world) be driven by other
factors e.g. differing security policies or minor difference in factors e.g. differing security policies or minor difference in
operator policy rather than gross disparities in privacy concerns. 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
skipping to change at page 5, line 26 skipping to change at page 5, line 26
from that document and from [RFC6973]. However this document is from that document and from [RFC6973]. However this document is
limited in scope to best practice considerations for the provision of limited in scope to best practice considerations for the provision of
DNS privacy services by servers (recursive resolvers) to clients DNS privacy services by servers (recursive resolvers) to clients
(stub resolvers or forwarders). Privacy considerations specifically (stub resolvers or forwarders). Privacy considerations specifically
from the perspective of an end user, or those for operators of from the perspective of an end user, or those for operators of
authoritative nameservers are out of scope. authoritative nameservers are out of scope.
This document includes (but is not limited to) considerations in the This document includes (but is not limited to) considerations in the
following areas (taken from [I-D.ietf-dprive-rfc7626-bis]): following areas (taken from [I-D.ietf-dprive-rfc7626-bis]):
1. Data "on the wire" between a client and a server 1. Data "on the wire" between a client and a server.
2. Data "at rest" on a server (e.g. in logs) 2. Data "at rest" on a server (e.g. in logs).
3. Data "sent onwards" from the server (either on the wire or shared 3. Data "sent onwards" from the server (either on the wire or shared
with a third party) with a third party).
Whilst the issues raised here are targeted at those operators who Whilst the issues raised here are targeted at those operators who
choose to offer a DNS privacy service, considerations for areas 2 and choose to offer a DNS privacy service, considerations for areas 2 and
3 could equally apply to operators who only offer DNS over 3 could equally apply to operators who only offer DNS over
unencrypted transports but who would like to align with privacy best unencrypted transports but who would like to align with privacy best
practice. practice.
3. Privacy related documents 3. Privacy related documents
There are various documents that describe protocol changes that have There are various documents that describe protocol changes that have
skipping to change at page 6, line 17 skipping to change at page 6, line 17
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
DNS terminology is as described in [RFC8499] with one modification: DNS terminology is as described in [RFC8499] with one modification:
we restate the clause in the original definition of Privacy-enabling we restate the clause in the original definition of Privacy-enabling
DNS server in [RFC8310] to include the requirement that a DNS over DNS server in [RFC8310] to include the requirement that a DNS over
(D)TLS server should also offer at least one of the credentials (D)TLS server should also offer at least one of the credentials
described in Section 8 and implement the (D)TLS profile described in described in Section 8 of [RFC8310] and implement the (D)TLS profile
Section 9 of [RFC8310]. described in Section 9 of [RFC8310].
Other Terms: Other Terms:
o DROP: DNS Recursive Operator Privacy statement, see Section 6. o DROP: DNS Recursive Operator Privacy statement, see Section 6.
o DNS privacy service: The service that is offered via a privacy- o DNS privacy service: The service that is offered via a privacy-
enabling DNS server and is documented either in an informal enabling DNS server and is documented either in an informal
statement of policy and practice with regard to users privacy or a statement of policy and practice with regard to users privacy or a
formal DROP statement. formal DROP statement.
5. Recommendations for DNS privacy services 5. Recommendations for DNS privacy services
We describe two classes of threats: We describe two classes of threats:
o 'Privacy Considerations for Internet Protocols' [RFC6973] Threats o Threats described in [RFC6973] 'Privacy Considerations for
Internet Protocols'
* Privacy terminology, threats to privacy and mitigations as * Privacy terminology, threats to privacy and mitigations as
described in Sections 3, 5 and 6 of [RFC6973]. described in Sections 3, 5 and 6 of [RFC6973].
o DNS Privacy Threats o DNS Privacy Threats
* These are threats to the users and operators of DNS privacy * These are threats to the users and operators of DNS privacy
services that are not directly covered by [RFC6973]. These may services that are not directly covered by [RFC6973]. These may
be more operational in nature such as certificate management or be more operational in nature such as certificate management or
service availability issues. service availability issues.
We describe three classes of actions that operators of DNS privacy We describe three classes of actions that operators of DNS privacy
services can take: services can take:
o Threat mitigation for well understood and documented privacy o Threat mitigation for well understood and documented privacy
threats to the users of the service and in some cases to the threats to the users of the service and in some cases to the
operators of the service. operators of the service.
o Optimization of privacy services from an operational or management o Optimization of privacy services from an operational or management
perspective perspective.
o Additional options that could further enhance the privacy and o Additional options that could further enhance the privacy and
usability of the service usability of the service.
This document does not specify policy only best practice, however for This document does not specify policy - only best practice, however
DNS Privacy services to be considered compliant with these best for DNS Privacy services to be considered compliant with these best
practice guidelines they SHOULD implement (where appropriate) all: practice guidelines they SHOULD implement (where appropriate) all:
o Threat mitigations to be minimally compliant o Threat mitigations to be minimally compliant.
o Optimizations to be moderately compliant o Optimizations to be moderately compliant.
o Additional options to be maximally compliant o Additional options to be maximally compliant.
5.1. On the wire between client and server 5.1. On the wire between client and server
In this section we consider both data on the wire and the service In this section we consider both data on the wire and the service
provided to the client. provided to the client.
5.1.1. Transport recommendations 5.1.1. Transport recommendations
[RFC6973] Threats: [RFC6973] Threats:
o Surveillance: o Surveillance:
* Passive surveillance of traffic on the wire * Passive surveillance of traffic on the wire
[I-D.ietf-dprive-rfc7626-bis] Section 2.4.2. [I-D.ietf-dprive-rfc7626-bis] Section 2.4.2.
DNS Privacy Threats: DNS Privacy Threats:
o Active injection of spurious data or traffic o Active injection of spurious data or traffic.
Mitigations: Mitigations:
A DNS privacy service can mitigate these threats by providing service A DNS privacy service can mitigate these threats by providing service
over one or more of the following transports over one or more of the following transports
o DNS-over-TLS [RFC7858] and [RFC8310] o DNS-over-TLS [RFC7858] and [RFC8310].
o DoH [RFC8484] o DoH [RFC8484].
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.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
DNS privacy services should ensure clients can authenticate the DNS privacy services should ensure clients can authenticate the
server. Note that this, in effect, commits the DNS privacy service server. Note that this, in effect, commits the DNS privacy service
to a public identity users will trust. to a public identity users will trust.
When using DNS-over-TLS clients that select a 'Strict Privacy' usage When using DNS-over-TLS clients that select a 'Strict Privacy' usage
profile [RFC8310] (to mitigate the threat of active attack on the profile [RFC8310] (to mitigate the threat of active attack on the
client) require the ability to authenticate the DNS server. To client) require the ability to authenticate the DNS server. To
enable this, DNS privacy services that offer DNS-over-TLS should enable this, DNS privacy services that offer DNS-over-TLS should
provide credentials in the form of either X.509 certificates provide credentials in the form of either X.509 certificates
[RFC5280] or SPKI pin sets [RFC8310]. [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310].
When offering DoH [RFC8484], HTTPS requires authentication of the When offering DoH [RFC8484], HTTPS requires authentication of the
server as part of the protocol. server as part of the protocol.
5.1.2.1. Certificate management 5.1.2.1. Certificate management
Anecdotal evidence to date highlights the management of certificates Anecdotal evidence to date highlights the management of certificates
as one of the more challenging aspects for operators of traditional as one of the more challenging aspects for operators of traditional
DNS resolvers that choose to additionally provide a DNS privacy DNS resolvers that choose to additionally provide a DNS privacy
service as management of such credentials is new to those DNS service as management of such credentials is new to those DNS
skipping to change at page 9, line 8 skipping to change at page 9, line 8
It is noted that SPKI pin set management is described in [RFC7858] It is noted that SPKI pin set management is described in [RFC7858]
but that key pinning mechanisms in general have fallen out of favor but that key pinning mechanisms in general have fallen out of favor
operationally for various reasons such as the logistical overhead of operationally for various reasons such as the logistical overhead of
rolling keys. rolling keys.
DNS Privacy Threats: DNS Privacy Threats:
o Invalid certificates, resulting in an unavailable service. o Invalid certificates, resulting in an unavailable service.
o Mis-identification of a server by a client e.g. typos in URLs or o Mis-identification of a server by a client e.g. typos in URLs or
authentication domain names authentication domain names.
Mitigations: Mitigations:
It is recommended that operators: It is recommended that operators:
o Follow the guidance in Section 6.5 of [RFC7525] with regards to o Follow the guidance in Section 6.5 of [RFC7525] with regards to
certificate revocation certificate revocation .
o Choose a short, memorable authentication name for the service
o Automate the generation, publication and renewal of certificates. o Automate the generation, publication and renewal of certificates.
For example, ACME [RFC8555] provides a mechanism to actively For example, ACME [RFC8555] provides a mechanism to actively
manage certificates through automation and has been implemented by manage certificates through automation and has been implemented by
a number of certificate authorities. a number of certificate authorities.
o Monitor certificates to prevent accidental expiration of o Monitor certificates to prevent accidental expiration of
certificates certificates.
o Choose a short, memorable authentication name for the service.
5.1.3. Protocol recommendations 5.1.3. Protocol recommendations
5.1.3.1. DNS-over-TLS 5.1.3.1. DNS-over-TLS
DNS Privacy Threats: DNS Privacy Threats:
o Known attacks on TLS such as those described in [RFC7457] o Known attacks on TLS such as those described in [RFC7457].
o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption] o Traffic analysis, for example: [Pitfalls-of-DNS-Encryption].
o Potential for client tracking via transport identifiers o Potential for client tracking via transport identifiers.
o Blocking of well known ports (e.g. 853 for DNS-over-TLS) o Blocking of well known ports (e.g. 853 for DNS-over-TLS).
Mitigations: Mitigations:
In the case of DNS-over-TLS, TLS profiles from Section 9 and the In the case of DNS-over-TLS, TLS profiles from Section 9 and the
Countermeasures to DNS Traffic Analysis from section 11.1 of Countermeasures to DNS Traffic Analysis from section 11.1 of
[RFC8310] provide strong mitigations. This includes but is not [RFC8310] provide strong mitigations. This includes but is not
limited to: limited to:
o Adhering to [RFC7525] o Adhering to [RFC7525].
o Implementing only (D)TLS 1.2 or later as specified in [RFC8310].
o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]
o Implementing EDNS(0) Padding [RFC7830] using the guidelines in o Implementing EDNS(0) Padding [RFC7830] using the guidelines in
[RFC8467] or a successor specification. [RFC8467] or a successor specification.
o Servers should not degrade in any way the query service level o Servers should not degrade in any way the query service level
provided to clients that do not use any form of session resumption provided to clients that do not use any form of session resumption
mechanism, such as TLS session resumption [RFC5077] with TLS 1.2, mechanism, such as TLS session resumption [RFC5077] with TLS 1.2,
section 2.2 of RFC8446, or Domain Name System (DNS) Cookies section 2.2 of RFC8446, or Domain Name System (DNS) Cookies
[RFC7873]. [RFC7873].
o A DNS-over-TLS privacy service on both port 853 and 443. This o A DNS-over-TLS privacy service on both port 853 and 443. This
practice may not be possible if e.g. the operator deploys DoH on practice may not be possible if e.g. the operator deploys DoH on
the same IP address. the same IP address.
Optimizations: Optimizations:
o Concurrent processing of pipelined queries, returning responses as o Concurrent processing of pipelined queries, returning responses as
soon as available, potentially out of order as specified in soon as available, potentially out of order as specified in
[RFC7766]. This is often called 'OOOR' - out-of-order responses. [RFC7766]. This is often called 'OOOR' - out-of-order responses
(Providing processing performance similar to HTTP multiplexing) (providing processing performance similar to HTTP multiplexing).
o Management of TLS connections to optimize performance for clients o Management of TLS connections to optimize performance for clients
using either using either:
* [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or * [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or
* DNS Stateful Operations [RFC8490] * DNS Stateful Operations [RFC8490].
5.1.3.2. DoH 5.1.3.2. DoH
DNS Privacy Threats: DNS Privacy Threats:
o Known attacks on TLS such as those described in [RFC7457] o Known attacks on TLS such as those described in [RFC7457].
o Traffic analysis, for example: DNS Privacy not so private: the o Traffic analysis, for example: [DNS-Privacy-not-so-private].
traffic analysis perspective [1]
o Potential for client tracking via transport identifiers o Potential for client tracking via transport identifiers.
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. DNSSEC 5.1.4. DNSSEC
DNS Privacy Threats: DNS Privacy Threats:
o Users may be directed to bogus IP addresses for e.g. websites o Users may be directed to bogus IP addresses for e.g. websites
skipping to change at page 12, line 5 skipping to change at page 12, line 5
outage. outage.
Mitigations: Mitigations:
A DNS privacy service should strive to engineer encrypted services to A DNS privacy service should strive to engineer encrypted services to
the same availability level as any unencrypted services they provide. the same availability level as any unencrypted services they provide.
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].
Years in the Life of Google [2].
Techniques such as those described in Section 10 of [RFC7766] can be Techniques such as those described in Section 10 of [RFC7766] can be
of use to operators to defend against such attacks. of use to operators to defend against such attacks.
5.1.6. Service options 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.7. Impact on DNS Privacy Service Operators 5.1.7. Impact of Encryption on DNS Monitoring
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
inspects network traffic. Such solutions will no longer function inspects network traffic. Such solutions will no longer function
when traffic between clients and resolvers is encrypted. There are, when traffic between clients and resolvers is encrypted. There are,
however, legitimate reasons for operators to inspect DNS traffic, however, legitimate reasons for operators to inspect DNS traffic,
e.g. to monitor for network security threats. Operators may e.g. to monitor for network security threats. Operators may
therefore need to invest in alternative means of monitoring that therefore need to invest in alternative means of monitoring that
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 [3]. traffic from the resolver using e.g. [dnstap].
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 section Section 5.2 for more details on data means to do so (see section Section 5.2 for more details on data
handling and also the discussion on the use of Bloom Filters in handling and also the discussion on the use of Bloom Filters in
Appendix A. Appendix A.
5.1.8. 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:
Some operators may choose to implement DNS-over-TLS using a TLS proxy Some operators may choose to implement DNS-over-TLS using a TLS proxy
(e.g. nginx [4], haproxy [5] or stunnel [6]) in front of a DNS (e.g. [nginx], [haproxy] or [stunnel]) in front of a DNS nameserver
nameserver because of proven robustness and capacity when handling because of proven robustness and capacity when handling large numbers
large numbers of client connections, load balancing capabilities and of client connections, load balancing capabilities and good tooling.
good tooling. Currently, however, because such proxies typically Currently, however, because such proxies typically have no specific
have no specific handling of DNS as a protocol over TLS or DTLS using handling of DNS as a protocol over TLS or DTLS using them can
them can restrict traffic management at the proxy layer and at the restrict traffic management at the proxy layer and at the DNS server.
DNS server. For example, all traffic received by a nameserver behind For example, all traffic received by a nameserver behind such a proxy
such a proxy will appear to originate from the proxy and DNS will appear to originate from the proxy and DNS techniques such as
techniques such as ACLs, RRL or DNS64 will be hard or impossible to ACLs, RRL or DNS64 will be hard or impossible to implement in the
implement in the nameserver. nameserver.
Operators may choose to use a DNS aware proxy such as dnsdist [7] Operators may choose to use a DNS aware proxy such as [dnsdist] which
which offer custom options (similar to that proposed in offer custom options (similar to that proposed in
[I-D.bellis-dnsop-xpf]) to add source information to packets to [I-D.bellis-dnsop-xpf]) to add source information to packets to
address this shortcoming. It should be noted that such options address this shortcoming. It should be noted that such options
potentially significantly increase the leaked information in the potentially significantly increase the leaked information in the
event of a misconfiguration. event of a misconfiguration.
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.
Mitigations: Mitigations:
The following are common activities for DNS service operators and in The following are common activities for DNS service operators and in
all cases should be minimized or completely avoided if possible for all cases should be minimized or completely avoided if possible for
DNS privacy services. If data is retained it should be encrypted and DNS privacy services. If data is retained it should be encrypted and
either aggregated, pseudonymized or anonymized whenever possible. In either aggregated, pseudonymized or anonymized whenever possible. In
general the principle of data minimization described in [RFC6973] general the principle of data minimization described in [RFC6973]
should be applied. should be applied.
skipping to change at page 15, line 27 skipping to change at page 15, line 27
the decade. Developments over the last decade have been both a the decade. Developments over the last decade have been both a
blessing and a curse; the large increase in size between an IPv4 and blessing and a curse; the large increase in size between an IPv4 and
an IPv6 address, for example, renders some techniques impractical, an IPv6 address, for example, renders some techniques impractical,
but also makes available a much larger amount of input entropy, the but also makes available a much larger amount of input entropy, the
better to resist brute force re-identification attacks that have better to resist brute force re-identification attacks that have
grown in practicality over the period. grown in practicality over the period.
Techniques employed may be broadly categorized as either Techniques employed may be broadly categorized as either
anonymization or pseudonymization. The following discussion uses the anonymization or pseudonymization. The following discussion uses the
definitions from [RFC6973] Section 3, with additional observations definitions from [RFC6973] Section 3, with additional observations
from van Dijkhuizen et al. [8] from [van-Dijkhuizen-et-al.]
o Anonymization. To enable anonymity of an individual, there must o Anonymization. To enable anonymity of an individual, there must
exist a set of individuals that appear to have the same exist a set of individuals that appear to have the same
attribute(s) as the individual. To the attacker or the observer, attribute(s) as the individual. To the attacker or the observer,
these individuals must appear indistinguishable from each other. these individuals must appear indistinguishable from each other.
o Pseudonymization. The true identity is deterministically replaced o Pseudonymization. The true identity is deterministically replaced
with an alternate identity (a pseudonym). When the with an alternate identity (a pseudonym). When the
pseudonymization schema is known, the process can be reversed, so pseudonymization schema is known, the process can be reversed, so
the original identity becomes known again. the original identity becomes known again.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
DNS is connecting DNS queries to an individual and the major vector DNS is connecting DNS queries to an individual and the major vector
for this in DNS traffic is the client IP address. for this in DNS traffic is the client IP address.
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. unencumbered by patents.
The following table presents a high level comparison of various The following table presents a high level comparison of various
techniques employed or under development today and classifies them techniques employed or under development in 2019 and classifies them
according to categorization of technique and other properties. according to categorization of technique and other properties.
Appendix B 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. The list definitions for the categories and properties listed below. The list
of techniques includes the main techniques in current use, but does of techniques includes the main techniques in current use, but does
not claim to be comprehensive. not claim to be comprehensive.
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
| Categorisation/Property | GA | d | TC | C | TS | i | B | | Categorisation/Property | GA | d | TC | C | TS | i | B |
+---------------------------+----+---+----+---+----+---+---+ +---------------------------+----+---+----+---+----+---+---+
| Anonymisation | X | X | X | | | | X | | Anonymisation | X | X | X | | | | X |
skipping to change at page 16, line 48 skipping to change at page 16, line 48
TS = TSA, i = ipcipher, B = Bloom filter TS = TSA, i = ipcipher, B = Bloom filter
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 [RFC8618] be in an existing data format such as PCAP [pcap] or C-DNS [RFC8618]
that can be used as input to existing analysis tools. In that case, that can be used as input to existing analysis tools. In that case,
use of a format-preserving technique is essential. This, though, is use of a format-preserving technique is essential. This, though, is
not cost-free - several authors (e.g. Brenker & Arnes [9]) have not cost-free - several authors (e.g. [Brenker-and-Arnes] have
observed that, as the entropy in an IPv4 address is limited, given a observed that, as the entropy in an IPv4 address is limited, given a
de-identified log from a target, if an attacker is capable of de-identified log from a target, if an attacker is capable of
ensuring packets are captured by the target and the attacker can send ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to forged traffic with arbitrary source and destination addresses to
that target, any format-preserving pseudonymization is vulnerable to that target, any format-preserving pseudonymization is vulnerable to
an attack along the lines of a cryptographic chosen plaintext attack. an attack along the 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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
o Fingerprinting of the client OS via various means including: IP o Fingerprinting of the client OS via various means including: IP
TTL/Hoplimit, TCP parameters (e.g. window size, ECN support, TTL/Hoplimit, TCP parameters (e.g. window size, ECN support,
SACK), OS specific DNS query patterns (e.g. for network SACK), OS specific DNS query patterns (e.g. for network
connectivity, captive portal detection or OS specific updates). connectivity, captive portal detection or OS specific updates).
o Fingerprinting of the client application or TLS library by e.g. o Fingerprinting of the client application or TLS library by e.g.
TLS version/Cipher suite combinations or other connection TLS version/Cipher suite combinations or other connection
parameters. parameters.
o Correlation of queries on multiple TCP session originating from o Correlation of queries on multiple TCP session originating from
the same IP address the same IP address.
o Correlating of queries on multiple TLS sessions originating from o Correlating of queries on multiple TLS sessions originating from
the same client, including via session resumption mechanisms the same client, including via 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 (e.g., User-Agent, Accept, Accept-Encoding) o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding).
Mitigations: Mitigations:
o Data minimization or discarding of such correlation data. o Data minimization or discarding of such correlation data.
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 [10] for an example o See [ISC-Knowledge-database-on-cache-snooping] for an example
discussion on defending against cache snooping discussion on defending 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:
* Transmission of identifying data upstream. * Transmission of identifying data upstream.
Mitigations: Mitigations:
As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS
Privacy services the server should: Privacy services the server should:
o Implement QNAME minimization [RFC7816] o Implement QNAME minimization [RFC7816].
o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
EDNS(0) Client Subnet (ECS) option and not send an ECS option in EDNS(0) Client Subnet (ECS) option and not send an ECS option in
upstream queries. upstream queries.
Optimizations: Optimizations:
o The server should either o The server should either:
* not use the ECS option in upstream queries at all, or * not use the ECS option in upstream queries at all, or
* offer alternative services, one that sends ECS and one that * offer alternative services, one that sends ECS and one that
does not. does not.
If operators do offer a service that sends the ECS options upstream If operators do offer a service that sends the ECS options upstream
they should use the shortest prefix that is operationally feasible they should use the shortest prefix that is operationally feasible
and ideally use a policy of whitelisting upstream servers to send ECS and ideally use a policy of whitelisting upstream servers to send ECS
to in order to minimize data leakage. Operators should make clear in to in order to minimize data leakage. Operators should make clear in
skipping to change at page 19, line 42 skipping to change at page 19, line 42
Another technique that particularly small operators may consider is Another technique that particularly small operators may consider is
forwarding local traffic to a larger resolver (with a privacy policy forwarding local traffic to a larger resolver (with a privacy policy
that aligns with their own practices) over an encrypted protocol so that aligns with their own practices) over an encrypted protocol so
that the upstream queries are obfuscated among those of the large that the upstream queries are obfuscated among those of the large
resolver. resolver.
5.3.3. Data sharing 5.3.3. Data sharing
[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
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).
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. This can purposes, within or outside of their own organization. This can
benefit not only the operator (through inclusion in novel research) benefit not only the operator (through inclusion in novel research)
but also the wider Internet community. See SURFnet's policy [11] on but also the wider Internet community. See the policy published by
data sharing for research as an example. SURFnet [SURFnet-policy] on data sharing for research as an example.
6. DNS Recursive Operator Privacy (DROP) statement 6. DNS Recursive Operator Privacy (DROP) statement
The following section outlines the recommended contents of a DROP The following section outlines the recommended contents of a DROP
statement an operator might choose to publish. An example statement statement an operator might choose to publish. An example statement
for a specific scenario is provided for guidance only in Appendix C. for a specific scenario is provided for guidance only in Appendix C.
6.1. Recommended contents of a DROP statement 6.1. Recommended contents of a DROP statement
6.1.1. Policy 6.1.1. Policy
1. Treatment of IP addresses. Make an explicit statement that IP 1. Treatment of IP addresses. Make an explicit statement that IP
addresses are treated as PII. addresses are treated as PII.
2. Data collection and sharing. Specify clearly what data 2. Data collection and sharing. Specify clearly what data
(including IP addresses) is: (including IP addresses) is:
* Collected and retained by the operator, and for what period it * Collected and retained by the operator, and for what period it
is retained is retained.
* Shared with partners * Shared with partners.
* Shared, sold or rented to third-parties * Shared, sold or rented to third-parties.
and in each case whether it is aggregated, pseudonymized or and in each case whether it is aggregated, pseudonymized or
anonymized and the conditions of data transfer. anonymized and the conditions of data transfer.
3. Exceptions. Specify any exceptions to the above, for example 3. Exceptions. Specify any exceptions to the above, for example
technically malicious or anomalous behavior. technically malicious or anomalous behavior.
4. Associated entities. Declare any partners, third-party 4. Associated entities. Declare any partners, third-party
affiliations or sources of funding. affiliations or sources of funding.
skipping to change at page 21, line 22 skipping to change at page 21, line 22
operator filters, edits or alters in any way the replies that it operator filters, edits or alters in any way the replies that it
receives from the authoritative servers for each DNS zone, before receives from the authoritative servers for each DNS zone, before
forwarding them to the clients. For each category listed below, forwarding them to the clients. For each category listed below,
the operator should also specify how the filtering lists are the operator should also specify how the filtering lists are
created and managed, whether it employs any third-party sources created and managed, whether it employs any third-party sources
for such lists, and which ones. for such lists, and which ones.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
network and computer security reasons (e.g. preventing network and computer security reasons (e.g. preventing
connections to malware-spreading websites or botnet control connections to malware-spreading websites or botnet control
servers) servers).
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
mandatory legal reasons, due to applicable legislation or mandatory legal reasons, due to applicable legislation or
binding orders by courts and other public authorities binding orders by courts and other public authorities.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
voluntary legal reasons, due to an internal policy by the voluntary legal reasons, due to an internal policy by the
operator aiming at reducing potential legal risks operator aiming at reducing potential legal risks.
* Specify if any replies are being filtered out or altered for * Specify if any replies are being filtered out or altered for
any other reason, including commercial ones any other reason, including commercial ones.
6.1.2. Practice 6.1.2. Practice
This section should explain the current operational practices of the This section should explain the current operational practices of the
service. service.
1. Deviations. Specify any temporary or permanent deviations from 1. Deviations. Specify any temporary or permanent deviations from
the policy for operational reasons. the policy for operational reasons.
2. Client facing capabilities. With reference to section Section 5 2. Client facing capabilities. With reference to section Section 5
provide specific details of which capabilities are provided on provide specific details of which capabilities are provided on
which client facing addresses and ports: which client facing addresses and ports:
1. For DoT, specify the authentication name to be used (if any) 1. For DoT, specify the authentication name to be used (if any).
2. For DoT, specify the SPKI pin sets to be used (if any) and 2. For DoT, specify the SPKI pin sets to be used (if any) and
policy for rolling keys policy for rolling keys.
3. Upstream capabilities. With reference to section Section 5.3 3. Upstream capabilities. With reference to section Section 5.3
provide specific details of which capabilities are provided provide specific details of which capabilities are provided
upstream for data sent to authoritative servers. upstream for data sent to authoritative servers.
4. Support. Provide contact/support information for the service. 4. Support. Provide contact/support information for the service.
5. Jurisdiction. This section should communicate the applicable 5. Jurisdiction. This section should communicate the applicable
jurisdictions and law enforcement regimes under which the service jurisdictions and law enforcement regimes under which the service
is being provided. is being provided.
skipping to change at page 22, line 39 skipping to change at page 22, line 39
certain countries are only served by certain servers, this certain countries are only served by certain servers, this
should be specified as well). should be specified as well).
4. Specify whether the operator has any agreement in place with 4. Specify whether the operator has any agreement in place with
law enforcement agencies, or other public and private parties law enforcement agencies, or other public and private parties
dealing with security and intelligence, to give them access dealing with security and intelligence, to give them access
to the servers and/or to the data. to the servers and/or to the data.
6.2. Current policy and privacy statements 6.2. Current policy and privacy statements
A tabular comparison of existing policy and privacy statements from A tabular comparison of policy and privacy statements from various
various DNS Privacy service operators based loosely on the proposed DNS Privacy service operators based loosely on the proposed DROP
DROP structure can be found on dnsprivacy.org [12]. structure can be found at [policy-comparison]. The analysis is based
on the data available in December 2019.
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 It is also noted that Mozilla have published a DoH resolver policy
policy [13], which describes the minimum set of policy requirements [DoH-resolver-policy], which describes the minimum set of policy
that a party must satisfy to be considered as a potential partner for requirements that a party must satisfy to be considered as a
Mozilla's Trusted Recursive Resolver (TRR) program. 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 [14] or Internet.nl [15]. that are currently available e.g. [SSL-Labs] or [Internet.nl].
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 DROP party auditor to verify their compliance with their published DROP
statement. statement.
7. IANA considerations 7. IANA considerations
None None
8. Security considerations 8. Security considerations
Security considerations for DNS-over-TCP are given in [RFC7766], many Security considerations for DNS-over-TCP are given in [RFC7766], many
of which are generally applicable to session based DNS. of which are generally applicable to session based DNS. Guidance on
operational requirements for DNS-over-TCP are also available in [I-
D.dnsop-dns-tcp-requirements].
9. Acknowledgements 9. Acknowledgements
Many thanks to Amelia Andersdotter for a very thorough review of the Many thanks to Amelia Andersdotter for a very thorough review of the
first draft of this document and Stephen Farrell for a thorough first draft of this document and Stephen Farrell for a thorough
review at WGLC and for suggesting the inclusion of an example DROP review at WGLC and for suggesting the inclusion of an example DROP
statement. Thanks to John Todd for discussions on this topic, and to statement. Thanks to John Todd for discussions on this topic, and to
Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review. Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review.
Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York, Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York,
John Reed, Lorenzo Colitti for comments at the mic. Thanks to John Reed, Lorenzo Colitti for comments at the mic. Thanks to
skipping to change at page 24, line 25 skipping to change at page 24, line 25
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-05 draft-ietf-dprive-bcp-op-07
o Editorial changes following AD review.
o Change all URIs to Informational References.
draft-ietf-dprive-bcp-op-06
o Final minor changes from second WGLC. o Final minor changes from second WGLC.
draft-ietf-dprive-bcp-op-05 draft-ietf-dprive-bcp-op-05
o Remove some text on consent: o Remove some text on consent:
* Paragraph 2 in section 5.3.3 * Paragraph 2 in section 5.3.3
* Item 6 in the DROP Practice statement (and example) * Item 6 in the DROP Practice statement (and example)
skipping to change at page 26, line 32 skipping to change at page 26, line 38
o Initial commit of re-named document after adoption to replace o Initial commit of re-named document after adoption to replace
draft-dickinson-dprive-bcp-op-01 draft-dickinson-dprive-bcp-op-01
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dprive-rfc7626-bis] [I-D.ietf-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in Considerations", draft-ietf-dprive-rfc7626-bis-03 (work in
progress), October 2019. progress), November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, <https://www.rfc- DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
editor.org/info/rfc6265>. editor.org/info/rfc6265>.
skipping to change at page 28, line 20 skipping to change at page 28, line 25
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>. October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
12.2. Informative References 12.2. Informative References
[Bloom-filter]
van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
Allodi, "Privacy-Conscious Threat Intelligence Using
DNSBLOOM", 2019,
<http://dl.ifip.org/db/conf/im/im2019/189282.pdf>.
[Brenker-and-Arnes]
Brekne, T. and A. Arnes, "CIRCUMVENTING IP-ADDRESS
PSEUDONYMIZATION", 2005, <https://pdfs.semanticscholar.org
/7b34/12c951cebe71cd2cddac5fda164fb2138a44.pdf>.
[Crypto-PAn]
CESNET, "Crypto-PAn", 2015,
<https://github.com/CESNET/ipfixcol/tree/master/base/src/
intermediate/anonymization/Crypto-PAn>.
[DNS-Privacy-not-so-private]
Silby, S., Juarez, M., Vallina-Rodriguez, N., and C.
Troncosol, "DNS Privacy not so private: the traffic
analysis perspective.", 2019,
<https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.
[dnsdist] PowerDNS, "dnsdist Overview", 2019, <https://dnsdist.org>.
[dnstap] dnstap.info, "DNSTAP", 2019, <http://dnstap.info>.
[DoH-resolver-policy]
Mozilla, "Security/DOH-resolver-policy", 2019,
<https://wiki.mozilla.org/Security/DOH-resolver-policy>.
[Geolocation-Impact-Assessement]
Conversion Works, "Anonymize IP Geolocation Accuracy
Impact Assessment", 2017,
<https://support.google.com/analytics/
answer/2763052?hl=en>.
[haproxy] haproxy.org, "HAPROXY", 2019, <https://www.haproxy.org/>.
[Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving
IP Address Anonymization", 2006,
<http://mharvan.net/talks/noms-ip_anon.pdf>.
[I-D.bellis-dnsop-xpf] [I-D.bellis-dnsop-xpf]
Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For", Bellis, R., Dijk, P., and R. Gacogne, "DNS X-Proxied-For",
draft-bellis-dnsop-xpf-04 (work in progress), March 2018. draft-bellis-dnsop-xpf-04 (work in progress), March 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-05 (work in progress), November 2019. requirements-05 (work in progress), November 2019.
[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-09 (work in progress), November ietf-httpbis-bcp56bis-09 (work in progress), November
2019. 2019.
[Internet.nl]
Internet.nl, "Internet.nl Is Your Internet Up To Date?",
2019, <https://internet.nl>.
[IP-Anonymization-in-Analytics]
Google, "IP Anonymization in Analytics", 2019,
<https://support.google.com/analytics/
answer/2763052?hl=en>.
[ipcipher1]
Hubert, B., "On IP address encryption: security analysis
with respect for privacy", 2017,
<https://medium.com/@bert.hubert/on-ip-address-encryption-
security-analysis-with-respect-for-privacy-dabe1201b476>.
[ipcipher2]
PowerDNS, "ipcipher", 2017, <https://github.com/PowerDNS/
ipcipher>.
[ipcrypt] veorq, "ipcrypt: IP-format-preserving encryption", 2015,
<https://github.com/veorq/ipcrypt>.
[ipcrypt-analysis]
Aumasson, J., "Analysis of ipcrypt?", 2018,
<https://www.ietf.org/mail-archive/web/cfrg/current/
msg09494.html>.
[ISC-Knowledge-database-on-cache-snooping]
ISC Knowledge Database, "DNS Cache snooping - should I be
concerned?", 2018, <https://kb.isc.org/docs/aa-00482>.
[nginx] nginx.org, "NGINX", 2019, <https://nginx.org/>.
[Passive-Observations-of-a-Large-DNS]
de Vries, W., van Rijswijk-Deij, R., de Boer, P., and A.
Pras, "Passive Observations of a Large DNS Service: 2.5
Years in the Life of Google", 2018,
<http://tma.ifip.org/2018/wp-
content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.
[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>. [pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
[Pitfalls-of-DNS-Encryption] [Pitfalls-of-DNS-Encryption]
Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
Encryption", 2014, <https://dl.acm.org/ Encryption", 2014, <https://dl.acm.org/
citation.cfm?id=2665959>. citation.cfm?id=2665959>.
[policy-comparison]
dnsprivacy.org, "Comparison of policy and privacy
statements 2019", 2019,
<https://dnsprivacy.org/wiki/display/DP/
Comparison+of+policy+and+privacy+statements+2019>.
[Ramaswamy-and-Wolf]
Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving
IP Address Anonymization for Passive Measurement Systems",
2007,
<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
skipping to change at page 30, line 10 skipping to change at page 32, line 15
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
2019, <https://www.rfc-editor.org/info/rfc8618>. 2019, <https://www.rfc-editor.org/info/rfc8618>.
12.3. URIs [SSL-Labs]
SSL Labs, "SSL Server Test", 2019,
[1] https://petsymposium.org/2018/files/hotpets/4-siby.pdf <https://www.ssllabs.com/ssltest/>.
[2] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/
tma2018_paper30.pdf
[3] http://dnstap.info
[4] https://nginx.org/
[5] https://www.haproxy.org/
[6] https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html
[7] https://dnsdist.org
[8] https://doi.org/10.1145/3182660
[9] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164
fb2138a44.pdf
[10] https://kb.isc.org/docs/aa-00482
[11] https://surf.nl/datasharing
[12] https://dnsprivacy.org/wiki/display/DP/
Comparison+of+policy+and+privacy+statements
[13] https://wiki.mozilla.org/Security/DOH-resolver-policy
[14] https://www.ssllabs.com/ssltest/
[15] https://internet.nl
[16] https://support.google.com/analytics/answer/2763052?hl=en
[17] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-
geo-impact-test/
[18] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc
[19] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html
[20] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
anon.pdf
[21] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/
[22] http://mharvan.net/talks/noms-ip_anon.pdf
[23] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf
[24] https://medium.com/@bert.hubert/on-ip-address-encryption- [stunnel] ISC Knowledge Database, "DNS-over-TLS", 2018,
security-analysis-with-respect-for-privacy-dabe1201b476 <https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.
[25] https://github.com/PowerDNS/ipcipher [SURFnet-policy]
SURFnet, "SURFnet Data Sharing Policy", 2016,
<https://surf.nl/datasharing>.
[26] https://github.com/veorq/ipcrypt [TCPdpriv]
Ipsilon Networks, Inc., "TCPdpriv", 2005,
<http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html>.
[27] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html [van-Dijkhuizen-et-al.]
Van Dijkhuizen , N. and J. Van Der Ham, "A Survey of
Network Traffic Anonymisation Techniques and
Implementations", 2018, <https://doi.org/10.1145/3182660>.
[28] http://dl.ifip.org/db/conf/im/im2019/189282.pdf [Xu-et-al.]
Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-
preserving IP address anonymization: measurement-based
security evaluation and a new cryptography-based scheme",
2004, <http://an.kaist.ac.kr/~sbmoon/paper/
intl-journal/2004-cn-anon.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 31, line 45 skipping to change at page 33, line 14
o 'Specification for DNS over Transport Layer Security (TLS)' o 'Specification for DNS over Transport Layer Security (TLS)'
[RFC7858], referred to here as 'DNS-over-TLS'. [RFC7858], referred to here as 'DNS-over-TLS'.
o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094], o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094],
referred to here as 'DNS-over-DTLS'. Note that this document has referred to here as 'DNS-over-DTLS'. Note that this document has
the Category of Experimental. the Category of Experimental.
o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH. o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH.
o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310] o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310].
o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for
EDNS(0)' [RFC8467] EDNS(0)' [RFC8467].
These documents apply to recursive to authoritative DNS but are These documents apply to recursive to authoritative DNS but are
relevant when considering the operation of a recursive server: relevant when considering the operation of a recursive server:
o 'DNS Query Name minimization to Improve Privacy' [RFC7816] o 'DNS Query Name minimization to Improve Privacy' [RFC7816]
referred to here as 'QNAME minimization' referred to here as 'QNAME minimization'.
A.2. Potential decreases in DNS privacy A.2. Potential decreases in DNS privacy
These documents relate to functionality that could provide increased These documents relate to functionality that could provide increased
tracking of user activity as a side effect: tracking of user activity as a side effect:
o 'Client Subnet in DNS Queries' [RFC7871] o 'Client Subnet in DNS Queries' [RFC7871].
o 'Domain Name System (DNS) Cookies' [RFC7873]) o 'Domain Name System (DNS) Cookies' [RFC7873]).
o 'Transport Layer Security (TLS) Session Resumption without Server- o 'Transport Layer Security (TLS) Session Resumption without Server-
Side State' [RFC5077] referred to here as simply TLS session Side State' [RFC5077] referred to here as simply TLS session
resumption. resumption.
o 'A DNS Packet Capture Format' [RFC8618] o 'A DNS Packet Capture Format' [RFC8618].
o Passive DNS [RFC8499] o Passive DNS [RFC8499].
Note that depending on the specifics of the implementation [RFC8484] Note that depending on the specifics of the implementation [RFC8484]
may also provide increased tracking. may also provide increased tracking.
A.3. Related operational documents A.3. Related operational documents
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' [RFC8490] o 'DNS Stateful Operations' [RFC8490].
Appendix B. IP address techniques Appendix B. 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
skipping to change at page 33, line 47 skipping to change at page 35, line 14
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.
B.1. Google Analytics non-prefix filtering B.1. Google Analytics non-prefix filtering
Since May 2010, Google Analytics has provided a facility [16] that Since May 2010, Google Analytics has provided a facility
allows website owners to request that all their users IP addresses [IP-Anonymization-in-Analytics] that allows website owners to request
are anonymized within Google Analytics processing. This very basic that all their users IP addresses are anonymized within Google
anonymization simply sets to zero the least significant 8 bits of Analytics processing. This very basic anonymization simply sets to
IPv4 addresses, and the least significant 80 bits of IPv6 addresses. zero the least significant 8 bits of IPv4 addresses, and the least
The level of anonymization this produces is perhaps questionable. significant 80 bits of IPv6 addresses. The level of anonymization
this produces is perhaps questionable. There are some analysis
There are some analysis results [17] which suggest that the impact of results [Geolocation-Impact-Assessement] which suggest that the
this on reducing the accuracy of determining the user's location from impact of this on reducing the accuracy of determining the user's
their IP address is less than might be hoped; the average discrepancy location from their IP address is less than might be hoped; the
in identification of the user city for UK users is no more than 17%. average discrepancy 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).
B.2. dnswasher B.2. dnswasher
Since 2006, PowerDNS have included a de-identification tool dnswasher Since 2006, PowerDNS have included a de-identification tool
[18] with their PowerDNS product. This is a PCAP filter that Appendix B.2 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.
B.3. Prefix-preserving map B.3. Prefix-preserving map
Used in TCPdpriv [19], this algorithm stores a set of original and Used in [TCPdpriv], 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).
B.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. [20] and implemented in the in TCPdpriv, described in [Xu-et-al.] and implemented in the
Crypto-PAn tool [21]. Crypto-PAn is now frequently used as an [Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym
acronym for the algorithm. Initially it was described for IPv4 for the algorithm. Initially it was described for IPv4 addresses
addresses only; extension for IPv6 addresses was proposed in Harvan & only; extension for IPv6 addresses was proposed in [Harvan]. This
Schoenwaelder [22] and implemented in snmpdump. This uses a 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).
B.5. Top-hash Subtree-replicated Anonymisation B.5. Top-hash Subtree-replicated Anonymisation
Proposed in Ramaswamy & Wolf [23], Top-hash Subtree-replicated Proposed in [Ramaswamy-and-Wolf], 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).
B.6. ipcipher B.6. ipcipher
A recently-released proposal from PowerDNS [24], ipcipher [25] is a A recently-released proposal from PowerDNS, ipcipher [ipcipher1]
simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6 [ipcipher2] is a simple pseudonymization technique for IPv4 and IPv6
addresses are encrypted directly with AES-128 using a key (which may addresses. IPv6 addresses are encrypted directly with AES-128 using
be derived from a passphrase). IPv4 addresses are similarly a key (which may be derived from a passphrase). IPv4 addresses are
encrypted, but using a recently proposed encryption ipcrypt [26] similarly encrypted, but using a recently proposed encryption
suitable for 32bit block lengths. However, the author of ipcrypt has [ipcrypt] suitable for 32bit block lengths. However, the author of
since indicated [27] that it has low security, and further analysis ipcrypt has since indicated [ipcrypt-analysis] that it has low
has revealed it is vulnerable to attack. security, and further analysis has revealed it is vulnerable to
attack.
Pseudonymization: Format-preserving, cryptographic permutation. Pseudonymization: Format-preserving, cryptographic permutation.
B.7. Bloom filters B.7. Bloom filters
van Rijswijk-Deij et al. [28] have recently described work using van Rijswijk-Deij et al. have recently described work using Bloom
Bloom filters to categorize query traffic and record the traffic as filters [Bloom-filter] to categorize query traffic and record the
the state of multiple filters. The goal of this work is to allow traffic as the state of multiple filters. The goal of this work is
operators to identify so-called Indicators of Compromise (IOCs) to allow operators to identify so-called Indicators of Compromise
originating from specific subnets without storing information about, (IOCs) originating from specific subnets without storing information
or be able to monitor the DNS queries of an individual user. By about, or be able to monitor the DNS queries of an individual user.
using a Bloom filter, it is possible to determine with a high By 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
performed a particular query. Large numbers of queries can be performed a particular query. Large numbers of queries can be
tracked in a memory-efficient way. As filter status is stored, this tracked in a memory-efficient way. As filter status is stored, this
approach cannot be used to regenerate traffic, and so cannot be used approach cannot be used to regenerate traffic, and so cannot be used
with tools used to process live traffic. with tools used to process live traffic.
Anonymized: Generalization. Anonymized: Generalization.
 End of changes. 114 change blocks. 
233 lines changed or deleted 302 lines changed or added

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