< draft-ietf-dprive-bcp-op-02.txt		draft-ietf-dprive-bcp-op-03.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: September 12, 2019 R. van Rijswijk-Deij		Expires: January 9, 2020 R. van Rijswijk-Deij
	NLnet Labs		NLnet Labs
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	March 11, 2019		July 8, 2019
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-02		draft-ietf-dprive-bcp-op-03
	Abstract		Abstract
	This document presents operational, policy and security		This document presents operational, policy and security
	considerations for DNS operators who choose to offer DNS Privacy		considerations for DNS operators who choose to offer DNS Privacy
	services. With these recommendations, the operator can make		services. With these recommendations, the operator can make
	deliberate decisions regarding which services to provide, and how the		deliberate decisions regarding which services to provide, and how the
	decisions and alternatives impact the privacy of users.		decisions and alternatives impact the privacy of users.
	This document also presents a framework to assist writers of DNS		This document also presents a framework to assist writers of DNS
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 12, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Privacy related documents . . . . . . . . . . . . . . . . . . 5		3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . 7		5.1.2. Authentication of DNS privacy services . . . . . . . 8
	5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9		5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
	5.1.4. Availability . . . . . . . . . . . . . . . . . . . . 10		5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1.5. Service options . . . . . . . . . . . . . . . . . . . 11		5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11
	5.1.6. Impact on Operators . . . . . . . . . . . . . . . . . 11		5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
	5.1.7. Limitations of using a pure TLS proxy . . . . . . . . 12		5.1.7. Impact on Operators . . . . . . . . . . . . . . . . . 12
	5.2. Data at rest on the server . . . . . . . . . . . . . . . 12		5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13
	5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 12		5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
	5.2.2. Data minimization of network traffic . . . . . . . . 13		5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
	5.2.3. IP address pseudonymization and anonymization methods 14		5.2.2. Data minimization of network traffic . . . . . . . . 14
			5.2.3. IP address pseudonymization and anonymization methods 15
	5.2.4. Pseudonymization, anonymization or discarding of		5.2.4. Pseudonymization, anonymization or discarding of
	other correlation data . . . . . . . . . . . . . . . 15		other correlation data . . . . . . . . . . . . . . . 16
	5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 16		5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
	5.3. Data sent onwards from the server . . . . . . . . . . . . 16		5.3. Data sent onwards from the server . . . . . . . . . . . . 17
	5.3.1. Protocol recommendations . . . . . . . . . . . . . . 16		5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
	5.3.2. Client query obfuscation . . . . . . . . . . . . . . 17		5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
	5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 18		5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
	6. DNS privacy policy and practice statement . . . . . . . . . . 19		6. DNS privacy policy and practice statement . . . . . . . . . . 19
	6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 19		6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 20
	6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 19		6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 20		6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Current policy and privacy statements . . . . . . . . . . 21		6.2. Current policy and privacy statements . . . . . . . . . . 22
	6.3. Enforcement/accountability . . . . . . . . . . . . . . . 21		6.3. Enforcement/accountability . . . . . . . . . . . . . . . 22
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
	8. Security considerations . . . . . . . . . . . . . . . . . . . 22		8. Security considerations . . . . . . . . . . . . . . . . . . . 23
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	12.1. Normative References . . . . . . . . . . . . . . . . . . 24		12.1. Normative References . . . . . . . . . . . . . . . . . . 25
	12.2. Informative References . . . . . . . . . . . . . . . . . 26		12.2. Informative References . . . . . . . . . . . . . . . . . 27
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 29		Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 30
	A.1. Potential increases in DNS privacy . . . . . . . . . . . 29		A.1. Potential increases in DNS privacy . . . . . . . . . . . 30
	A.2. Potential decreases in DNS privacy . . . . . . . . . . . 29		A.2. Potential decreases in DNS privacy . . . . . . . . . . . 30
	A.3. Related operational documents . . . . . . . . . . . . . . 30		A.3. Related operational documents . . . . . . . . . . . . . . 31
	Appendix B. Encryption and DNSSEC . . . . . . . . . . . . . . . 30		Appendix B. IP address techniques . . . . . . . . . . . . . . . 31
	Appendix C. IP address techniques . . . . . . . . . . . . . . . 30		B.1. Google Analytics non-prefix filtering . . . . . . . . . . 32
	C.1. Google Analytics non-prefix filtering . . . . . . . . . . 31		B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33
	C.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 32		B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 33
	C.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 32		B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 33
	C.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 32		B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34
	C.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 33		B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 34
	C.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 33		B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 34
	C.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is at the core of the Internet; almost		The Domain Name System (DNS) is at the core of the Internet; almost
	every activity on the Internet starts with a DNS query (and often		every activity on the Internet starts with a DNS query (and often
	several). However the DNS was not originally designed with strong		several). However the DNS was not originally designed with strong
	security or privacy mechanisms. A number of developments have taken		security or privacy mechanisms. A number of developments have taken
	place in recent years which aim to increase the privacy of the DNS		place in recent years which aim to increase the privacy of the DNS
	system and these are now seeing some deployment. This latest		system and these are now seeing some deployment. This latest
	evolution of the DNS presents new challenges to operators and this		evolution of the DNS presents new challenges to operators and this
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	and present a framework to assist writers of this document. A		and present a framework to assist writers of this document. A
	DPPPS is a document that an operator can publish outlining their		DPPPS is a document that an operator can publish outlining their
	operational practices and commitments with regard to privacy		operational practices and commitments with regard to privacy
	thereby providing a means for clients to evaluate the privacy		thereby providing a means for clients to evaluate the privacy
	properties of a given DNS privacy service. In particular, the		properties of a given DNS privacy service. In particular, the
	framework identifies the elements that should be considered in		framework identifies the elements that should be considered in
	formulating a DPPPS. This document does not, however, define a		formulating a DPPPS. This document does not, however, define a
	particular Policy or Practice Statement, nor does it seek to		particular Policy or Practice Statement, nor does it seek to
	provide legal advice or recommendations as to the contents.		provide legal advice or recommendations as to the contents.
			A desired operational impact is that all operators (both those
			providing resolvers within networks and those operating large anycast
			services) can demonstrate their commitment to user privacy thereby
			driving all DNS resolution services to a more equitable footing.
			Choices for users would (in this ideal world) be driven by other
			factors e.g. differing security policies or minor difference in
			operator policy rather than gross disparities in privacy concerns.
	Community insight [or judgment?] about operational practices can		Community insight [or judgment?] about operational practices can
	change quickly, and experience shows that a Best Current Practice		change quickly, and experience shows that a Best Current Practice
	(BCP) document about privacy and security is a point-in-time		(BCP) document about privacy and security is a point-in-time
	statement. Readers are advised to seek out any errata or updates		statement. Readers are advised to seek out any errata or updates
	that apply to this document.		that apply to this document.
	2. Scope		2. Scope
	"DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis]		"DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis]
	describes the general privacy issues and threats associated with the		describes the general privacy issues and threats associated with the
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 52 ¶
	It is noted that a DNS privacy service can also be provided over DNS-		It is noted that a DNS privacy service can also be provided over DNS-
	over-DTLS [RFC8094], however this is an Experimental specification		over-DTLS [RFC8094], however this is an Experimental specification
	and there are no known implementations at the time of writing.		and there are no known implementations at the time of writing.
	It is also noted that DNS privacy service might be provided over		It is also noted that DNS privacy service might be provided over
	IPSec, DNSCrypt or VPNs. However, use of these transports for DNS		IPSec, DNSCrypt or VPNs. However, use of these transports for DNS
	are not standardized and any discussion of best practice for		are not standardized and any discussion of best practice for
	providing such a service is out of scope for this document.		providing such a service is out of scope for this document.
	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 Appendix B.		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 that can redirect traffic to rogue servers		* Active attacks that can redirect traffic to rogue servers
	[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3.		[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3.
	skipping to change at page 10, line 47 ¶		skipping to change at page 11, line 9 ¶
	Mitigations:		Mitigations:
	o Clients must be able to forego the use of HTTP Cookies [RFC6265]		o Clients must be able to forego the use of HTTP Cookies [RFC6265]
	and still use the service		and still use the service
	o Clients should not be required to include any headers beyond the		o Clients should not be required to include any headers beyond the
	absolute minimum to obtain service from a DoH server. (See		absolute minimum to obtain service from a DoH server. (See
	Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)		Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)
	5.1.4. Availability		5.1.4. DNSSEC
			DNS Privacy Threats:
			o Users may be directed to bogus IP addresses for e.g. websites
			where they might reveal personal information to attackers.
			Mitigations:
			o All DNS privacy services must offer a DNS privacy service that
			performs DNSSEC validation. In addition they must be able to
			provide the DNSSEC RRs to the client so that it can perform its
			own validation.
			The addition of encryption to DNS does not remove the need for DNSSEC
			[RFC4033] - they are independent and fully compatible protocols, each
			solving different problems. The use of one does not diminish the
			need nor the usefulness of the other.
			While the use of an authenticated and encrypted transport protects
			origin authentication and data integrity between a client and a DNS
			privacy service it provides no proof (for a non-validating client)
			that the data provided by the DNS privacy service was actually DNSSEC
			authenticated. As with cleartext DNS the user is still solely
			trusting the AD bit (if present) set by the resolver.
			It should also be noted that the use of an encrypted transport for
			DNS actually solves many of the practical issues encountered by DNS
			validating clients e.g. interference by middleboxes with cleartext
			DNS payloads is completely avoided. In this sense a validating
			client that uses a DNS privacy service which supports DNSSEC has a
			far simpler task in terms of DNS Roadblock avoidance.
			5.1.5. Availability
	DNS Privacy Threats:		DNS Privacy Threats:
	o A failed DNS privacy service could force the user to switch		o A failed DNS privacy service could force the user to switch
	providers, fallback to cleartext or accept no DNS service for the		providers, fallback to cleartext or accept no DNS service for the
	outage.		outage.
	Mitigations:		Mitigations:
	A DNS privacy service must be engineered for high availability.		A DNS privacy service must be engineered for high availability.
	Particular care should to be taken to protect DNS privacy services		Particular care should to be taken to protect DNS privacy services
	against denial-of-service attacks, as experience has shown that		against denial-of-service attacks, as experience has shown that
	unavailability of DNS resolving because of attacks is a significant		unavailability of DNS resolving because of attacks is a significant
	motivation for users to switch services. See, for example		motivation for users to switch services. See, for example
	Section IV-C of Passive Observations of a Large DNS Service: 2.5		Section IV-C of Passive Observations of a Large DNS Service: 2.5
	Years in the Life of Google [3].		Years in the Life of Google [3].
	5.1.5. Service options		Techniques such as those described in Section 10 of [RFC7766] can be
			of use to operators to defend against such attacks.
			5.1.6. Service options
	DNS Privacy Threats:		DNS Privacy Threats:
	o Unfairly disadvantaging users of the privacy service with respect		o Unfairly disadvantaging users of the privacy service with respect
	to the services available. This could force the user to switch		to the services available. This could force the user to switch
	providers, fallback to cleartext or accept no DNS service for the		providers, fallback to cleartext or accept no DNS service for the
	outage.		outage.
	Mitigations:		Mitigations:
	A DNS privacy service should deliver the same level of service as		A DNS privacy service should deliver the same level of service as
	offered on un-encrypted channels in terms of such options as		offered on un-encrypted channels in terms of such options as
	filtering (or lack thereof), DNSSEC validation, etc.		filtering (or lack thereof), DNSSEC validation, etc.
	5.1.6. Impact on Operators		5.1.7. Impact on Operators
	DNS Privacy Threats:		DNS Privacy Threats:
	o Increased use of encryption impacts operator ability to manage		o Increased use of encryption impacts operator ability to manage
	their network [RFC8404]		their network [RFC8404]
	Many monitoring solutions for DNS traffic rely on the plain text		Many monitoring solutions for DNS traffic rely on the plain text
	nature of this traffic and work by intercepting traffic on the wire,		nature of this traffic and work by intercepting traffic on the wire,
	either using a separate view on the connection between clients and		either using a separate view on the connection between clients and
	the resolver, or as a separate process on the resolver system that		the resolver, or as a separate process on the resolver system that
	skipping to change at page 12, line 12 ¶		skipping to change at page 13, line 10 ¶
	relies on either the resolver software directly, or exporting DNS		relies on either the resolver software directly, or exporting DNS
	traffic from the resolver using e.g. dnstap [4].		traffic from the resolver using e.g. dnstap [4].
	Optimization:		Optimization:
	When implementing alternative means for traffic monitoring, operators		When implementing alternative means for traffic monitoring, operators
	of a DNS privacy service should consider using privacy conscious		of a DNS privacy service should consider using privacy conscious
	means to do so (see, for example, the discussion on the use of Bloom		means to do so (see, for example, the discussion on the use of Bloom
	Filters in the #documents appendix in this document).		Filters in the #documents appendix in this document).
	5.1.7. Limitations of using a pure TLS proxy		5.1.8. Limitations of using a pure TLS proxy
	DNS Privacy Threats:		DNS Privacy Threats:
	o Limited ability to manage or monitor incoming connections using		o Limited ability to manage or monitor incoming connections using
	DNS specific techniques		DNS specific techniques
	o Misconfiguration of the target server could lead to data leakage		o Misconfiguration of the target server could lead to data leakage
	if the proxy to target server path is not encrypted.		if the proxy to target server path is not encrypted.
	Optimization:		Optimization:
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 50 ¶
	5.2. Data at rest on the server		5.2. Data at rest on the server
	5.2.1. Data handling		5.2.1. Data handling
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance		o Surveillance
	o Stored data compromise		o Stored data compromise
	o Correlation
			o Correlation
	o Identification		o Identification
	o Secondary use		o Secondary use
	o Disclosure		o Disclosure
	Other Threats		Other Threats
	o Contravention of legal requirements not to process user data?		o Contravention of legal requirements not to process user data?
	skipping to change at page 15, line 14 ¶		skipping to change at page 16, line 14 ¶
	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. The following table presents a high level		unencumbered by patents. The following table presents a high level
	comparison of various techniques employed or under development today		comparison of various techniques employed or under development today
	and classifies them according to categorization of technique and		and classifies them according to categorization of technique and
	other properties. The list of techniques includes the main		other properties. The list of techniques includes the main
	techniques in current use, but does not claim to be comprehensive.		techniques in current use, but does not claim to be comprehensive.
	Appendix C provides a more detailed survey of these techniques and		Appendix B provides a more detailed survey of these techniques and
	definitions for the categories and properties listed below.		definitions for the categories and properties listed below.
	Figure showing comparison of IP address techniques (SVG) [10]		Figure showing comparison of IP address techniques (SVG) [10]
	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		be in an existing data format such as PCAP [pcap] or C-DNS
	skipping to change at page 15, line 43 ¶		skipping to change at page 16, line 43 ¶
	preserving pseudonymization is vulnerable to an attack along the		preserving pseudonymization is vulnerable to an attack along the
	lines of a cryptographic chosen plaintext attack.		lines of a cryptographic chosen plaintext attack.
	5.2.4. Pseudonymization, anonymization or discarding of other		5.2.4. Pseudonymization, anonymization or discarding of other
	correlation data		correlation data
	DNS Privacy Threats:		DNS Privacy Threats:
	o IP TTL/Hoplimit can be used to fingerprint client OS		o IP TTL/Hoplimit can be used to fingerprint client OS
			o TLS version/Cipher suite combinations can be used to fingerprint
			the client application or TLS library
	o Tracking of TCP sessions		o Tracking of TCP sessions
	o Tracking of TLS sessions and session resumption mechanisms		o Tracking of TLS sessions and session resumption mechanisms
	o Resolvers _might_ receive client identifiers e.g. MAC addresses		o Resolvers _might_ receive client identifiers e.g. MAC addresses
	in EDNS(0) options - some CPE devices are known to add them.		in EDNS(0) options - some CPE devices are known to add them.
	o HTTP headers		o HTTP headers
	Mitigations:		Mitigations:
	o Data minimization or discarding of such correlation data		o Data minimization or discarding of such correlation data.
	TODO: More analysis here.
	5.2.5. Cache snooping		5.2.5. Cache snooping
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance:		o Surveillance:
	* Profiling of client queries by malicious third parties		* Profiling of client queries by malicious third parties
	Mitigations:		Mitigations:
	o See ISC Knowledge database on cache snooping [12] for an example		o See ISC Knowledge database on cache snooping [12] for an example
	discussion on defending against cache snooping		discussion on defending against cache snooping
	TODO: Describe other techniques to defend against cache snooping
	5.3. Data sent onwards from the server		5.3. Data sent onwards from the server
	In this section we consider both data sent on the wire in upstream		In this section we consider both data sent on the wire in upstream
	queries and data shared with third parties.		queries and data shared with third parties.
	5.3.1. Protocol recommendations		5.3.1. Protocol recommendations
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance:		o Surveillance:
	skipping to change at page 18, line 26 ¶		skipping to change at page 19, line 26 ¶
	o Correlation		o Correlation
	o Identification		o Identification
	o Secondary use		o Secondary use
	o Disclosure		o Disclosure
	DNS Privacy Threats:		DNS Privacy Threats:
	o Contravention of legal requirements not to process user data?		o Contravention of legal requirements not to process user data
	Mitigations:		Mitigations:
	Operators should not provide identifiable data to third-parties		Operators should not provide identifiable data to third-parties
	without explicit consent from clients (we take the stance here that		without explicit consent from clients (we take the stance here that
	simply using the resolution service itself does not constitute		simply using the resolution service itself does not constitute
	consent).		consent).
	Even when consent is granted operators should employ data		Even when consent is granted operators should employ data
	minimization techniques such as those described in Section 5.2.1 if		minimization techniques such as those described in Section 5.2.1 if
	data is shared with third-parties.		data is shared with third-parties.
	Operators should consider including specific guidelines for the		Operators should consider including specific guidelines for the
	collection of aggregated and/or anonymized data for research		collection of aggregated and/or anonymized data for research
	purposes, within or outside of their own organization. See SURFnet's		purposes, within or outside of their own organization. This can
	policy [13] on data sharing for research as an example.		benefit not only the operator (through inclusion in novel research)
			but also the wider Internet community. See SURFnet's policy [13] on
	TODO: More on data for research vs operations... how to still		data sharing for research as an example.
	motivate operators to share anonymized data?
	TODO: Guidelines for when consent is granted?
	TODO: Applies to server data handling too.. could operators offer
	alternatives services one that implies consent for data processing,
	one that doesn't?
	6. DNS privacy policy and practice statement		6. DNS privacy policy and practice statement
	6.1. Recommended contents of a DPPPS		6.1. Recommended contents of a DPPPS
	6.1.1. Policy		6.1.1. Policy
	1. Make an explicit statement that IP addressses are treated as PII		1. Make an explicit statement that IP addressses are treated as PII
	2. State if IP addresses are being logged		2. State if IP addresses are being logged
	3. Specify clearly what data (including whether it is aggregated,		3. Specify clearly what data (including whether it is aggregated,
	pseudonymized or anonymized and the conditions of data transfer)		pseudonymized or anonymized and the conditions of data transfer)
	skipping to change at page 21, line 32 ¶		skipping to change at page 22, line 27 ¶
	A tabular comparison of existing policy and privacy statements from		A tabular comparison of existing policy and privacy statements from
	various DNS Privacy service operators based on the proposed DPPPS		various DNS Privacy service operators based on the proposed DPPPS
	structure can be found on dnsprivacy.org [14].		structure can be found on dnsprivacy.org [14].
	We note that the existing set of policies vary widely in style,		We note that the existing set of policies vary widely in style,
	content and detail and it is not uncommon for the full text for a		content and detail and it is not uncommon for the full text for a
	given operator to equate to more than 10 pages of moderate font sized		given operator to equate to more than 10 pages of moderate font sized
	A4 text. It is a non-trivial task today for a user to extract a		A4 text. It is a non-trivial task today for a user to extract a
	meaningful overview of the different services on offer.		meaningful overview of the different services on offer.
			It is also noted that Mozilla have published a Security/DoH-resolver
			policy [15], which describes the minimum set of policy requirements
			that a party must satisfy to be considered as a potential partner for
			Mozilla's Trusted Recursive Resolver (TRR) program.
	6.3. Enforcement/accountability		6.3. Enforcement/accountability
	Transparency reports may help with building user trust that operators		Transparency reports may help with building user trust that operators
	adhere to their policies and practices.		adhere to their policies and practices.
	Independent monitoring or analysis could be performed where possible		Independent monitoring or analysis could be performed where possible
	of:		of:
	o ECS, QNAME minimization, EDNS(0) padding, etc.		o ECS, QNAME minimization, EDNS(0) padding, etc.
	o Filtering		o Filtering
	o Uptime		o Uptime
	This is by analogy with e.g. several TLS or website analysis tools		This is by analogy with e.g. several TLS or website analysis tools
	that are currently available e.g. SSL Labs [15] or Internet.nl [16].		that are currently available e.g. SSL Labs [16] or Internet.nl [17].
	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 DPPPS.		party auditor to verify their compliance with their published DPPPS.
	7. IANA considerations		7. IANA considerations
	None		None
	8. Security considerations		8. Security considerations
	skipping to change at page 22, line 48 ¶		skipping to change at page 23, line 48 ¶
	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-03
			o Add paragraph about operational impact
			o Move DNSSEC requirement out of the Appendix into main text as a
			privacy threat that should be mitigated
			o Add TLS version/Cipher suite as tracking threat
			o Add reference to Mozilla TRR policy
			o Remove several TODOs and QUESTIONS.
	draft-ietf-dprive-bcp-op-02		draft-ietf-dprive-bcp-op-02
	o Change 'open resolver' for 'public resolver'		o Change 'open resolver' for 'public resolver'
	o Minor editorial changes		o Minor editorial changes
	o Remove recommendation to run a separate TLS 1.3 service		o Remove recommendation to run a separate TLS 1.3 service
	o Move TLSA to purely a optimisation in Section 5.2.1		o Move TLSA to purely a optimisation in Section 5.2.1
	o Update reference on minimal DoH headers.		o Update reference on minimal DoH headers.
	o Add reference on user switching provider after service issues in		o Add reference on user switching provider after service issues in
	Section 5.1.4		Section 5.1.4
	o Add text in Section 5.1.6 on impact on operators.		o Add text in Section 5.1.6 on impact on operators.
	skipping to change at page 26, line 25 ¶		skipping to change at page 27, line 33 ¶
	[I-D.ietf-dnsop-dns-capture-format]		[I-D.ietf-dnsop-dns-capture-format]
	Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,		Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
	and J. Bond, "C-DNS: A DNS Packet Capture Format", draft-		and J. Bond, "C-DNS: A DNS Packet Capture Format", draft-
	ietf-dnsop-dns-capture-format-10 (work in progress),		ietf-dnsop-dns-capture-format-10 (work in progress),
	December 2018.		December 2018.
	[I-D.ietf-dnsop-dns-tcp-requirements]		[I-D.ietf-dnsop-dns-tcp-requirements]
	Kristoff, J. and D. Wessels, "DNS Transport over TCP -		Kristoff, J. and D. Wessels, "DNS Transport over TCP -
	Operational Requirements", draft-ietf-dnsop-dns-tcp-		Operational Requirements", draft-ietf-dnsop-dns-tcp-
	requirements-03 (work in progress), January 2019.		requirements-04 (work in progress), June 2019.
	[I-D.ietf-dnsop-terminology-bis]		[I-D.ietf-dnsop-terminology-bis]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", draft-ietf-dnsop-terminology-bis-14 (work in		Terminology", draft-ietf-dnsop-terminology-bis-14 (work in
	progress), September 2018.		progress), September 2018.
	[I-D.ietf-httpbis-bcp56bis]		[I-D.ietf-httpbis-bcp56bis]
	Nottingham, M., "Building Protocols with HTTP", draft-		Nottingham, M., "Building Protocols with HTTP", draft-
	ietf-httpbis-bcp56bis-08 (work in progress), November		ietf-httpbis-bcp56bis-08 (work in progress), November
	2018.		2018.
	skipping to change at page 28, line 20 ¶		skipping to change at page 29, line 28 ¶
	[11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16		[11] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda16
	4fb2138a44.pdf		4fb2138a44.pdf
	[12] https://kb.isc.org/docs/aa-00482		[12] https://kb.isc.org/docs/aa-00482
	[13] https://surf.nl/datasharing		[13] https://surf.nl/datasharing
	[14] https://dnsprivacy.org/wiki/display/DP/		[14] https://dnsprivacy.org/wiki/display/DP/
	Comparison+of+policy+and+privacy+statements		Comparison+of+policy+and+privacy+statements
	[15] https://www.ssllabs.com/ssltest/		[15] https://wiki.mozilla.org/Security/DOH-resolver-policy
	[16] https://internet.nl		[16] https://www.ssllabs.com/ssltest/
	[17] https://support.google.com/analytics/answer/2763052?hl=en		[17] https://internet.nl
	[18] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-		[18] https://support.google.com/analytics/answer/2763052?hl=en
			[19] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-
	geo-impact-test/		geo-impact-test/
	[19] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc		[20] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc
	[20] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html		[21] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html
	[21] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-		[22] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
	anon.pdf		anon.pdf
	[22] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/		[23] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/
	[23] http://mharvan.net/talks/noms-ip_anon.pdf		[24] http://mharvan.net/talks/noms-ip_anon.pdf
	[24] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf		[25] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf
	[25] https://medium.com/@bert.hubert/on-ip-address-encryption-		[26] https://medium.com/@bert.hubert/on-ip-address-encryption-
	security-analysis-with-respect-for-privacy-dabe1201b476		security-analysis-with-respect-for-privacy-dabe1201b476
	[26] https://github.com/PowerDNS/ipcipher		[27] https://github.com/PowerDNS/ipcipher
	[27] https://github.com/veorq/ipcrypt		[28] https://github.com/veorq/ipcrypt
	[28] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html		[29] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html
	[29] https://tnc18.geant.org/core/presentation/127		[30] http://dl.ifip.org/db/conf/im/im2019/189282.pdf
	Appendix A. Documents		Appendix A. Documents
	This section provides an overview of some DNS privacy related		This section provides an overview of some DNS privacy related
	documents, however, this is neither an exhaustive list nor a		documents, however, this is neither an exhaustive list nor a
	definitive statement on the characteristic of the document.		definitive statement on the characteristic of the document.
	A.1. Potential increases in DNS privacy		A.1. Potential increases in DNS privacy
	These documents are limited in scope to communications between stub		These documents are limited in scope to communications between stub
	skipping to change at page 29, line 42 ¶		skipping to change at page 31, line 4 ¶
	o 'DNS Query Name minimization to Improve Privacy' [RFC7816]		o 'DNS Query Name minimization to Improve Privacy' [RFC7816]
	referred to here as 'QNAME minimization'		referred to here as 'QNAME minimization'
	A.2. Potential decreases in DNS privacy		A.2. Potential decreases in DNS privacy
	These documents relate to functionality that could provide increased		These documents relate to functionality that could provide increased
	tracking of user activity as a side effect:		tracking of user activity as a side effect:
	o 'Client Subnet in DNS Queries' [RFC7871]		o 'Client Subnet in DNS Queries' [RFC7871]
	o 'Domain Name System (DNS) Cookies' [RFC7873])		o 'Domain Name System (DNS) Cookies' [RFC7873])
	o 'Transport Layer Security (TLS) Session Resumption without Server-		o 'Transport Layer Security (TLS) Session Resumption without Server-
	Side State' [RFC5077] referred to here as simply TLS session		Side State' [RFC5077] referred to here as simply TLS session
	resumption.		resumption.
	o 'A DNS Packet Capture Format' [I-D.ietf-dnsop-dns-capture-format]		o 'A DNS Packet Capture Format' [I-D.ietf-dnsop-dns-capture-format]
	o Passive DNS [I-D.ietf-dnsop-terminology-bis]		o Passive DNS [I-D.ietf-dnsop-terminology-bis]
	Note that depending on the specifics of the implementation [RFC8484]		Note that depending on the specifics of the implementation [RFC8484]
	may also provide increased tracking.		may also provide increased tracking.
	A.3. Related operational documents		A.3. Related operational documents
	o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]		o 'DNS Transport over TCP - Implementation Requirements' [RFC7766]
	o 'Operational requirements for DNS-over-TCP'		o 'Operational requirements for DNS-over-TCP'
	[I-D.ietf-dnsop-dns-tcp-requirements]		[I-D.ietf-dnsop-dns-tcp-requirements]
	o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]		o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828]
	o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal]		o 'DNS Stateful Operations' [I-D.ietf-dnsop-session-signal]
	Appendix B. Encryption and DNSSEC		Appendix B. IP address techniques
	The addition of encryption to DNS does not remove the need for DNSSEC
	[RFC4033] - they are independent and fully compatible protocols, each
	solving different problems. The use of one does not diminish the
	need nor the usefulness of the other.
	All DNS privacy services SHOULD offer a DNS privacy service that
	performs DNSSEC validation. In addition they SHOULD be able to
	provide the DNSSEC RRs to the client so that it can perform its own
	validation.
	While the use of an authenticated and encrypted transport protects
	origin authentication and data integrity between a client and a DNS
	privacy service it provides no proof (for a non-validating client)
	that the data provided by the DNS privacy service was actually DNSSEC
	authenticated.
	Appendix C. IP address techniques
	Data minimization methods may be categorized by the processing used		Data minimization methods may be categorized by the processing used
	and the properties of their outputs. The following builds on the		and the properties of their outputs. The following builds on the
	categorization employed in [RFC6235]:		categorization employed in [RFC6235]:
	o Format-preserving. Normally when encrypting, the original data		o Format-preserving. Normally when encrypting, the original data
	length and patterns in the data should be hidden from an attacker.		length and patterns in the data should be hidden from an attacker.
	Some applications of de-identification, such as network capture		Some applications of de-identification, such as network capture
	de-identification, require that the de-identified data is of the		de-identification, require that the de-identified data is of the
	same form as the original data, to allow the data to be parsed in		same form as the original data, to allow the data to be parsed in
	skipping to change at page 31, line 41 ¶		skipping to change at page 32, line 35 ¶
	o Reordering/shuffling. Preserving the original data, but		o Reordering/shuffling. Preserving the original data, but
	rearranging its order, often in a random manner.		rearranging its order, often in a random manner.
	o Random substitution. As replacement, but using randomly generated		o Random substitution. As replacement, but using randomly generated
	replacement values.		replacement values.
	o Cryptographic permutation. Using a permutation function, such as		o Cryptographic permutation. Using a permutation function, such as
	a hash function or cryptographic block cipher, to generate a		a hash function or cryptographic block cipher, to generate a
	replacement de-identified value.		replacement de-identified value.
	C.1. Google Analytics non-prefix filtering		B.1. Google Analytics non-prefix filtering
	Since May 2010, Google Analytics has provided a facility [17] that		Since May 2010, Google Analytics has provided a facility [18] that
	allows website owners to request that all their users IP addresses		allows website owners to request that all their users IP addresses
	are anonymized within Google Analytics processing. This very basic		are anonymized within Google Analytics processing. This very basic
	anonymization simply sets to zero the least significant 8 bits of		anonymization simply sets to zero the least significant 8 bits of
	IPv4 addresses, and the least significant 80 bits of IPv6 addresses.		IPv4 addresses, and the least significant 80 bits of IPv6 addresses.
	The level of anonymization this produces is perhaps questionable.		The level of anonymization this produces is perhaps questionable.
	There are some analysis results [18] which suggest that the impact of		There are some analysis results [19] which suggest that the impact of
	this on reducing the accuracy of determining the user's location from		this on reducing the accuracy of determining the user's location from
	their IP address is less than might be hoped; the average discrepancy		their IP address is less than might be hoped; the average discrepancy
	in identification of the user city for UK users is no more than 17%.		in identification of the user city for UK users is no more than 17%.
	Anonymization: Format-preserving, Filtering (grey marking).		Anonymization: Format-preserving, Filtering (grey marking).
	C.2. dnswasher		B.2. dnswasher
	Since 2006, PowerDNS have included a de-identification tool dnswasher		Since 2006, PowerDNS have included a de-identification tool dnswasher
	[19] with their PowerDNS product. This is a PCAP filter that		[20] with their PowerDNS product. This is a PCAP filter that
	performs a one-to-one mapping of end user IP addresses with an		performs a one-to-one mapping of end user IP addresses with an
	anonymized address. A table of user IP addresses and their de-		anonymized address. A table of user IP addresses and their de-
	identified counterparts is kept; the first IPv4 user addresses is		identified counterparts is kept; the first IPv4 user addresses is
	translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de-		translated to 0.0.0.1, the second to 0.0.0.2 and so on. The de-
	identified address therefore depends on the order that addresses		identified address therefore depends on the order that addresses
	arrive in the input, and running over a large amount of data the		arrive in the input, and running over a large amount of data the
	address translation tables can grow to a significant size.		address translation tables can grow to a significant size.
	Anonymization: Format-preserving, Enumeration.		Anonymization: Format-preserving, Enumeration.
	C.3. Prefix-preserving map		B.3. Prefix-preserving map
	Used in TCPdpriv [20], this algorithm stores a set of original and		Used in TCPdpriv [21], this algorithm stores a set of original and
	anonymised IP address pairs. When a new IP address arrives, it is		anonymised IP address pairs. When a new IP address arrives, it is
	compared with previous addresses to determine the longest prefix		compared with previous addresses to determine the longest prefix
	match. The new address is anonymized by using the same prefix, with		match. The new address is anonymized by using the same prefix, with
	the remainder of the address anonymized with a random value. The use		the remainder of the address anonymized with a random value. The use
	of a random value means that TCPdrpiv is not deterministic; different		of a random value means that TCPdrpiv is not deterministic; different
	anonymized values will be generated on each run. The need to store		anonymized values will be generated on each run. The need to store
	previous addresses means that TCPdpriv has significant and unbounded		previous addresses means that TCPdpriv has significant and unbounded
	memory requirements, and because of the need to allocated anonymized		memory requirements, and because of the need to allocated anonymized
	addresses sequentially cannot be used in parallel processing.		addresses sequentially cannot be used in parallel processing.
	Anonymization: Format-preserving, prefix preservation (general).		Anonymization: Format-preserving, prefix preservation (general).
	C.4. Cryptographic Prefix-Preserving Pseudonymisation		B.4. Cryptographic Prefix-Preserving Pseudonymisation
	Cryptographic prefix-preserving pseudonymisation was originally		Cryptographic prefix-preserving pseudonymisation was originally
	proposed as an improvement to the prefix-preserving map implemented		proposed as an improvement to the prefix-preserving map implemented
	in TCPdpriv, described in Xu et al. [21] and implemented in the		in TCPdpriv, described in Xu et al. [22] and implemented in the
	Crypto-PAn tool [22]. Crypto-PAn is now frequently used as an		Crypto-PAn tool [23]. Crypto-PAn is now frequently used as an
	acronym for the algorithm. Initially it was described for IPv4		acronym for the algorithm. Initially it was described for IPv4
	addresses only; extension for IPv6 addresses was proposed in Harvan &		addresses only; extension for IPv6 addresses was proposed in Harvan &
	Schoenwaelder [23] and implemented in snmpdump. This uses a		Schoenwaelder [24] and implemented in snmpdump. This uses a
	cryptographic algorithm rather than a random value, and thus		cryptographic algorithm rather than a random value, and thus
	pseudonymity is determined uniquely by the encryption key, and is		pseudonymity is determined uniquely by the encryption key, and is
	deterministic. It requires a separate AES encryption for each output		deterministic. It requires a separate AES encryption for each output
	bit, so has a non-trivial calculation overhead. This can be		bit, so has a non-trivial calculation overhead. This can be
	mitigated to some extent (for IPv4, at least) by pre-calculating		mitigated to some extent (for IPv4, at least) by pre-calculating
	results for some number of prefix bits.		results for some number of prefix bits.
	Pseudonymization: Format-preserving, prefix preservation (general).		Pseudonymization: Format-preserving, prefix preservation (general).
	C.5. Top-hash Subtree-replicated Anonymisation		B.5. Top-hash Subtree-replicated Anonymisation
	Proposed in Ramaswamy & Wolf [24], Top-hash Subtree-replicated		Proposed in Ramaswamy & Wolf [25], Top-hash Subtree-replicated
	Anonymisation (TSA) originated in response to the requirement for		Anonymisation (TSA) originated in response to the requirement for
	faster processing than Crypto-PAn. It used hashing for the most		faster processing than Crypto-PAn. It used hashing for the most
	significant byte of an IPv4 address, and a pre-calculated binary tree		significant byte of an IPv4 address, and a pre-calculated binary tree
	structure for the remainder of the address. To save memory space,		structure for the remainder of the address. To save memory space,
	replication is used within the tree structure, reducing the size of		replication is used within the tree structure, reducing the size of
	the pre-calculated structures to a few Mb for IPv4 addresses.		the pre-calculated structures to a few Mb for IPv4 addresses.
	Address pseudonymization is done via hash and table lookup, and so		Address pseudonymization is done via hash and table lookup, and so
	requires minimal computation. However, due to the much increased		requires minimal computation. However, due to the much increased
	address space for IPv6, TSA is not memory efficient for IPv6.		address space for IPv6, TSA is not memory efficient for IPv6.
	Pseudonymization: Format-preserving, prefix preservation (general).		Pseudonymization: Format-preserving, prefix preservation (general).
	C.6. ipcipher		B.6. ipcipher
	A recently-released proposal from PowerDNS [25], ipcipher [26] is a		A recently-released proposal from PowerDNS [26], ipcipher [27] is a
	simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6		simple pseudonymization technique for IPv4 and IPv6 addresses. IPv6
	addresses are encrypted directly with AES-128 using a key (which may		addresses are encrypted directly with AES-128 using a key (which may
	be derived from a passphrase). IPv4 addresses are similarly		be derived from a passphrase). IPv4 addresses are similarly
	encrypted, but using a recently proposed encryption ipcrypt [27]		encrypted, but using a recently proposed encryption ipcrypt [28]
	suitable for 32bit block lengths. However, the author of ipcrypt has		suitable for 32bit block lengths. However, the author of ipcrypt has
	since indicated [28] that it has low security, and further analysis		since indicated [29] that it has low security, and further analysis
	has revealed it is vulnerable to attack.		has revealed it is vulnerable to attack.
	Pseudonymization: Format-preserving, cryptographic permutation.		Pseudonymization: Format-preserving, cryptographic permutation.
	C.7. Bloom filters		B.7. Bloom filters
	van Rijswijk-Deij et al. [29] have recently described work using		van Rijswijk-Deij et al. [30] have recently described work using
	Bloom filters to categorize query traffic and record the traffic as		Bloom filters to categorize query traffic and record the traffic as
	the state of multiple filters. The goal of this work is to allow		the state of multiple filters. The goal of this work is to allow
	operators to identify so-called Indicators of Compromise (IOCs)		operators to identify so-called Indicators of Compromise (IOCs)
	originating from specific subnets without storing information about,		originating from specific subnets without storing information about,
	or be able to monitor the DNS queries of an individual user. By		or be able to monitor the DNS queries of an individual user. By
	using a Bloom filter, it is possible to determine with a high		using a Bloom filter, it is possible to determine with a high
	probability if, for example, a particular query was made, but the set		probability if, for example, a particular query was made, but the set
	of queries made cannot be recovered from the filter. Similarly, by		of queries made cannot be recovered from the filter. Similarly, by
	mixing queries from a sufficient number of users in a single filter,		mixing queries from a sufficient number of users in a single filter,
	it becomes practically impossible to determine if a particular user		it becomes practically impossible to determine if a particular user
End of changes. 65 change blocks.
	129 lines changed or deleted		166 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/