draft-ietf-dprive-bcp-op-12.txt   draft-ietf-dprive-bcp-op-13.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: January 7, 2021 R. van Rijswijk-Deij Expires: January 11, 2021 R. van Rijswijk-Deij
NLnet Labs NLnet Labs
A. Mankin A. Mankin
Salesforce Salesforce
July 6, 2020 July 10, 2020
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-ietf-dprive-bcp-op-12 draft-ietf-dprive-bcp-op-13
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 January 7, 2021. This Internet-Draft will expire on January 11, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 12
5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12 5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
5.1.7. Impact of Encryption on Monitoring by DNS Privacy 5.1.7. Impact of Encryption on Monitoring by DNS Privacy
Service Operators . . . . . . . . . . . . . . . . . . 12 Service Operators . . . . . . . . . . . . . . . . . . 13
5.1.8. Limitations of fronting a DNS privacy service with a 5.1.8. Limitations of fronting a DNS privacy service with a
pure TLS proxy . . . . . . . . . . . . . . . . . . . 13 pure TLS proxy . . . . . . . . . . . . . . . . . . . 13
5.2. Data at rest on the server . . . . . . . . . . . . . . . 14 5.2. Data at rest on the server . . . . . . . . . . . . . . . 14
5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Data minimization of network traffic . . . . . . . . 15 5.2.2. Data minimization of network traffic . . . . . . . . 15
5.2.3. IP address pseudonymization and anonymization methods 16 5.2.3. IP address pseudonymization and anonymization methods 16
5.2.4. Pseudonymization, anonymization, or discarding of 5.2.4. Pseudonymization, anonymization, or discarding of
other correlation data . . . . . . . . . . . . . . . 16 other correlation data . . . . . . . . . . . . . . . 16
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. Recursive operator Privacy Statement (RPS) . . . . . . . . . 19 6. Recursive operator Privacy Statement (RPS) . . . . . . . . . 20
6.1. Outline of an RPS . . . . . . . . . . . . . . . . . . . . 20 6.1. Outline of an RPS . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 22 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security considerations . . . . . . . . . . . . . . . . . . . 22 8. Security considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 34
A.1. Potential increases in DNS privacy . . . . . . . . . . . 33 A.1. Potential increases in DNS privacy . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . . . . 38
B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38 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 . . . . . . 39
B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39 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 . . . . . . . 40
Appendix D. Example RPS . . . . . . . . . . . . . . . . . . . . 40 Appendix D. Example RPS . . . . . . . . . . . . . . . . . . . . 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
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
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 (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, there are no specific RFCs that IPSec, DNSCrypt, or VPNs. However, there are no specific RFCs that
cover the use of these transports for DNS 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. on the paths traversed by the encrypted connection 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 that will be accepted by the client's trust model, in the credentials that will be accepted by the client's trust model, in the
form of either X.509 certificates [RFC5280] or Subject Public Key form of either X.509 certificates [RFC5280] or Subject Public Key
Info (SPKI) pin sets [RFC8310]. 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].
skipping to change at page 17, line 24 skipping to change at page 17, line 34
[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] 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. Options proposed
include limiting access to a server and limiting non-recursive
queries.
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:
skipping to change at page 22, line 46 skipping to change at page 23, line 11
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 RPS. party auditor to verify their compliance with their published RPS.
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]. Security considerations for DoT are D.dnsop-dns-tcp-requirements]. Security considerations for DoT are
given in [RFC7858] and [RFC8310], those for DoH in [RFC8484]. given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].
Security considerations for DNSSEC are given in [RFC4033], [RFC4034] Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
and [RFC4035]. 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
skipping to change at page 23, line 42 skipping to change at page 24, line 7
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-13
o Minor edits
draft-ietf-dprive-bcp-op-12 draft-ietf-dprive-bcp-op-12
o Change DROP to RPS throughout o Change DROP to RPS throughout
draft-ietf-dprive-bcp-op-11 draft-ietf-dprive-bcp-op-11
o Improve text around use of normative language o Improve text around use of normative language
o Fix section 5.1.3.2 bullets o Fix section 5.1.3.2 bullets
skipping to change at page 24, line 36 skipping to change at page 25, line 5
draft-ietf-dprive-bcp-op-09 draft-ietf-dprive-bcp-op-09
o Fix references so they match the correct section numbers in draft- o Fix references so they match the correct section numbers in draft-
ietf-dprive-rfc7626-bis-05 ietf-dprive-rfc7626-bis-05
draft-ietf-dprive-bcp-op-08 draft-ietf-dprive-bcp-op-08
o Address IETF Last call comments. o Address IETF Last call comments.
draft-ietf-dprive-bcp-op-07
o Editorial changes following AD review. o Editorial changes following AD review.
o Change all URIs to Informational References. o Change all URIs to Informational References.
draft-ietf-dprive-bcp-op-06 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
skipping to change at page 34, line 47 skipping to change at page 35, line 15
o Section 8 of [RFC8484] outlines the privacy considerations of DoH. o Section 8 of [RFC8484] outlines the privacy considerations of DoH.
Note that (while that document advises exposing the minimal set of Note that (while that document advises exposing the minimal set of
data needed to achieve the desired feature set) depending on the data needed to achieve the desired feature set) depending on the
specifics of a DoH implementation there may be increased specifics of a DoH implementation there may be increased
identification and tracking compared to other DNS transports. 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].
o 'DNS Stateful Operations' [RFC8490]. o 'DNS Stateful Operations' [RFC8490].
Appendix B. IP address techniques Appendix B. IP address techniques
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 in 2019, and classifies them techniques employed or under development in 2019, and classifies them
skipping to change at page 38, line 12 skipping to change at page 38, line 26
Anonymization: Format-preserving, Enumeration. Anonymization: Format-preserving, Enumeration.
B.2.3. Prefix-preserving map B.2.3. Prefix-preserving map
Used in [TCPdpriv], 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 TCPdpriv 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.2.4. Cryptographic Prefix-Preserving Pseudonymization B.2.4. Cryptographic Prefix-Preserving Pseudonymization
Cryptographic prefix-preserving pseudonymization was originally Cryptographic prefix-preserving pseudonymization was originally
 End of changes. 23 change blocks. 
28 lines changed or deleted 33 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/