rfc8932v1.txt		rfc8932.txt
	skipping to change at line 19 ¶		skipping to change at line 19 ¶
	October 2020		October 2020
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	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, as		can make deliberate decisions regarding which services to provide, as
	well as how the decisions and alternatives impact the privacy of		well as understanding how those decisions and the alternatives impact
	users.		the privacy of users.
	This document also presents a non-normative framework to assist		This document also presents a non-normative framework to assist
	writers of a Recursive operator Privacy Statement, analogous to DNS		writers of a Recursive operator Privacy Statement, analogous to DNS
	Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements		Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements
	described in RFC 6841.		described in RFC 6841.
	Status of This Memo		Status of This Memo
	This memo documents an Internet Best Current Practice.		This memo documents an Internet Best Current Practice.
	skipping to change at line 192 ¶		skipping to change at line 192 ¶
	legal advice as to the contents of an RPS.		legal advice as to the contents of an RPS.
	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 differences in		factors -- e.g., differing security policies or minor differences in
	operator policy -- rather than gross disparities in privacy concerns.		operator policy -- rather than gross disparities in privacy concerns.
	Community insight [or judgment?] about operational practices can		Community insight (or judgment?) about operational practices can
	change quickly, and experience shows that a Best Current Practice		change quickly, and experience shows that a Best Current Practice
	(BCP) document about privacy and security is a point-in-time		(BCP) document about privacy and security is a point-in-time
	statement. Readers are advised to seek out any updates that apply to		statement. Readers are advised to seek out any updates that apply to
	this document.		this document.
	2. Scope		2. Scope
	"DNS Privacy Considerations" [RFC7626] describes the general privacy		"DNS Privacy Considerations" [RFC7626] describes the general privacy
	issues and threats associated with the use of the DNS by Internet		issues and threats associated with the use of the DNS by Internet
	users; much of the threat analysis here is lifted from that document		users; much of the threat analysis here is lifted from that document
	skipping to change at line 316 ¶		skipping to change at line 316 ¶
	to the three named levels of compliance stated above. However,		to the three named levels of compliance stated above. However,
	compliance (to the indicated level) remains a normative requirement.		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:		Threats described in [RFC6973]:
	Surveillance:		Surveillance:
	Passive surveillance of traffic on the wire.		Passive surveillance of traffic on the wire.
	DNS Privacy Threats:		DNS Privacy Threats:
	Active injection of spurious data or traffic.		Active injection of spurious data or traffic.
	Mitigations:		Mitigations:
	A DNS privacy service can mitigate these threats by providing		A DNS privacy service can mitigate these threats by providing
	service over one or more of the following transports:		service over one or more of the following transports:
	* DNS over TLS (DoT) [RFC7858] [RFC8310].		* DNS over TLS (DoT) [RFC7858] [RFC8310].
	* DNS over HTTPS (DoH) [RFC8484].		* 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		DNSCrypt [DNSCrypt], IPsec, or VPNs. However, there are no specific
	cover the use of these transports for DNS, and any discussion of best		RFCs that cover the use of these transports for DNS, and any
	practice for providing such a service is out of scope for this		discussion of best practice for providing such a service is out of
	document.		scope for this document.
	Whilst encryption of DNS traffic can protect against active injection		Whilst encryption of DNS traffic can protect against active injection
	on the paths traversed by the encrypted connection, this does not		on the paths traversed by the encrypted connection, this does not
	diminish the need for DNSSEC; see Section 5.1.4.		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:		Threats described in [RFC6973]:
	Surveillance:		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		server. Note that this, in effect, commits the DNS privacy
	service to a public identity users will trust.		service to a public identity users will trust.
	When using DoT, clients that select a "Strict Privacy" usage		When using DoT, clients that select a "Strict Privacy" usage
	profile [RFC8310] (to mitigate the threat of active attack on the		profile [RFC8310] (to mitigate the threat of active attack on the
	client) require the ability to authenticate the DNS server. To		client) require the ability to authenticate the DNS server. To
	enable this, DNS privacy services that offer DNS over TLS need to		enable this, DNS privacy services that offer DoT need to provide
	provide credentials that will be accepted by the client's trust		credentials that will be accepted by the client's trust model, in
	model, in the form of either X.509 certificates [RFC5280] or		the form of either X.509 certificates [RFC5280] or Subject Public
	Subject Public Key Info (SPKI) pin sets [RFC8310].		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 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
	as one of the more challenging aspects for operators of traditional		as one of the more challenging aspects for operators of traditional
	DNS resolvers that choose to additionally provide a DNS privacy		DNS resolvers that choose to additionally provide a DNS privacy
	service, as management of such credentials is new to those DNS		service, as management of such credentials is new to those DNS
	operators.		operators.
	It is noted that SPKI pin-set management is described in [RFC7858]		It is noted that SPKI pin set management is described in [RFC7858]
	but that key-pinning mechanisms in general have fallen out of favor		but that key-pinning mechanisms in general have fallen out of favor
	operationally for various reasons, such as the logistical overhead of		operationally for various reasons, such as the logistical overhead of
	rolling keys.		rolling keys.
	DNS Privacy Threats:		DNS Privacy Threats:
	* Invalid certificates, resulting in an unavailable service,		* Invalid certificates, resulting in an unavailable service,
	which might force a user to fallback to cleartext.		which might force a user to fall back to cleartext.
	* Misidentification of a server by a client -- e.g., typos in DoH		* Misidentification of a server by a client -- e.g., typos in DoH
	URL templates [RFC8484] or authentication domain names		URL templates [RFC8484] or authentication domain names
	[RFC8310] that accidentally direct clients to attacker-		[RFC8310] that accidentally direct clients to attacker-
	controlled servers.		controlled servers.
	Mitigations:		Mitigations:
	It is recommended that operators:		It is recommended that operators:
	* Follow the guidance in Section 6.5 of [RFC7525] with regard to		* Follow the guidance in Section 6.5 of [RFC7525] with regard to
	skipping to change at line 523 ¶		skipping to change at line 520 ¶
	DNS actually solves many of the practical issues encountered by DNS		DNS actually solves many of the practical issues encountered by DNS
	validating clients -- e.g., interference by middleboxes with		validating clients -- e.g., interference by middleboxes with
	cleartext DNS payloads is completely avoided. In this sense, a		cleartext DNS payloads is completely avoided. In this sense, a
	validating client that uses a DNS privacy service that supports		validating client that uses a DNS privacy service that supports
	DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance		DNSSEC has a far simpler task in terms of DNSSEC roadblock avoidance
	[RFC8027].		[RFC8027].
	5.1.5. Availability		5.1.5. Availability
	DNS Privacy Threats:		DNS Privacy Threats:
	A failed DNS privacy service could force the user to switch		A failing DNS privacy service could force the user to switch
	providers, fallback to cleartext, or accept no DNS service for the		providers, fall back to cleartext, or accept no DNS service for
	outage.		the duration of the outage.
	Mitigations:		Mitigations:
	A DNS privacy service should strive to engineer encrypted services		A DNS privacy service should strive to engineer encrypted services
	to the same availability level as any unencrypted services they		to the same availability level as any unencrypted services they
	provide. Particular care should to be taken to protect DNS		provide. Particular care should to be taken to protect DNS
	privacy services against denial-of-service (DoS) attacks, as		privacy services against denial-of-service (DoS) attacks, as
	experience has shown that unavailability of DNS resolving because		experience has shown that unavailability of DNS resolving because
	of attacks is a significant motivation for users to switch		of attacks is a significant motivation for users to switch
	services. See, for example, Section IV-C of		services. See, for example, Section IV-C of
	[Passive-Observations-of-a-Large-DNS].		[Passive-Observations-of-a-Large-DNS].
	Techniques such as those described in Section 10 of [RFC7766] can		Techniques such as those described in Section 10 of [RFC7766] can
	be of use to operators to defend against such attacks.		be of use to operators to defend against such attacks.
	5.1.6. Service Options		5.1.6. Service Options
	DNS Privacy Threats:		DNS Privacy Threats:
	Unfairly disadvantaging users of the privacy service with respect		Unfairly disadvantaging users of the privacy service with respect
	to the services available. This could force the user to switch		to the services available. This could force the user to switch
	providers, fallback to cleartext, or accept no DNS service for the		providers, fall back to cleartext, or accept no DNS service for
	outage.		the duration of the outage.
	Mitigations:		Mitigations:
	A DNS privacy service should deliver the same level of service as		A DNS privacy service should deliver the same level of service as
	offered on unencrypted channels in terms of options such as		offered on unencrypted channels in terms of options such as
	filtering (or lack thereof), DNSSEC validation, etc.		filtering (or lack thereof), DNSSEC validation, etc.
	5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service		5.1.7. Impact of Encryption on Monitoring by DNS Privacy Service
	Operators		Operators
	DNS Privacy Threats:		DNS Privacy Threats:
	skipping to change at line 602 ¶		skipping to change at line 599 ¶
	Some operators may choose to implement DoT using a TLS proxy		Some operators may choose to implement DoT using a TLS proxy
	(e.g., [nginx], [haproxy], or [stunnel]) in front of a DNS		(e.g., [nginx], [haproxy], or [stunnel]) in front of a DNS
	nameserver because of proven robustness and capacity when handling		nameserver because of proven robustness and capacity when handling
	large numbers of client connections, load-balancing capabilities,		large numbers of client connections, load-balancing capabilities,
	and good tooling. Currently, however, because such proxies		and good tooling. Currently, however, because such proxies
	typically have no specific handling of DNS as a protocol over TLS		typically have no specific handling of DNS as a protocol over TLS
	or DTLS, using them can restrict traffic management at the proxy		or DTLS, using them can restrict traffic management at the proxy
	layer and the DNS server. For example, all traffic received by a		layer and the DNS server. For example, all traffic received by a
	nameserver behind such a proxy will appear to originate from the		nameserver behind such a proxy will appear to originate from the
	proxy, and DNS techniques such as Access Control Lists (ACLs),		proxy, and DNS techniques such as Access Control Lists (ACLs),
	Response Rate Limiting (RRL), or DNS64 will be hard or impossible		Response Rate Limiting (RRL), or DNS64 [RFC6147] will be hard or
	to implement in the nameserver.		impossible to implement in the nameserver.
	Operators may choose to use a DNS-aware proxy, such as [dnsdist],		Operators may choose to use a DNS-aware proxy, such as [dnsdist],
	that offers custom options (similar to those proposed in		that offers custom options (similar to those proposed in
	[DNS-XPF]) to add source information to packets to address this		[DNS-XPF]) to add source information to packets to address this
	shortcoming. It should be noted that such options potentially		shortcoming. It should be noted that such options potentially
	significantly increase the leaked information in the event of a		significantly increase the leaked information in the event of a
	misconfiguration.		misconfiguration.
	5.2. Data at Rest on the Server		5.2. Data at Rest on the Server
	5.2.1. Data Handling		5.2.1. Data Handling
	[RFC6973] Threats:		Threats described in [RFC6973]:
	* Surveillance.		* Surveillance.
	* Stored-data compromise.		* Stored-data compromise.
	* Correlation.		* Correlation.
	* Identification.		* Identification.
	* Secondary use.		* Secondary use.
	skipping to change at line 726 ¶		skipping to change at line 723 ¶
	individual, and the major vector for this in DNS traffic is the		individual, and the major vector for this in DNS traffic is the
	client IP address.		client IP address.
	There is active discussion in the space of effective pseudonymization		There is active discussion in the space of effective pseudonymization
	of IP addresses in DNS traffic logs; however, there seems to be no		of IP addresses in DNS traffic logs; however, there seems to be no
	single solution that is widely recognized as suitable for all or most		single solution that is widely recognized as suitable for all or most
	use cases. There are also as yet no standards for this that are		use cases. There are also as yet no standards for this that are
	unencumbered by patents.		unencumbered by patents.
	Appendix B provides a more detailed survey of various techniques		Appendix B provides a more detailed survey of various techniques
	employed or under development in 2019.		employed or under development in 2020.
	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:
	* Fingerprinting of the client OS via various means, including:		* Fingerprinting of the client OS via various means, including:
	IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit		IP TTL/Hoplimit, TCP parameters (e.g., window size, Explicit
	Congestion Notification (ECN) support, selective acknowledgment		Congestion Notification (ECN) support, selective acknowledgment
	(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		connectivity, captive portal detection, or OS-specific
	skipping to change at line 761 ¶		skipping to change at line 758 ¶
	* Resolvers _might_ receive client identifiers -- e.g., Media		* Resolvers _might_ receive client identifiers -- e.g., Media
	Access Control (MAC) addresses in EDNS(0) options. Some		Access Control (MAC) addresses in EDNS(0) options. Some
	customer premises equipment (CPE) devices are known to add them		customer premises equipment (CPE) devices are known to add them
	[MAC-address-EDNS].		[MAC-address-EDNS].
	Mitigations:		Mitigations:
	* Data minimization or discarding of such correlation data.		* Data minimization or discarding of such correlation data.
	5.2.5. Cache Snooping		5.2.5. Cache Snooping
	[RFC6973] Threats:		Threats described in [RFC6973]:
	Surveillance:		Surveillance:
	Profiling of client queries by malicious third parties.		Profiling of client queries by malicious third parties.
	Mitigations:		Mitigations:
	See [ISC-Knowledge-database-on-cache-snooping] for an example		See [ISC-Knowledge-database-on-cache-snooping] for an example
	discussion on defending against cache snooping. Options proposed		discussion on defending against cache snooping. Options proposed
	include limiting access to a server and limiting nonrecursive		include limiting access to a server and limiting nonrecursive
	queries.		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:		Threats described in [RFC6973]:
	Surveillance:		Surveillance:
	Transmission of identifying data upstream.		Transmission of identifying data upstream.
	Mitigations:		Mitigations:
	As specified in [RFC8310] for DoT but applicable to any DNS		The server should:
	privacy services, the server should:
	* implement QNAME minimization [RFC7816].		* implement QNAME minimization [RFC7816].
	* honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the		* honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
	EDNS(0) Client Subnet (ECS) option ([RFC7871], Section 7.1.2).		EDNS(0) Client Subnet (ECS) option ([RFC7871], Section 7.1.2).
			This is as specified in [RFC8310] for DoT but applicable to any
			DNS privacy service.
	Optimizations:		Optimizations:
	As per Section 2 of [RFC7871], the server should either:		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,
	skipping to change at line 820 ¶		skipping to change at line 818 ¶
	significant operational overhead compared to dynamic detection of ECS		significant operational overhead compared to dynamic detection of ECS
	support on authoritative servers.		support on authoritative servers.
	Additional options:		Additional options:
	* "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] and		* "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] and
	"NXDOMAIN: There Really Is Nothing Underneath" [RFC8020] to reduce		"NXDOMAIN: There Really Is Nothing Underneath" [RFC8020] to reduce
	the number of queries to authoritative servers to increase		the number of queries to authoritative servers to increase
	privacy.		privacy.
	* Run a copy of the root zone on loopback [RFC8806] to avoid making		* Run a local copy of the root zone [RFC8806] to avoid making
	queries to the root servers that might leak information.		queries to the root servers that might leak information.
	5.3.2. Client Query Obfuscation		5.3.2. Client Query Obfuscation
	Additional options:		Additional options:
	Since queries from recursive resolvers to authoritative servers are		Since queries from recursive resolvers to authoritative servers are
	performed using cleartext (at the time of writing), resolver services		performed using cleartext (at the time of writing), resolver services
	need to consider the extent to which they may be directly leaking		need to consider the extent to which they may be directly leaking
	information about their client community via these upstream queries		information about their client community via these upstream queries
	skipping to change at line 851 ¶		skipping to change at line 849 ¶
	recognized techniques to perform such obfuscation or bulk prefetches.		recognized techniques to perform such obfuscation or bulk prefetches.
	Another technique that particularly small operators may consider is		Another technique that particularly small operators may consider is
	forwarding local traffic to a larger resolver (with a privacy policy		forwarding local traffic to a larger resolver (with a privacy policy
	that aligns with their own practices) over an encrypted protocol, so		that aligns with their own practices) over an encrypted protocol, so
	that the upstream queries are obfuscated among those of the large		that the upstream queries are obfuscated among those of the large
	resolver.		resolver.
	5.3.3. Data Sharing		5.3.3. Data Sharing
	[RFC6973] Threats:		Threats described in [RFC6973]:
	* Surveillance.		* Surveillance.
	* Stored-data compromise.		* Stored-data compromise.
	* Correlation.		* Correlation.
	* Identification.		* Identification.
	* Secondary use.		* Secondary use.
	skipping to change at line 1179 ¶		skipping to change at line 1177 ¶
	Troncoso, "DNS Privacy not so private: the traffic		Troncoso, "DNS Privacy not so private: the traffic
	analysis perspective.", Privacy Enhancing		analysis perspective.", Privacy Enhancing
	Technologies Symposium, 2018,		Technologies Symposium, 2018,
	<https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.		<https://petsymposium.org/2018/files/hotpets/4-siby.pdf>.
	[DNS-XPF] Bellis, R., Dijk, P. V., and R. Gacogne, "DNS X-Proxied-		[DNS-XPF] Bellis, R., Dijk, P. V., and R. Gacogne, "DNS X-Proxied-
	For", Work in Progress, Internet-Draft, draft-bellis-		For", Work in Progress, Internet-Draft, draft-bellis-
	dnsop-xpf-04, 5 March 2018,		dnsop-xpf-04, 5 March 2018,
	<https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>.		<https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04>.
			[DNSCrypt] "DNSCrypt - Official Project Home Page",
			<https://www.dnscrypt.org>.
	[dnsdist] PowerDNS, "dnsdist Overview", <https://dnsdist.org>.		[dnsdist] PowerDNS, "dnsdist Overview", <https://dnsdist.org>.
	[dnstap] "dnstap", <https://dnstap.info>.		[dnstap] "dnstap", <https://dnstap.info>.
	[DoH-resolver-policy]		[DoH-resolver-policy]
	Mozilla, "Security/DOH-resolver-policy", 2019,		Mozilla, "Security/DOH-resolver-policy", 2019,
	<https://wiki.mozilla.org/Security/DOH-resolver-policy>.		<https://wiki.mozilla.org/Security/DOH-resolver-policy>.
	[dot-ALPN] IANA, "Transport Layer Security (TLS) Extensions: TLS		[dot-ALPN] IANA, "Transport Layer Security (TLS) Extensions: TLS
	Application-Layer Protocol Negotiation (ALPN) Protocol		Application-Layer Protocol Negotiation (ALPN) Protocol
	IDs", <https://www.iana.org/assignments/tls-extensiontype-		IDs", <https://www.iana.org/assignments/tls-extensiontype-
	values>.		values>.
	[Geolocation-Impact-Assessment]		[Geolocation-Impact-Assessment]
	Conversion Works, "Anonymize IP Geolocation Accuracy		Conversion Works, "Anonymize IP Geolocation Accuracy
	Impact Assessment", 2017,		Impact Assessment", 19 May 2017,
	<https://support.google.com/analytics/		<https://www.conversionworks.co.uk/blog/2017/05/19/
	answer/2763052?hl=en>.		anonymize-ip-geo-impact-test/>.
	[haproxy] "HAProxy - The Reliable, High Performance TCP/HTTP Load		[haproxy] "HAProxy - The Reliable, High Performance TCP/HTTP Load
	Balancer", <https://www.haproxy.org/>.		Balancer", <https://www.haproxy.org/>.
	[Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving		[Harvan] Harvan, M., "Prefix- and Lexicographical-order-preserving
	IP Address Anonymization", IEEE/IFIP Network Operations		IP Address Anonymization", IEEE/IFIP Network Operations
	and Management Symposium, 2006,		and Management Symposium, DOI 10.1109/NOMS.2006.1687580,
	<http://mharvan.net/talks/noms-ip_anon.pdf>.		2006, <http://mharvan.net/talks/noms-ip_anon.pdf>.
	[Internet.nl]		[Internet.nl]
	Internet.nl, "Internet.nl Is Your Internet Up To Date?",		Internet.nl, "Internet.nl Is Your Internet Up To Date?",
	2019, <https://internet.nl>.		2019, <https://internet.nl>.
	[IP-Anonymization-in-Analytics]		[IP-Anonymization-in-Analytics]
	Google, "IP Anonymization in Analytics", 2019,		Google, "IP Anonymization in Analytics", 2019,
	<https://support.google.com/analytics/		<https://support.google.com/analytics/
	answer/2763052?hl=en>.		answer/2763052?hl=en>.
	skipping to change at line 1251 ¶		skipping to change at line 1252 ¶
	Hubert, B., "Embedding MAC address in DNS requests for		Hubert, B., "Embedding MAC address in DNS requests for
	selective filtering", DNS-OARC mailing list, 25 January		selective filtering", DNS-OARC mailing list, 25 January
	2016, <https://lists.dns-oarc.net/pipermail/dns-		2016, <https://lists.dns-oarc.net/pipermail/dns-
	operations/2016-January/014143.html>.		operations/2016-January/014143.html>.
	[nginx] nginx.org, "nginx news", 2019, <https://nginx.org/>.		[nginx] nginx.org, "nginx news", 2019, <https://nginx.org/>.
	[Passive-Observations-of-a-Large-DNS]		[Passive-Observations-of-a-Large-DNS]
	de Vries, W. B., van Rijswijk-Deij, R., de Boer, P-T., and		de Vries, W. B., van Rijswijk-Deij, R., de Boer, P-T., and
	A. Pras, "Passive Observations of a Large DNS Service: 2.5		A. Pras, "Passive Observations of a Large DNS Service: 2.5
	Years in the Life of Google", 2018,		Years in the Life of Google",
			DOI 10.23919/TMA.2018.8506536, 2018,
	<http://tma.ifip.org/2018/wp-		<http://tma.ifip.org/2018/wp-
	content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.		content/uploads/sites/3/2018/06/tma2018_paper30.pdf>.
	[pcap] The Tcpdump Group, "Tcpdump & Libpcap", 2020,		[pcap] The Tcpdump Group, "Tcpdump & Libpcap", 2020,
	<https://www.tcpdump.org/>.		<https://www.tcpdump.org/>.
	[Pitfalls-of-DNS-Encryption]		[Pitfalls-of-DNS-Encryption]
	Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS		Shulman, H., "Pretty Bad Privacy: Pitfalls of DNS
	Encryption", Proceedings of the 13th Workshop on Privacy		Encryption", Proceedings of the 13th Workshop on Privacy
	in the Electronic Society, pp. 191-200,		in the Electronic Society, pp. 191-200,
	skipping to change at line 1279 ¶		skipping to change at line 1281 ¶
	Comparison+of+policy+and+privacy+statements+2019>.		Comparison+of+policy+and+privacy+statements+2019>.
	[PowerDNS-dnswasher]		[PowerDNS-dnswasher]
	PowerDNS, "dnswasher", commit 050e687, 24 April 2020,		PowerDNS, "dnswasher", commit 050e687, 24 April 2020,
	<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,		DOI 10.1109/TNET.2006.890128, 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.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<https://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<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>.
			[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
			Beijnum, "DNS64: DNS Extensions for Network Address
			Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
			DOI 10.17487/RFC6147, April 2011,
			<https://www.rfc-editor.org/info/rfc6147>.
	[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,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,		[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
	DOI 10.17487/RFC7626, August 2015,		DOI 10.17487/RFC7626, August 2015,
	skipping to change at line 1354 ¶		skipping to change at line 1362 ¶
	[stunnel] Goldlust, S., Almond, C., and F. Dupont, "DNS over TLS",		[stunnel] Goldlust, S., Almond, C., and F. Dupont, "DNS over TLS",
	ISC Knowledge Database", 1 November 2018,		ISC Knowledge Database", 1 November 2018,
	<https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.		<https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html>.
	[SURFnet-policy]		[SURFnet-policy]
	Baartmans, C., van Wynsberghe, A., van Rijswijk-Deij, R.,		Baartmans, C., van Wynsberghe, A., van Rijswijk-Deij, R.,
	and F. Jorna, "SURFnet Data Sharing Policy", June 2016,		and F. Jorna, "SURFnet Data Sharing Policy", June 2016,
	<https://surf.nl/datasharing>.		<https://surf.nl/datasharing>.
	[TCPdpriv] Ipsilon Networks, Inc., "TCPdpriv", 2005,		[tcpdpriv] Ipsilon Networks, Inc., "TCPDRIV - Program for Eliminating
	<http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html>.		Confidential Information from Traces", 2004,
			<http://fly.isti.cnr.it/software/tcpdpriv/>.
	[van-Dijkhuizen-et-al]		[van-Dijkhuizen-et-al]
	Van Dijkhuizen, N. and J. Van Der Ham, "A Survey of		Van Dijkhuizen, N. and J. Van Der Ham, "A Survey of
	Network Traffic Anonymisation Techniques and		Network Traffic Anonymisation Techniques and
	Implementations", ACM Computing Surveys,		Implementations", ACM Computing Surveys,
	DOI 10.1145/3182660, May 2018,		DOI 10.1145/3182660, May 2018,
	<https://doi.org/10.1145/3182660>.		<https://doi.org/10.1145/3182660>.
	[Xu-et-al] Fan, J., Xu, J., Ammar, M.H., and S.B. Moon, "Prefix-		[Xu-et-al] Fan, J., Xu, J., Ammar, M.H., and S.B. Moon, "Prefix-
	preserving IP address anonymization: measurement-based		preserving IP address anonymization: measurement-based
	security evaluation and a new cryptography-based scheme",		security evaluation and a new cryptography-based scheme",
	DOI 10.1016/j.comnet.2004.03.033, 2004,		DOI 10.1016/j.comnet.2004.03.033, 2004,
	<http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-		<http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
	anon.pdf>.		anon.pdf>.
	Appendix A. Documents		Appendix A. Documents
	This section provides an overview of some DNS privacy-related		This section provides an overview of some DNS privacy-related
	documents. However, this is neither an exhaustive list nor a		documents. However, this is neither an exhaustive list nor a
	definitive statement on the characteristic of the document.		definitive statement on the characteristics of any document with
			regard to potential increases or decreases in DNS privacy.
	A.1. Potential Increases in DNS Privacy		A.1. Potential Increases in DNS Privacy
	These documents are limited in scope to communications between stub		These documents are limited in scope to communications between stub
	clients and recursive resolvers:		clients and recursive resolvers:
	* "Specification for DNS over Transport Layer Security (TLS)"		* "Specification for DNS over Transport Layer Security (TLS)"
	[RFC7858].		[RFC7858].
	* "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094].		* "DNS over Datagram Transport Layer Security (DTLS)" [RFC8094].
	skipping to change at line 1554 ¶		skipping to change at line 1564 ¶
	reverse truncation) or completely (black-marker anonymization).		reverse truncation) or completely (black-marker anonymization).
	Generalization. Data is replaced by more general data with reduced		Generalization. Data is replaced by more general data with reduced
	specificity. One example would be to replace all TCP/UDP port		specificity. One example would be to replace all TCP/UDP port
	numbers with one of two fixed values indicating whether the		numbers with one of two fixed values indicating whether the
	original port was ephemeral (>=1024) or nonephemeral (>1024).		original port was ephemeral (>=1024) or nonephemeral (>1024).
	Another example, precision degradation, reduces the accuracy of,		Another example, precision degradation, reduces the accuracy of,
	for example, a numeric value or a timestamp.		for example, a numeric value or a timestamp.
	Enumeration. With data from a well-ordered set, replace the first		Enumeration. With data from a well-ordered set, replace the first
	data item data using a random initial value and then allocate		data item's data using a random initial value and then allocate
	ordered values for subsequent data items. When used with		ordered values for subsequent data items. When used with
	timestamp data, this preserves ordering but loses precision and		timestamp data, this preserves ordering but loses precision and
	distance.		distance.
	Reordering/shuffling. Preserving the original data, but rearranging		Reordering/shuffling. Preserving the original data, but rearranging
	its order, often in a random manner.		its order, often in a random manner.
	Random substitution. As replacement, but using randomly generated		Random substitution. As replacement, but using randomly generated
	replacement values.		replacement values.
	skipping to change at line 1605 ¶		skipping to change at line 1615 ¶
	addresses is translated to 0.0.0.1, the second to 0.0.0.2, and so on.		addresses is 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		The de-identified address therefore depends on the order that
	addresses arrive in the input, and when running over a large amount		addresses arrive in the input, and when running over a large amount
	of data, the address translation tables can grow to a significant		of data, the address translation tables can grow to a significant
	size.		size.
	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
	anonymized IP address pairs. When a new IP address arrives, it is		anonymized 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 TCPdpriv 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 allocate anonymized		memory requirements. The need to allocate anonymized addresses
	addresses sequentially cannot be used in parallel processing.		sequentially means that TCPdpriv 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
	proposed as an improvement to the prefix-preserving map implemented		proposed as an improvement to the prefix-preserving map implemented
	in TCPdpriv, described in [Xu-et-al] and implemented in the		in TCPdpriv, described in [Xu-et-al] and implemented in the
	[Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym		[Crypto-PAn] tool. Crypto-PAn is now frequently used as an acronym
	for the algorithm. Initially, it was described for IPv4 addresses		for the algorithm. Initially, it was described for IPv4 addresses
	skipping to change at line 1643 ¶		skipping to change at line 1654 ¶
	Pseudonymization: Format-preserving, prefix preservation (general).		Pseudonymization: Format-preserving, prefix preservation (general).
	B.2.5. Top-Hash Subtree-Replicated Anonymization		B.2.5. Top-Hash Subtree-Replicated Anonymization
	Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated		Proposed in [Ramaswamy-and-Wolf], Top-hash Subtree-replicated
	Anonymization (TSA) originated in response to the requirement for		Anonymization (TSA) originated in response to the requirement for
	faster processing than Crypto-PAn. It used hashing for the most		faster processing than Crypto-PAn. It used hashing for the most
	significant byte of an IPv4 address and a precalculated binary-tree		significant byte of an IPv4 address and a precalculated binary-tree
	structure for the remainder of the address. To save memory space,		structure for the remainder of the address. To save memory space,
	replication is used within the tree structure, reducing the size of		replication is used within the tree structure, reducing the size of
	the precalculated structures to a few Mb for IPv4 addresses. Address		the precalculated structures to a few megabytes for IPv4 addresses.
	pseudonymization is done via hash and table lookup and so requires		Address pseudonymization is done via hash and table lookup and so
	minimal computation. However, due to the much-increased address		requires minimal computation. However, due to the much-increased
	space for IPv6, TSA is not memory efficient for IPv6.		address space for IPv6, TSA is not memory efficient for IPv6.
	Pseudonymization: Format-preserving, prefix preservation (general).		Pseudonymization: Format-preserving, prefix preservation (general).
	B.2.6. ipcipher		B.2.6. ipcipher
	A recently released proposal from PowerDNS, ipcipher [ipcipher1]		A recently released proposal from PowerDNS, ipcipher [ipcipher1]
	[ipcipher2], is a simple pseudonymization technique for IPv4 and IPv6		[ipcipher2], is a simple pseudonymization technique for IPv4 and IPv6
	addresses. IPv6 addresses are encrypted directly with AES-128 using		addresses. IPv6 addresses are encrypted directly with AES-128 using
	a key (which may be derived from a passphrase). IPv4 addresses are		a key (which may be derived from a passphrase). IPv4 addresses are
	similarly encrypted, but using a recently proposed encryption		similarly encrypted, but using a recently proposed encryption
	skipping to change at line 1907 ¶		skipping to change at line 1918 ¶
	Thanks to Loganaden Velvindron for useful updates to the text.		Thanks to Loganaden Velvindron for useful updates to the text.
	Sara Dickinson thanks the Open Technology Fund for a grant to support		Sara Dickinson thanks the Open Technology Fund for a grant to support
	the work on this document.		the work on this document.
	Contributors		Contributors
	The below individuals contributed significantly to the document:		The below individuals contributed significantly to the document:
	John Dickinson		John Dickinson
	Sinodun Internet Technologies		Sinodun IT
	Magdalen Centre		Magdalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford		Oxford
	OX4 4GA		OX4 4GA
	United Kingdom		United Kingdom
	Jim Hague		Jim Hague
	Sinodun Internet Technologies		Sinodun IT
	Magdalen Centre		Magdalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford		Oxford
	OX4 4GA		OX4 4GA
	United Kingdom		United Kingdom
	Authors' Addresses		Authors' Addresses
	Sara Dickinson		Sara Dickinson
	Sinodun IT		Sinodun IT
End of changes. 34 change blocks.
	53 lines changed or deleted		64 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/