draft-ietf-dprive-bcp-op-10.txt   draft-ietf-dprive-bcp-op-11.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: December 20, 2020 R. van Rijswijk-Deij Expires: January 3, 2021 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
June 18, 2020 July 2, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-10 draft-ietf-dprive-bcp-op-11
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 non-normative framework to assist This document also presents a non-normative framework to assist
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 December 20, 2020. This Internet-Draft will expire on January 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 49 skipping to change at page 2, line 49
5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17 5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
5.3. Data sent onwards from the server . . . . . . . . . . . . 17 5.3. Data sent onwards from the server . . . . . . . . . . . . 17
5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17 5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18 5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19 5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19 6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19
6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20 6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20
6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20 6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21 6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22 6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security considerations . . . . . . . . . . . . . . . . . . . 23 8. Security considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . 29
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33
A.1. Potential increases in DNS privacy . . . . . . . . . . . 33 A.1. Potential increases in DNS privacy . . . . . . . . . . . 33
A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34 A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34
A.3. Related operational documents . . . . . . . . . . . . . . 34 A.3. Related operational documents . . . . . . . . . . . . . . 34
Appendix B. IP address techniques . . . . . . . . . . . . . . . 35 Appendix B. IP address techniques . . . . . . . . . . . . . . . 35
B.1. Categorization of techniques . . . . . . . . . . . . . . 36 B.1. Categorization of techniques . . . . . . . . . . . . . . 36
B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37 B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37
B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37 B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37
B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37 B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37
B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 37 B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38
B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38 B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38
B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38 B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38
B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 38 B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39
B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39 B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39
Appendix C. Current policy and privacy statements . . . . . . . 39 Appendix C. Current policy and privacy statements . . . . . . . 39
Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40 Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40
D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40 D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40
D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43 D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
feature (e.g., good reachability or encrypted transport) or because feature (e.g., good reachability or encrypted transport) or because
the network resolver lacks a specific feature (e.g., strong privacy the network resolver lacks a specific feature (e.g., strong privacy
policy or unfiltered responses). These open resolvers have tended to policy or unfiltered responses). These open resolvers have tended to
be at the forefront of adoption of privacy-related enhancements but be at the forefront of adoption of privacy-related enhancements but
it is anticipated that operators of other resolver services will it is anticipated that operators of other resolver services will
follow. follow.
Whilst protocols that encrypt DNS messages on the wire provide Whilst protocols that encrypt DNS messages on the wire provide
protection against certain attacks, the resolver operator still has protection against certain attacks, the resolver operator still has
(in principle) full visibility of the query data and transport (in principle) full visibility of the query data and transport
identifiers for each user. Therefore, a trust relationship exists. identifiers for each user. Therefore, a trust relationship (whether
The ability of the operator to provide a transparent, well explicit or implicit) is assumed to exist between each user and the
documented, and secure privacy service will likely serve as a major operator of the resolver(s) used by that user. The ability of the
differentiating factor for privacy conscious users if they make an operator to provide a transparent, well documented, and secure
active selection of which resolver to use. privacy service will likely serve as a major differentiating factor
for privacy conscious users if they make an active selection of which
resolver to use.
It should also be noted that the choice of a user to configure a It should also be noted that the choice of a user to configure a
single resolver (or a fixed set of resolvers) and an encrypted single resolver (or a fixed set of resolvers) and an encrypted
transport to use in all network environments has both advantages and transport to use in all network environments has both advantages and
disadvantages. For example, the user has a clear expectation of disadvantages. For example, the user has a clear expectation of
which resolvers have visibility of their query data. However, this which resolvers have visibility of their query data. However, this
resolver/transport selection may provide an added mechanism to track resolver/transport selection may provide an added mechanism to track
them as they move across network environments. Commitments from them as they move across network environments. Commitments from
resolver operators to minimize such tracking as users move between resolver operators to minimize such tracking as users move between
networks are also likely to play a role in user selection of networks are also likely to play a role in user selection of
skipping to change at page 4, line 38 skipping to change at page 4, line 40
This document has two main goals: This document has two main goals:
o To provide operational and policy guidance related to DNS over o To provide operational and policy guidance related to DNS over
encrypted transports and to outline recommendations for data encrypted transports and to outline recommendations for data
handling for operators of DNS privacy services. handling for operators of DNS privacy services.
o To introduce the DNS Recursive Operator Privacy (DROP) statement o To introduce the DNS Recursive Operator Privacy (DROP) statement
and present a framework to assist writers of a DROP statement. A and present a framework to assist writers of a DROP statement. A
DROP statement is a document that an operator should publish which DROP statement is a document that an operator should publish which
outlines their operational practices and commitments with regard outlines 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 both
measurable and claimed privacy properties of a given DNS privacy the measurable and claimed privacy properties of a given DNS
service. The framework identifies a set of elements and specifies privacy service. The framework identifies a set of elements and
an outline order for them. This document does not, however, specifies an outline order for them. This document does not,
define a particular Privacy statement, nor does it seek to provide however, define a particular Privacy statement, nor does it seek
legal advice as to the contents. to provide legal advice 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 public 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
skipping to change at page 5, line 43 skipping to change at page 5, line 45
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 otherwise like to align with unencrypted transports but who would otherwise like to align with
privacy best practice. privacy best 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
the potential to either increase or decrease the privacy properties the potential to either increase or decrease the privacy properties
of the DNS. Note this does not imply that some documents are good or of the DNS in various ways. Note this does not imply that some
bad, better or worse, just that (for example) some features may bring documents are good or bad, better or worse, just that (for example)
functional benefits at the price of a reduction in privacy and some features may bring functional benefits at the price of a
conversely some features increase privacy with an accompanying reduction in privacy and conversely some features increase privacy
increase in complexity. A selection of the most relevant documents with an accompanying increase in complexity. A selection of the most
are listed in Appendix A for reference. relevant documents are listed in Appendix A for reference.
4. Terminology 4. Terminology
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:
skipping to change at page 7, line 25 skipping to change at page 7, line 25
This document does not specify policy - only best practice, however This document does not specify policy - only best practice, however
for 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.
In other words, these requirements are specified here as all being The rest of this document does not use normative language but instead
normative requirements, and are classified only by different levels refers only to the three differing classes of action which correspond
of compliance in the rest of the document. to the three named levels of compliance stated above. However,
compliance (to the indicated level) remains a normative requirement.
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:
skipping to change at page 8, line 12 skipping to change at page 8, line 12
o DNS over TLS (DoT) [RFC7858] and [RFC8310]. o DNS over TLS (DoT) [RFC7858] and [RFC8310].
o DNS over HTTPS (DoH) [RFC8484]. o DNS over HTTPS (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, there are no specific RFCs that
are not standardized in DNS specific RFCs and any discussion of best cover the use of these transports for DNS and any discussion of best
practice for providing such a service is out of scope for this practice for providing such a service is out of scope for this
document. 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 Section 5.1.4. 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 on client resolver configuration * Active attacks on client resolver configuration
Mitigations: Mitigations:
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 DoT clients that select a 'Strict Privacy' usage profile When using DoT, clients that select a 'Strict Privacy' usage profile
[RFC8310] (to mitigate the threat of active attack on the client) [RFC8310] (to mitigate the threat of active attack on the client)
require the ability to authenticate the DNS server. To enable this, require the ability to authenticate the DNS server. To enable this,
DNS privacy services that offer DNS-over-TLS need to provide DNS privacy services that offer DNS-over-TLS need to provide
credentials in the form of either X.509 certificates [RFC5280] or credentials that will be accepted by the client's trust model, in the
Subject Public Key Info (SPKI) pin sets [RFC8310]. form of either X.509 certificates [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.
Server operators should also follow the best practices with regard to Server operators should also follow the best practices with regard to
certificate revocation as described in [RFC7525]. certificate revocation as described in [RFC7525].
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
skipping to change at page 10, line 50 skipping to change at page 10, line 50
Management of TLS connections to optimize performance for clients Management of TLS connections to optimize performance for clients
using DNS Stateful Operations [RFC8490]. using 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 Use of HTTP/2 padding and/or EDNS(0) padding as described in
Section 9 of [RFC8484]
o Traffic analysis, for example: [DNS-Privacy-not-so-private]. o Traffic analysis, for example: [DNS-Privacy-not-so-private].
o Potential for client tracking via transport identifiers. o Potential for client tracking via transport identifiers.
Mitigations: Mitigations:
o Clients must be able to forgo the use of HTTP Cookies [RFC6265] o Clients must be able to forgo the use of HTTP Cookies [RFC6265]
and still use the service. and still use the service.
o Use of HTTP/2 padding and/or EDNS(0) padding as described in
Section 9 of [RFC8484]
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 which, depending on o Users may be directed to bogus IP addresses which, depending on
the application, protocol and authentication method, might lead the application, protocol and authentication method, might lead
skipping to change at page 14, line 32 skipping to change at page 14, line 32
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 recommendations relating to common activities for The following are recommendations relating to common activities for
DNS service operators and in all cases such activities should be DNS service operators and in all cases data retention should be
minimized or completely avoided if possible for DNS privacy services. minimized or completely avoided if possible for DNS privacy services.
If data is retained it should be encrypted and either aggregated, If data is retained it should be encrypted and either aggregated,
pseudonymized, or anonymized whenever possible. In general the pseudonymized, or anonymized whenever possible. In general the
principle of data minimization described in [RFC6973] should be principle of data minimization described in [RFC6973] should be
applied. applied.
o Transient data (e.g., that is used for real time monitoring and o Transient data (e.g., that is used for real time monitoring and
threat analysis which might be held only in memory) should be threat analysis which might be held only in memory) should be
retained for the shortest possible period deemed operationally retained for the shortest possible period deemed operationally
feasible. feasible.
skipping to change at page 16, line 42 skipping to change at page 16, line 42
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 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.,
HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS
version/Cipher suite combinations, or other connection parameters. version/Cipher suite combinations, or other connection parameters.
o Correlation of queries on multiple TCP sessions originating from o Correlation of queries on multiple TCP sessions 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 Customer-premises equipment (CPE) in EDNS(0) options - some Customer-premises equipment (CPE)
devices are known to add them [MAC-address-EDNS]. devices are known to add them [MAC-address-EDNS].
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:
skipping to change at page 18, line 13 skipping to change at page 18, line 13
o As per Section 2 of [RFC7871] the server should either: o As per Section 2 of [RFC7871] 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 allowlisting upstream servers to send ECS and ideally use a policy of allowlisting upstream servers to send ECS
to in order to minimize data leakage. Operators should make clear in to in order to reduce data leakage. Operators should make clear in
any policy statement what prefix length they actually send and the any policy statement what prefix length they actually send and the
specific policy used. specific policy used.
Allowlisting has the benefit that not only does the operator know Allowlisting has the benefit that not only does the operator know
which upstream servers can use ECS but also allows the operator to which upstream servers can use ECS but also allows the operator to
decide which upstream servers apply privacy policies that the decide which upstream servers apply privacy policies that the
operator is happy with. However some operators consider allowlisting operator is happy with. However some operators consider allowlisting
to incur significant operational overhead compared to dynamic to incur significant operational overhead compared to dynamic
detection of ECS on authoritative servers. detection of ECS support on authoritative servers.
Additional options: Additional options:
o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020] o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
(NXDOMAIN: There Really Is Nothing Underneath) to reduce the (NXDOMAIN: There Really Is Nothing Underneath) to reduce the
number of queries to authoritative servers to increase privacy. number of queries to authoritative servers to increase privacy.
o Run a copy of the root zone on loopback [RFC7706] to avoid making o Run a copy of the root zone on loopback [RFC7706] to avoid making
queries to the root servers that might leak information. queries to the root servers that might leak information.
skipping to change at page 21, line 44 skipping to change at page 21, line 44
[NOTE FOR RFC EDITOR: Please update this section to use letters for [NOTE FOR RFC EDITOR: Please update this section to use letters for
the sub-bullet points instead of numbers. This was not done during the sub-bullet points instead of numbers. This was not done during
review because the markdown tool used to write the document did not review because the markdown tool used to write the document did not
support it.] support it.]
Communicate the current operational practices of the service. Communicate the current operational practices of the 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 5 provide 2. Client facing capabilities. With reference to each subsection of
specific details of which capabilities are provided on which Section 5.1 provide specific details of which capabilities
client facing addresses and ports: (transport, DNSSEC, padding, etc.) are provided on which client
facing addresses/port combination or DoH URI template. For
Section 5.1.2, clearly specify which specific authentication
mechanisms are supported for each endpoint that offers DoT:
1. For DoT, specify the authentication domain name to be used 1. The authentication domain name to be used (if any).
(if any).
2. For DoT, specify the SPKI pin sets to be used (if any) and 2. The SPKI pin sets to be used (if any) and policy for rolling
policy for rolling keys. 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. Data Processing. This section can optionally communicate links
jurisdictions and law enforcement regimes under which the service to and the high level contents of any separate statements the
is being provided. operator has published which cover applicable data processing
legislation or agreements with regard to the location(s) of
1. Specify the operator entity or entities that will control the service provision.
data and be responsible for their treatment, and their legal
place of business.
2. Specify, either directly or by pointing to the applicable
privacy policy, the relevant privacy laws that apply to the
treatment of the data, the rights that users enjoy in regard
to their own personal information that is treated by the
service, and how they can contact the operator to exercise
them.
3. Additionally specify the countries in which the servers
handling the DNS requests and the data are located (if the
operator applies a geolocation policy so that requests from
certain countries are only served by certain servers, this
should be specified as well).
4. Specify whether the operator has any agreement in place with
law enforcement agencies, or other public and private
parties, to give them access to the servers and/or to the
data.
6.2. Enforcement/accountability 6.2. 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.
skipping to change at page 23, line 18 skipping to change at page 22, line 50
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. Guidance on of which are generally applicable to session based DNS. Guidance on
operational requirements for DNS-over-TCP are also available in [I- operational requirements for DNS-over-TCP are also available in [I-
D.dnsop-dns-tcp-requirements]. D.dnsop-dns-tcp-requirements]. Security considerations for DoT are
given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].
Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
and [RFC4035].
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,
Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to
skipping to change at page 24, line 7 skipping to change at page 23, line 42
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-10 draft-ietf-dprive-bcp-op-11
o Improve text around use of normative language
o Fix section 5.1.3.2 bullets
o Improve text in 6.1.2. item 2.
o Rework text of 6.1.2. item 5 and update example DROP
o Various editorial improvements
o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
have one general reference RFC7626 have one general reference RFC7626
o Clarify that the DROP statement outline is non-normative and add o Clarify that the DROP statement outline is non-normative and add
some further qualifications about content some further qualifications about content
o Update wording on data sharing to remove explicit discussion of o Update wording on data sharing to remove explicit discussion of
consent consent
o Move table in section 5.2.3 to an appendix o Move table in section 5.2.3 to an appendix
skipping to change at page 25, line 4 skipping to change at page 24, line 48
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)
o Remove .onion and TLSA options o Remove .onion and TLSA options
o Include ACME as a reference for certificate management
o Include ACME as a reference for certificate management
o Update text on session resumption usage o Update text on session resumption usage
o Update section 5.2.4 on client fingerprinting o Update section 5.2.4 on client fingerprinting
draft-ietf-dprive-bcp-op-04 draft-ietf-dprive-bcp-op-04
o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement
o Update structure of DROP slightly o Update structure of DROP slightly
skipping to change at page 27, line 22 skipping to change at page 27, line 17
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>. <https://www.rfc-editor.org/info/rfc7816>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
skipping to change at page 28, line 5 skipping to change at page 28, line 10
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, <https://www.rfc- DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
editor.org/info/rfc7830>. editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
editor.org/info/rfc7871>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, <https://www.rfc- DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
editor.org/info/rfc8310>. editor.org/info/rfc8310>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, <https://www.rfc-
editor.org/info/rfc8404>.
[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>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
12.2. Informative References 12.2. Informative References
[Bloom-filter] [Bloom-filter]
van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L. van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
Allodi, "Privacy-Conscious Threat Intelligence Using Allodi, "Privacy-Conscious Threat Intelligence Using
DNSBLOOM", 2019, DNSBLOOM", 2019,
skipping to change at page 31, line 27 skipping to change at page 31, line 44
PowerDNS, "dnswasher", 2019, PowerDNS, "dnswasher", 2019,
<https://github.com/PowerDNS/pdns/blob/master/pdns/ <https://github.com/PowerDNS/pdns/blob/master/pdns/
dnswasher.cc>. dnswasher.cc>.
[Ramaswamy-and-Wolf] [Ramaswamy-and-Wolf]
Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving
IP Address Anonymization for Passive Measurement Systems", IP Address Anonymization for Passive Measurement Systems",
2007, 2007,
<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>. <http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[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>.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
<https://www.rfc-editor.org/info/rfc6235>. <https://www.rfc-editor.org/info/rfc6235>.
[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>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc- DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
editor.org/info/rfc7626>. editor.org/info/rfc7626>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
editor.org/info/rfc7706>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
editor.org/info/rfc7871>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy, [RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
"DNSSEC Roadblock Avoidance", BCP 207, RFC 8027, "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
DOI 10.17487/RFC8027, November 2016, <https://www.rfc- DOI 10.17487/RFC8027, November 2016, <https://www.rfc-
editor.org/info/rfc8027>. editor.org/info/rfc8027>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, <https://www.rfc- DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
editor.org/info/rfc8094>. editor.org/info/rfc8094>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, Pervasive Encryption on Operators", RFC 8404,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. DOI 10.17487/RFC8404, July 2018, <https://www.rfc-
editor.org/info/rfc8404>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>.
[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>.
skipping to change at page 34, line 34 skipping to change at page 34, line 38
resumption. resumption.
o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
1.3 1.3
o 'A DNS Packet Capture Format' [RFC8618]. o 'A DNS Packet Capture Format' [RFC8618].
o Passive DNS [RFC8499]. o Passive DNS [RFC8499].
o Section 8 of [RFC8484] outlines the privacy considerations of DoH. o Section 8 of [RFC8484] outlines the privacy considerations of DoH.
Note that depending on the specifics of a DoH implementation there Note that (while that document advises exposing the minimal set of
may be increased identification and tracking compared to other DNS data needed to achieve the desired feature set) depending on the
transports. specifics of a DoH implementation there may be increased
identification and tracking compared to other DNS transports.
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].
skipping to change at page 35, line 49 skipping to change at page 35, line 49
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-and-Arnes] 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, if an
de-identified log from a target, if an attacker is capable of attacker can
ensuring packets are captured by the target and the attacker can send
forged traffic with arbitrary source and destination addresses to o ensure packets are captured by the target and
that target, any format-preserving pseudonymization is vulnerable to o send forged traffic with arbitrary source and destination
an attack along the lines of a cryptographic chosen plaintext attack. addresses to that target and
o obtain a de-identified log of said traffic from that target
any format-preserving pseudonymization is vulnerable to an attack
along the lines of a cryptographic chosen plaintext attack.
B.1. Categorization of techniques B.1. Categorization of 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 36, line 33 skipping to change at page 36, line 38
addresses. Prefix preservation ensures that prefixes are de- addresses. Prefix preservation ensures that prefixes are de-
identified consistently; e.g., if two IP addresses are from the identified consistently; e.g., if two IP addresses are from the
same subnet, a prefix preserving de-identification will ensure same subnet, a prefix preserving de-identification will ensure
that their de-identified counterparts will also share a subnet. that their de-identified counterparts will also share a subnet.
Prefix preservation may be fixed (i.e. based on a user selected Prefix preservation may be fixed (i.e. based on a user selected
prefix length identified in advance to be preserved ) or general. prefix length identified in advance to be preserved ) or general.
o Replacement. A one-to-one replacement of a field to a new value o Replacement. A one-to-one replacement of a field to a new value
of the same type, for example, using a regular expression. of the same type, for example, using a regular expression.
o Filtering. Removing (and thus truncating) or replacing data in a o Filtering. Removing or replacing data in a field. Field data can
field. Field data can be overwritten, often with zeros, either be overwritten, often with zeros, either partially (truncation or
partially (grey marking) or completely (black marking). reverse truncation) or completely (black-marker anonymization).
o Generalization. Data is replaced by more general data with o Generalization. Data is replaced by more general data with
reduced specificity. One example would be to replace all TCP/UDP reduced specificity. One example would be to replace all TCP/UDP
port numbers with one of two fixed values indicating whether the port numbers with one of two fixed values indicating whether the
original port was ephemeral (>=1024) or non-ephemeral (>1024). original port was ephemeral (>=1024) or non-ephemeral (>1024).
Another example, precision degradation, reduces the accuracy of Another example, precision degradation, reduces the accuracy of
e.g., a numeric value or a timestamp. e.g., a numeric value or a timestamp.
o Enumeration. With data from a well-ordered set, replace the first o Enumeration. With data from a well-ordered set, replace the first
data item data using a random initial value and then allocate data item data using a random initial value and then allocate
skipping to change at page 37, line 29 skipping to change at page 37, line 34
Analytics processing. This very basic anonymization simply sets to Analytics processing. This very basic anonymization simply sets to
zero the least significant 8 bits of IPv4 addresses, and the least zero the least significant 8 bits of IPv4 addresses, and the least
significant 80 bits of IPv6 addresses. The level of anonymization significant 80 bits of IPv6 addresses. The level of anonymization
this produces is perhaps questionable. There are some analysis this produces is perhaps questionable. There are some analysis
results [Geolocation-Impact-Assessement] which suggest that the results [Geolocation-Impact-Assessement] which suggest that the
impact of this on reducing the accuracy of determining the user's impact of this on reducing the accuracy of determining the user's
location from their IP address is less than might be hoped; the location from their IP address is less than might be hoped; the
average discrepancy in identification of the user city for UK users average discrepancy in identification of the user city for UK users
is no more than 17%. is no more than 17%.
Anonymization: Format-preserving, Filtering (grey marking). Anonymization: Format-preserving, Filtering (trucation).
B.2.2. dnswasher B.2.2. dnswasher
Since 2006, PowerDNS have included a de-identification tool dnswasher Since 2006, PowerDNS have included a de-identification tool dnswasher
[PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP [PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP
filter that performs a one-to-one mapping of end user IP addresses filter that performs a one-to-one mapping of end user IP addresses
with an anonymized address. A table of user IP addresses and their with an anonymized address. A table of user IP addresses and their
de-identified counterparts is kept; the first IPv4 user addresses is de-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
skipping to change at page 41, line 22 skipping to change at page 41, line 28
DoH DoH
+ Origin IP general geolocation information: i.e. geocode, + Origin IP general geolocation information: i.e. geocode,
region ID, city ID, and metro code region ID, city ID, and metro code
+ IP protocol version - IPv4 or IPv6 + IP protocol version - IPv4 or IPv6
+ Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN, + Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN,
etc. etc.
+ Absolute arrival time + Absolute arrival time using a precision in ms
+ Name of the specific instance that processed this request + Name of the specific instance that processed this request
+ IP address of the specific instance to which this request + IP address of the specific instance to which this request
was addressed (no relation to the requestor's IP address) was addressed (no relation to the requestor's IP address)
We may keep the following data as summary information, We may keep the following data as summary information,
including all the above EXCEPT for data about the DNS record including all the above EXCEPT for data about the DNS record
requested: requested:
skipping to change at page 43, line 40 skipping to change at page 43, line 48
3. Upstream capabilities. 3. Upstream capabilities.
1. Our servers implement QNAME minimization. 1. Our servers implement QNAME minimization.
2. Our servers do not send ECS upstream. 2. Our servers do not send ECS upstream.
4. Support. Support information for this service is available at 4. Support. Support information for this service is available at
(insert link). (insert link).
5. Jurisdiction. 5. Data Processing. We operate as the legal entity (insert entity)
registered in (insert country); as such we operate under (insert
1. We operate as the legal entity (insert entity) registered in country/region) law. Our separate statement regarding the
(insert country) as (insert company identifier e.g Company specifics of our data processing policy, practice, and agreements
Number). Our Headquarters are located at (insert address). can be found here (insert link).
2. As such we operate under (insert country) law. For details
of our company privacy policy see (insert link). For
questions on this policy and enforcement contact our Data
Protection Officer on (insert email address).
3. We operate servers in the following countries (insert list).
4. We have no agreements in place with law enforcement agencies
to give them access to the data. Apart from as stated in the
Policy section of this document with regard to cyber threat
intelligence, we have no agreements in place with other
public and private parties dealing with security and
intelligence, to give them access to the servers and/or to
the data.
Authors' Addresses Authors' Addresses
Sara Dickinson Sara Dickinson
Sinodun IT Sinodun IT
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
 End of changes. 50 change blocks. 
144 lines changed or deleted 144 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/