< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/