< draft-ietf-dprive-bcp-op-00.txt		draft-ietf-dprive-bcp-op-01.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: February 9, 2019 NLnet Labs		Expires: June 21, 2019 R. van Rijswijk-Deij
	R. van Rijswijk-Deij		NLnet Labs
	SURFnet bv
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	August 8, 2018		December 18, 2018
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-00		draft-ietf-dprive-bcp-op-01
	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 the recommendations, the operator can make deliberate		services. With these recommendations, the operator can make
	decisions which services to provide, and how the decisions and		deliberate decisions regarding which services to provide, and how the
	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
	Privacy Policy and Practices Statements (analogous to DNS Security		Privacy Policy and Practices Statements (analogous to DNS Security
	Extensions (DNSSEC) Policies and DNSSEC Practice Statements described		Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
	in [RFC6841]).		in [RFC6841]).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://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 February 9, 2019.		This Internet-Draft will expire on June 21, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Privacy related documents . . . . . . . . . . . . . . . . . . 5		3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . 8		5.1.2. Authentication of DNS privacy services . . . . . . . 7
	5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9		5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
	5.1.4. Availability . . . . . . . . . . . . . . . . . . . . 10		5.1.4. Availability . . . . . . . . . . . . . . . . . . . . 11
	5.1.5. Service options . . . . . . . . . . . . . . . . . . . 11		5.1.5. Service options . . . . . . . . . . . . . . . . . . . 11
	5.1.6. Limitations of using a pure TLS proxy . . . . . . . . 11		5.1.6. Impact on Operators . . . . . . . . . . . . . . . . . 11
			5.1.7. Limitations of using a pure TLS proxy . . . . . . . . 11
	5.2. Data at rest on the server . . . . . . . . . . . . . . . 12		5.2. Data at rest on the server . . . . . . . . . . . . . . . 12
	5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 12		5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 12
	5.2.2. Data minimization of network traffic . . . . . . . . 13		5.2.2. Data minimization of network traffic . . . . . . . . 13
	5.2.3. IP address pseudonymization and anonymization methods 14		5.2.3. IP address pseudonymization and anonymization methods 14
	5.2.4. Pseudonymization, anonymization or discarding of		5.2.4. Pseudonymization, anonymization or discarding of
	other correlation data . . . . . . . . . . . . . . . 14		other correlation data . . . . . . . . . . . . . . . 15
	5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 15		5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 15
	5.3. Data sent onwards from the server . . . . . . . . . . . . 15		5.3. Data sent onwards from the server . . . . . . . . . . . . 16
	5.3.1. Protocol recommendations . . . . . . . . . . . . . . 15		5.3.1. Protocol recommendations . . . . . . . . . . . . . . 16
	5.3.2. Client query obfuscation . . . . . . . . . . . . . . 16		5.3.2. Client query obfuscation . . . . . . . . . . . . . . 17
	5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 17		5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 17
	6. DNS privacy policy and practice statement . . . . . . . . . . 17		6. DNS privacy policy and practice statement . . . . . . . . . . 18
	6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 18		6.1. Recommended contents of a DPPPS . . . . . . . . . . . . . 18
	6.2. Current policy and privacy statements . . . . . . . . . . 19		6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.1. Quad9 . . . . . . . . . . . . . . . . . . . . . . . . 19		6.1.2. Practice. . . . . . . . . . . . . . . . . . . . . . . 19
	6.2.2. Cloudflare . . . . . . . . . . . . . . . . . . . . . 19		6.2. Current policy and privacy statements . . . . . . . . . . 20
	6.2.3. Google . . . . . . . . . . . . . . . . . . . . . . . 20		6.3. Enforcement/accountability . . . . . . . . . . . . . . . 21
	6.2.4. OpenDNS . . . . . . . . . . . . . . . . . . . . . . . 20
	6.2.5. Comparison . . . . . . . . . . . . . . . . . . . . . 20
	6.3. Enforcement/accountability . . . . . . . . . . . . . . . 20
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
	8. Security considerations . . . . . . . . . . . . . . . . . . . 21		8. Security considerations . . . . . . . . . . . . . . . . . . . 21
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	12.1. Normative References . . . . . . . . . . . . . . . . . . 22		12.1. Normative References . . . . . . . . . . . . . . . . . . 23
	12.2. Informative References . . . . . . . . . . . . . . . . . 23		12.2. Informative References . . . . . . . . . . . . . . . . . 25
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 26		Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 27
	A.1. Potential increases in DNS privacy . . . . . . . . . . . 26		A.1. Potential increases in DNS privacy . . . . . . . . . . . 27
	A.2. Potential decreases in DNS privacy . . . . . . . . . . . 27		A.2. Potential decreases in DNS privacy . . . . . . . . . . . 28
	A.3. Related operational documents . . . . . . . . . . . . . . 27		A.3. Related operational documents . . . . . . . . . . . . . . 28
	Appendix B. IP address techniques . . . . . . . . . . . . . . . 27		Appendix B. Encryption and DNSSEC . . . . . . . . . . . . . . . 29
	B.1. Google Analytics non-prefix filtering . . . . . . . . . . 28		Appendix C. IP address techniques . . . . . . . . . . . . . . . 29
	B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 29		C.1. Google Analytics non-prefix filtering . . . . . . . . . . 30
	B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 29		C.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 30
	B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 29		C.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 31
	B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 30		C.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 31
	B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 30		C.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 31
	B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 30		C.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		C.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 32
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	[NOTE: This document is submitted to the IETF for initial review and
	for feedback on the best forum for future versions of this document.
	Initial considerations for DoH [I-D.ietf-doh-dns-over-https] are
	included here in anticipation of that draft progressing to be an RFC
	but further analysis is required.]
	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
	document attempts to provide an overview of considerations for		document attempts to provide an overview of considerations for
	privacy focussed DNS services.		privacy focused DNS services.
	In recent years there has also been an increase in the availability		In recent years there has also been an increase in the availability
	of "open resolvers" [I-D.ietf-dnsop-terminology-bis] which users may		of "open resolvers" [I-D.ietf-dnsop-terminology-bis] which users may
	prefer to use instead of the default network resolver because they		prefer to use instead of the default network resolver because they
	offer a specific feature (e.g. good reachability, encrypted		offer a specific feature (e.g. good reachability, encrypted
	transport, strong privacy policy, filtering (or lack of), etc.).		transport, strong privacy policy, filtering (or lack of), etc.).
	These open resolvers have tended to be at the forefront of adoption		These open resolvers have tended to be at the forefront of adoption
	of privacy related enhancements but it is anticipated that operators		of privacy related enhancements but it is anticipated that operators
	of other resolver services will follow.		of other resolver services will follow.
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 17 ¶
	transport to use in all network environments has both advantages and		transport to use in all network environments has both advantages and
	disadvantages. For example the user has a clear expectation of which		disadvantages. For example the user has a clear expectation of which
	resolvers have visibility of their query data however this resolver/		resolvers have visibility of their query data however this resolver/
	transport selection may provide an added mechanism to track them as		transport selection may provide an added mechanism to track them as
	they move across network environments. Commitments from operators to		they move across network environments. Commitments from operators to
	minimize such tracking are also likely to play a role in users		minimize such tracking are also likely to play a role in users
	selection of resolver.		selection of resolver.
	More recently the global legislative landscape with regard to		More recently the global legislative landscape with regard to
	personal data collection, retention, and pseudonymization has seen		personal data collection, retention, and pseudonymization has seen
	significant activity with differing requirements active in different		significant activity. It is an untested area that simply using a DNS
	jurisdictions. For example the user of a service and the service		resolution service constitutes consent from the user for the operator
	itself may be in jurisdictions with conflicting legislation. It is		to process their query data. The impact of recent legislative
	an untested area that simply using a DNS resolution service		changes on data pertaining to the users of both Internet Service
	constitutes consent from the user for the operator to process their		Providers and DNS open resolvers is not fully understood at the time
	query data. The impact of recent legislative changes on data		of writing.
	pertaining to the users of both Internet Service Providers and DNS
	open resolvers is not fully understood at the time of writing.
	This document has two main goals:		This document has two main goals:
	o To provide operational and policy guidance related to DNS over		o To provide operational and policy guidance related to DNS over
	encrypted transports and to outline recommendations for data		encrypted transports and to outline recommendations for data
	handling for operators of DNS privacy services.		handling for operators of DNS privacy services.
	o To introduce the DNS Privacy Policy and Practice Statement (DPPPS)		o To introduce the DNS Privacy Policy and Practice Statement (DPPPS)
	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
	skipping to change at page 5, line 18 ¶		skipping to change at page 4, line 52 ¶
	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
	use of the DNS by Internet users and much of the threat analysis here		use of the DNS by Internet users and much of the threat analysis here
	is lifted from that document and from [RFC6873]. However this		is lifted from that document and from [RFC6973]. However this
	document is limited in scope to best practice considerations for the		document is limited in scope to best practice considerations for the
	provision of DNS privacy services by servers (recursive resolvers) to		provision of DNS privacy services by servers (recursive resolvers) to
	clients (stub resolvers or forwarders). Privacy considerations		clients (stub resolvers or forwarders). Privacy considerations
	specifically from the perspective of an end user, or those for		specifically from the perspective of an end user, or those for
	operators of authoritative nameservers are out of scope.		operators of authoritative nameservers are out of scope.
	This document includes (but is not limited to) considerations in the		This document includes (but is not limited to) considerations in the
	following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]):		following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]):
	1. Data "on the wire" between a client and a server		1. Data "on the wire" between a client and a server
	skipping to change at page 6, line 10 ¶		skipping to change at page 5, line 42 ¶
	benefits at the price of a reduction in privacy and conversely some		benefits at the price of a reduction in privacy and conversely some
	features increase privacy with an accompanying increase in		features increase privacy with an accompanying increase in
	complexity. A selection of the most relevant documents are listed in		complexity. A selection of the most relevant documents are listed in
	Appendix A for reference.		Appendix A for reference.
	4. Terminology		4. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] and [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Privacy terminology is as described in Section 3 of [RFC6973].
	DNS terminology is as described in [I-D.ietf-dnsop-terminology-bis]		DNS terminology is as described in [I-D.ietf-dnsop-terminology-bis]
	with one modification: we use the definition of Privacy-enabling DNS		with one modification: we restate the clause in the original
	server taken from [RFC8310]:		definition of Privacy-enabling DNS server in [RFC8310] to include the
			requirement that a DNS over (D)TLS server should also offer at least
	o Privacy-enabling DNS server: A DNS server (most likely a full-		one of the credentials described in Section 8 and implement the
	service resolver) that implements DNS-over-TLS [RFC7858], and may		(D)TLS profile described in Section 9 of [RFC8310].
	optionally implement DNS-over-DTLS [RFC8094]. The server should
	also offer at least one of the credentials described in Section 8
	and implement the (D)TLS profile described in Section 9.
	TODO: Update the definition of Privacy-enabling DNS server in		Other Terms:
	[I-D.ietf-dnsop-terminology-bis] to be complete and also include DoH,
	then reference that here.
	o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6.		o DPPPS: DNS Privacy Policy and Practice Statement, see Section 6.
	o DNS privacy service: The service that is offered via a privacy-		o DNS privacy service: The service that is offered via a privacy-
	enabling DNS server and is documented either in an informal		enabling DNS server and is documented either in an informal
	statement of policy and practice with regard to users privacy or a		statement of policy and practice with regard to users privacy or a
	formal DPPPS.		formal DPPPS.
	5. Recommendations for DNS privacy services		5. Recommendations for DNS privacy services
			We describe two classes of threats:
			o 'Privacy Considerations for Internet Protocols' [RFC6973] Threats
			* Privacy terminology, threats to privacy and mitigations are
			described in Sections 3, 5 and 6 of [RFC6973].
			o DNS Privacy Threats
			* These are threats to the users and operators of DNS privacy
			services that are not directly covered by [RFC6973]. These may
			be more operational in nature such as certificate management or
			service availability issues.
	We describe three classes of actions that operators of DNS privacy		We describe three classes of actions that operators of DNS privacy
	services can take:		services can take:
	o Threat mitigation for well understood and documented privacy		o Threat mitigation for well understood and documented privacy
	threats to the users of the service and in some cases to the		threats to the users of the service and in some cases to the
	operators of the service.		operators of the service.
	o Optimization of privacy services from an operational or management		o Optimization of privacy services from an operational or management
	perspective		perspective
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 5 ¶
	This document does not specify policy only best practice, however for		This document does not specify policy only best practice, however for
	DNS Privacy services to be considered compliant with these best		DNS Privacy services to be considered compliant with these best
	practice guidelines they SHOULD implement (where appropriate) all:		practice guidelines they SHOULD implement (where appropriate) all:
	o Threat mitigations to be minimally compliant		o Threat mitigations to be minimally compliant
	o Optimizations to be moderately compliant		o Optimizations to be moderately compliant
	o Additional options to be maximally compliant		o Additional options to be maximally compliant
	TODO: Some of the threats listed in the following sections are taken
	directly from Section 5 of RFC6973, some are just standalone
	descriptions, we need to go through all of them and see if we can use
	the RFC6973 threats where possible and make them consistent.
	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
	Threats:		[RFC6973] Threats:
	o Surveillance: Passive surveillance of traffic on the wire		o Surveillance:
	o Intrusion: Active injection of spurious data or traffic		* Passive surveillance of traffic on the wire
			[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.4.2.
			DNS Privacy Threats:
			o Active injection of spurious data or traffic
	Mitigations:		Mitigations:
	A DNS privacy service can mitigate these threats by providing service		A DNS privacy service can mitigate these threats by providing service
	over one or more of the following transports		over one or more of the following transports
	o DNS-over-TLS [RFC7858]		o DNS-over-TLS [RFC7858] and [RFC8310]
	o DoH [I-D.ietf-doh-dns-over-https]		o DoH [RFC8484]
	Additional options:		It is noted that a DNS privacy service can also be provided over DNS-
			over-DTLS [RFC8094], however this is an Experimental specification
			and there are no known implementations at the time of writing.
	o A DNS privacy service can also be provided over DNS-over-DTLS		It is also noted that DNS privacy service might be provided over
	[RFC8094], however note that this is an Experimental		IPSec, DNSCrypt or VPNs. However, use of these transports for DNS
	specification.		are not standardized and any discussion of best practice for
			providing such service is out of scope for this document.
	It is noted that DNS privacy service might be provided over IPSec,		Whilst encryption of DNS traffic can protect against active injection
	DNSCrypt or VPNs. However, use of these transports for DNS are not		this does not diminish the need for DNSSEC, see Appendix B.
	standardized and any discussion of best practice for providing such
	service is out of scope for this document.
	5.1.2. Authentication of DNS privacy services		5.1.2. Authentication of DNS privacy services
	Threats:		[RFC6973] Threats:
	o Surveillance and Intrusion: Active attacks that can redirect		o Surveillance:
	traffic to rogue servers
			* Active attacks that can redirect traffic to rogue servers
			[I-D.bortzmeyer-dprive-rfc7626-bis] Section 2.5.3.
	Mitigations:		Mitigations:
	DNS privacy services should ensure clients can authenticate the		DNS privacy services should ensure clients can authenticate the
	server. Note that this, in effect, commits the DNS privacy service		server. Note that this, in effect, commits the DNS privacy service
	to a public identity users will trust.		to a public identity users will trust.
	When using DNS-over-TLS clients that select a 'Strict Privacy' usage		When using DNS-over-TLS 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 should		enable this, DNS privacy services that offer DNS-over-TLS should
	provide credentials in the form of either X.509 certificates, SPKI		provide credentials in the form of either X.509 certificates, SPKI
	pinsets or TLSA records.		pinsets or TLSA records.
	When offering DoH [I-D.ietf-doh-dns-over-https], HTTPS requires		When offering DoH [RFC8484], HTTPS requires authentication of the
	authentication of the server as part of the protocol.		server as part of the protocol.
			NOTE: At this time the reference to the TLS DNSSEC chain extension
			draft has been removed as it is no longer considered an active TLS WG
			document.
	Optimizations:		Optimizations:
	DNS privacy services can also consider the following capabilities/		DNS privacy services can also consider the following capabilities/
	options:		options:
	o As recommended in [RFC8310] providing DANE TLSA records for the		o As recommended in [RFC8310] providing DANE TLSA records for the
	nameserver		nameserver
	* In particular, the service could provide TLSA records such that		* In particular, the service could provide TLSA records such that
	authenticating solely via the PKIX infrastructure can be		authenticating solely via the PKIX infrastructure can be
	avoided.		avoided.
	o Implementing [I-D.ietf-tls-dnssec-chain-extension]
	* This can decrease the latency of connection setup to the server
	and remove the need for the client to perform meta-queries to
	obtain and validate the DANE records.
	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 pinset management is described in [RFC7858] but		It is noted that SPKI pinset management is described in [RFC7858] but
	that key pinning mechanisms in general have fallen out of favour		that key pinning mechanisms in general have fallen out of favor
	operationally for various reasons.		operationally for various reasons such as the logistical overhead of
			rolling keys.
	Threats:		DNS Privacy Threats:
	o Invalid certificates, resulting in an unavailable service.		o Invalid certificates, resulting in an unavailable service.
	o Mis-identification of a server by a client e.g. typos in URLs or		o Mis-identification of a server by a client e.g. typos in URLs or
	authentication domain names		authentication domain names
	Mitigations:		Mitigations:
	It is recommended that operators:		It is recommended that operators:
	o Choose a short, memorable authentication name for their service		o Follow the guidance in Section 6.5 of [RFC7525] with regards to
			certificate revocation
			o Choose a short, memorable authentication name for the service
	o Automate the generation and publication of certificates		o Automate the generation and publication of certificates
	o Monitor certificates to prevent accidental expiration of		o Monitor certificates to prevent accidental expiration of
	certificates		certificates
	TODO: Could we provide references for certificate management best
	practice, for example Section 6.5 of RFC7525?
	5.1.3. Protocol recommendations		5.1.3. Protocol recommendations
	5.1.3.1. DNS-over-TLS		5.1.3.1. DNS-over-TLS
	Threats:		DNS Privacy Threats:
	o Known attacks on TLS (TODO: add a reference)		o Known attacks on TLS such as those described in [RFC7457]
	o Traffic analysis (TODO: add a reference)		o Traffic analysis, for example: Pitfalls of DNS Encryption [1]
	o Potential for client tracking via transport identifiers		o Potential for client tracking via transport identifiers
	o Blocking of well known ports (e.g. 853 for DNS-over-TLS)		o Blocking of well known ports (e.g. 853 for DNS-over-TLS)
	Mitigations:		Mitigations:
	In the case of DNS-over-TLS, TLS profiles from Section 9 and the		In the case of DNS-over-TLS, TLS profiles from Section 9 and the
	Countermeasures to DNS Traffic Analysis from section 11.1 of		Countermeasures to DNS Traffic Analysis from section 11.1 of
	[RFC8310] provide strong mitigations. This includes but is not		[RFC8310] provide strong mitigations. This includes but is not
	skipping to change at page 10, line 4 ¶		skipping to change at page 9, line 44 ¶
	o Blocking of well known ports (e.g. 853 for DNS-over-TLS)		o Blocking of well known ports (e.g. 853 for DNS-over-TLS)
	Mitigations:		Mitigations:
	In the case of DNS-over-TLS, TLS profiles from Section 9 and the		In the case of DNS-over-TLS, TLS profiles from Section 9 and the
	Countermeasures to DNS Traffic Analysis from section 11.1 of		Countermeasures to DNS Traffic Analysis from section 11.1 of
	[RFC8310] provide strong mitigations. This includes but is not		[RFC8310] provide strong mitigations. This includes but is not
	limited to:		limited to:
	o Adhering to [RFC7525]		o Adhering to [RFC7525]
	o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]		o Implementing only (D)TLS 1.2 or later as specified in [RFC8310]
	o Implementing EDNS(0) Padding [RFC7830] using the guidelines in		o Implementing EDNS(0) Padding [RFC7830] using the guidelines in
	[I-D.ietf-dprive-padding-policy]		[RFC8467]
	o Clients should not be required to use TLS session resumption		o Clients should not be required to use TLS session resumption
	[RFC5077], Domain Name System (DNS) Cookies [RFC7873].		[RFC5077] or Domain Name System (DNS) Cookies [RFC7873].
	o A DNS-over-TLS privacy service on both port 853 and 443. We note		o A DNS-over-TLS privacy service on both port 853 and 443. This
	that this practice may require revision when DoH becomes more		practice may not be possible if e.g. the operator deploys DoH on
	widely deployed, because of the potential use of the same ports		the same IP address.
	for two incompatible types of service.
	Optimizations:		Optimizations:
	o Concurrent processing of pipelined queries, returning responses as		o Concurrent processing of pipelined queries, returning responses as
	soon as available, potentially out of order as specified in		soon as available, potentially out of order as specified in
	[RFC7766]. This is often called 'OOOR' - out-of-order responses.		[RFC7766]. This is often called 'OOOR' - out-of-order responses.
	(Providing processing performance similar to HTTP multiplexing)		(Providing processing performance similar to HTTP multiplexing)
	o Management of TLS connections to optimize performance for clients		o Management of TLS connections to optimize performance for clients
	using either		using either
	* [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or		* [RFC7766] and EDNS(0) Keepalive [RFC7828] and/or
	* DNS Stateful Operations [I-D.ietf-dnsop-session-signal]		* DNS Stateful Operations [I-D.ietf-dnsop-session-signal]
			o Offer a separate service that uses only TLS 1.3 [RFC8446]
	Additional options that providers may consider:		Additional options that providers may consider:
	o Offer a .onion [RFC7686] service endpoint		o Offer a .onion [RFC7686] service endpoint
	5.1.3.2. DoH		5.1.3.2. DoH
	TODO: Fill this in, a lot of overlap with DNS-over-TLS but we need to		DNS Privacy Threats:
	address DoH specific ones if possible.
			o Known attacks on TLS such as those described in [RFC7457]
			o Traffic analysis, for example: DNS Privacy not so private: the
			traffic analysis perspective [2]
			o Potential for client tracking via transport identifiers
	Mitigations:		Mitigations:
	o Clients should not be required to use HTTP Cookies [RFC6265].		o Clients should not be required to use HTTP Cookies [RFC6265].
	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.		absolute minimum to obtain service from a DoH server. (Some
			initial work in this area has been proposed
			[I-D.dickinson-doh-dohpe] but there are no clear guidelines for
			HTTP header privacy, more work on this topic is required.)
			Optimizations:
			o Offer a separate service that uses only TLS 1.3 [RFC8446]
	5.1.4. Availability		5.1.4. Availability
	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.		motivation for users to switch services.
	TODO: Add reference to ongoing research on this topic.		TODO: Add reference to ongoing research on this topic.
	5.1.5. Service options		5.1.5. Service options
	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 to
	providers, fallback to cleartext or accept no DNS service for the		the services available. providers, fallback to cleartext or accept
	outage.		no DNS service for the outage.
	Mitigations:		Mitigations:
	A DNS privacy service should deliver the same level of service		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 of), DNSSEC validation, etc.		filtering (or lack of), DNSSEC validation, etc.
	5.1.6. Limitations of using a pure TLS proxy		5.1.6. Impact on Operators
			DNS Privacy Threats:
			o Increased use of encryption impacts operator ability to manage
			their network [RFC8404]
			5.1.7. Limitations of using a pure TLS proxy
			DNS Privacy Threats:
			o Limited ability to manage or monitor incoming connections using
			DNS specific techniques
	Optimization:		Optimization:
	Some operators may choose to implement DNS-over-TLS using a TLS proxy		Some operators may choose to implement DNS-over-TLS using a TLS proxy
	(e.g. nginx [1], haproxy [2] or stunnel [3]) in front of a DNS		(e.g. nginx [3], haproxy [4] or stunnel [5]) 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 and		large numbers of client connections, load balancing capabilities and
	good tooling. Currently, however, because such proxies typically		good tooling. Currently, however, because such proxies typically
	have no specific handling of DNS as a protocol over TLS or DTLS using		have no specific handling of DNS as a protocol over TLS or DTLS using
	them can restrict traffic management at the proxy layer and at the		them can restrict traffic management at the proxy layer and at the
	DNS server. For example, all traffic received by a nameserver behind		DNS server. For example, all traffic received by a nameserver behind
	such a proxy will appear to originate from the proxy and DNS		such a proxy will appear to originate from the proxy and DNS
	techniques such as ACLs, RRL or DNS64 will be hard or impossible to		techniques such as ACLs, RRL or DNS64 will be hard or impossible to
	implement in the nameserver.		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.
	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
	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 Treats
	o Contravention of legal requirements not to process user data?		o Contravention of legal requirements not to process user data?
	Mitigations:		Mitigations:
	The following are common activities for DNS service operators and in		The following are common activities for DNS service operators and in
	all cases should be minimized or completely avoided if possible for		all cases should be minimized or completely avoided if possible for
	DNS privacy services. If data is retained it should be encrypted and		DNS privacy services. If data is retained it should be encrypted and
	either aggregated, pseudonymized or anonymized whenever possible. In		either aggregated, pseudonymized or anonymized whenever possible. In
	general the principle of data minimization described in [RFC6973]		general the principle of data minimization described in [RFC6973]
	should be applied.		should be applied.
	skipping to change at page 12, line 47 ¶		skipping to change at page 13, line 15 ¶
	feasible.		feasible.
	o The retention period of DNS traffic logs should be only those		o The retention period of DNS traffic logs should be only those
	required to sustain operation of the service and, to the extent		required to sustain operation of the service and, to the extent
	that such exists, meet regulatory requirements.		that such exists, meet regulatory requirements.
	o DNS privacy services should not track users except for the		o DNS privacy services should not track users except for the
	particular purpose of detecting and remedying technically		particular purpose of detecting and remedying technically
	malicious (e.g. DoS) or anomalous use of the service.		malicious (e.g. DoS) or anomalous use of the service.
	o Data access should be minimized to only those personal who require		o Data access should be minimized to only those personnel who
	access to perform operational duties.		require access to perform operational duties.
			Optimizations:
			o Consider use of full disk encryption for logs and data capture
			storage.
	5.2.2. Data minimization of network traffic		5.2.2. Data minimization of network traffic
	Data minimization refers to collecting, using, disclosing, and		Data minimization refers to collecting, using, disclosing, and
	storing the minimal data necessary to perform a task, and this can be		storing the minimal data necessary to perform a task, and this can be
	achieved by removing or obfuscating privacy-sensitive information in		achieved by removing or obfuscating privacy-sensitive information in
	network traffic logs. This is typically personal data, or data that		network traffic logs. This is typically personal data, or data that
	can be used to link a record to an individual, but may also include		can be used to link a record to an individual, but may also include
	revealing other confidential information, for example on the		revealing other confidential information, for example on the
	structure of an internal corporate network.		structure of an internal corporate network.
	skipping to change at page 13, line 37 ¶		skipping to change at page 14, line 8 ¶
	the decade. Developments over the last decade have been both a		the decade. Developments over the last decade have been both a
	blessing and a curse; the large increase in size between an IPv4 and		blessing and a curse; the large increase in size between an IPv4 and
	an IPv6 address, for example, renders some techniques impractical,		an IPv6 address, for example, renders some techniques impractical,
	but also makes available a much larger amount of input entropy, the		but also makes available a much larger amount of input entropy, the
	better to resist brute force re-identification attacks that have		better to resist brute force re-identification attacks that have
	grown in practicality over the period.		grown in practicality over the period.
	Techniques employed may be broadly categorized as either		Techniques employed may be broadly categorized as either
	anonymization or pseudonymization. The following discussion uses the		anonymization or pseudonymization. The following discussion uses the
	definitions from [RFC6973] Section 3, with additional observations		definitions from [RFC6973] Section 3, with additional observations
	from van Dijkhuizen et al. [4]		from van Dijkhuizen et al. [6]
	o Anonymization. To enable anonymity of an individual, there must		o Anonymization. To enable anonymity of an individual, there must
	exist a set of individuals that appear to have the same		exist a set of individuals that appear to have the same
	attribute(s) as the individual. To the attacker or the observer,		attribute(s) as the individual. To the attacker or the observer,
	these individuals must appear indistinguishable from each other.		these individuals must appear indistinguishable from each other.
	o Pseudonymization. The true identity is deterministically replaced		o Pseudonymization. The true identity is deterministically replaced
	with an alternate identity (a pseudonym). When the		with an alternate identity (a pseudonym). When the
	pseudonymization schema is known, the process can be reversed, so		pseudonymization schema is known, the process can be reversed, so
	the original identity becomes known again.		the original identity becomes known again.
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 40 ¶
	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. This following table presents a high level		unencumbered by patents. This 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 B provides a more detailed survey of these techniques and		Appendix C 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) [5]		Figure showing comparison of IP address techniques (SVG) [7]
	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
	[I-D.ietf-dnsop-dns-capture-format] that can be used as input to		[I-D.ietf-dnsop-dns-capture-format] that can be used as input to
	existing analysis tools. In that case, use of a Format-preserving		existing analysis tools. In that case, use of a Format-preserving
	technique is essential. This, though, is not cost-free - several		technique is essential. This, though, is not cost-free - several
	authors (e.g. Brenker & Arnes [6]) have observed that, as the		authors (e.g. Brenker & Arnes [8]) have observed that, as the
	entropy in a IPv4 address is limited, given a de-identified log from		entropy in a IPv4 address is limited, given a de-identified log from
	a target, if an attacker is capable of ensuring packets are captured		a target, if an attacker is capable of ensuring packets are captured
	by the target and the attacker can send forged traffic with arbitrary		by the target and the attacker can send forged traffic with arbitrary
	source and destination addresses to that target, any format-		source and destination addresses to that target, any format-
	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
	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 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.		TODO: More analysis here.
	5.2.5. Cache snooping		5.2.5. Cache snooping
	Threats:		[RFC6973] Threats:
	o Profiling of client queries by malicious third parties		o Surveillance:
			* Profiling of client queries by malicious third parties
	Mitigations:		Mitigations:
	TODO: Describe techniques to defend against cache snooping		o See ISC Knowledge database on cache snooping [9] for an example
			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
	Threats:		[RFC6973] Threats:
	o Transmission of identifying data upstream.		o Surveillance:
			* Transmission of identifying data upstream.
	Mitigations:		Mitigations:
	As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS		As specified in [RFC8310] for DNS-over-TLS but applicable to any DNS
	Privacy services the server should:		Privacy services the server should:
	o Implement QNAME minimization [RFC7816]		o Implement QNAME minimization [RFC7816]
	o Honour a SOURCE PREFIX-LENGTH set to 0 in a query containing the		o Honor a SOURCE PREFIX-LENGTH set to 0 in a query containing the
	EDNS(0) Client Subnet (ECS) option and not send an ECS option in		EDNS(0) Client Subnet (ECS) option and not send an ECS option in
	upstream queries.		upstream queries.
	Optimizations:		Optimizations:
	o The server should either		o The server should either
	* not use the ECS option in upstream queries at all, or		* not use the ECS option in upstream queries at all, or
	* offer alternative services, one that sends ECS and one that		* offer alternative services, one that sends ECS and one that
	does not.		does not.
	If operators do offer a service that sends the ECS options upstream		If operators do offer a service that sends the ECS options upstream
	they should use the shortest prefix that is operationally feasible		they should use the shortest prefix that is operationally feasible
	(NOTE: the authors believe they will be able to add a reference for		(NOTE: the authors believe they will be able to add a reference for
	advice here soon) and ideally use a policy of whitelisting upstream		advice here soon) and ideally use a policy of whitelisting upstream
	servers to send ECS to in order to minimize data leakage. Operators		servers to send ECS to in order to minimize data leakage. Operators
	should make clear in any policy statement what prefix length they		should make clear in any policy statement what prefix length they
	actually send and the specific policy used.		actually send and the specific policy used.
			Whitelisting has the benefit that not only does the operator know
			which upstream servers can use ECS but also allows the operator to
			decide which upstream servers apply privacy policies that the
			operator is happy with. However some operators consider whitelisting
			to incur significant operational overhead compared to dynamic
			detection of ECS on authoritative servers.
	Additional options:		Additional options:
	o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the		o Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
	number of queries to authoritative servers to increase privacy.		number of queries to authoritative servers to increase privacy.
	o Run a copy of the root zone on loopback [RFC7706] to avoid making		o Run a copy of the root zone on loopback [RFC7706] to avoid making
	queries to the root servers that might leak information.		queries to the root servers that might leak information.
	5.3.2. Client query obfuscation		5.3.2. Client query obfuscation
	skipping to change at page 16, line 41 ¶		skipping to change at page 17, line 31 ¶
	and what they can do to mitigate this further. Note, that even when		and what they can do to mitigate this further. Note, that even when
	all the relevant techniques described above are employed there may		all the relevant techniques described above are employed there may
	still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For		still be attacks possible, e.g. [Pitfalls-of-DNS-Encryption]. For
	example, a resolver with a very small community of users risks		example, a resolver with a very small community of users risks
	exposing data in this way and OUGHT obfuscate this traffic by mixing		exposing data in this way and OUGHT obfuscate this traffic by mixing
	it with 'generated' traffic to make client characterization harder.		it with 'generated' traffic to make client characterization harder.
	The resolver could also employ aggressive pre-fetch techniques as a		The resolver could also employ aggressive pre-fetch techniques as a
	further measure to counter traffic analysis.		further measure to counter traffic analysis.
	At the time of writing there are no standardized or widely recognized		At the time of writing there are no standardized or widely recognized
	techniques to preform such obfuscation or bulk pre-fetches.		techniques to perform such obfuscation or bulk pre-fetches.
	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
	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
	skipping to change at page 17, line 18 ¶		skipping to change at page 18, line 4 ¶
	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
			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
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 35 ¶
	TODO: More on data for research vs operations... how to still		TODO: More on data for research vs operations... how to still
	motivate operators to share anonymized data?		motivate operators to share anonymized data?
	TODO: Guidelines for when consent is granted?		TODO: Guidelines for when consent is granted?
	TODO: Applies to server data handling too.. could operators offer		TODO: Applies to server data handling too.. could operators offer
	alternatives services one that implies consent for data processing,		alternatives services one that implies consent for data processing,
	one that doesn't?		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
	1 Policy
	1.1 Recommendations. This section should explain, with reference to
	section Section 5 of this document which recommendations the DNS
	privacy service employs.
	1.2 Data handling. This section should explain, with reference to
	section Section 5.2 of this document the policy for gathering and
	disseminating information collected by the DNS privacy service.
	1.2.1 Specify clearly what data (including whether it is aggregated,
	pseudonymized or anonymized) is:
	1.2.1.1 Collected and retained by the operator (and for how long)		6.1. Recommended contents of a DPPPS
	1.2.1.2 Shared with partners
	1.2.1.3 Shared, sold or rented to third-parties
	1.2.2 Specify any exceptions to the above, for example technically
	malicious or anomalous behaviour
	1.2.3 Declare any partners, third-party affiliations or sources of
	funding
	1.2.4 Whether user DNS data is correlated or combined with any other
	personal information held by the operator
	2 Practice. This section should explain the current operational
	practices of the service.
	2.1 Specify any temporary or permanent deviations from the policy for
	operational reasons
	2.2 With reference to section Section 5.1 provide specific details of
	which capabilities are provided on which address and ports
	2.3 With reference to section Section 5.3 provide specific details of		6.1.1. Policy
	which capabilities are employed for upstream traffic from the server
	2.4 Specify the authentication name to be used (if any) and if TLSA		1. Make an explicit statement that IP addressses are treated as PII
	records are published (including options used in the TLSA records)
	2.5 Specify the SPKI pinsets to be used (if any) and policy for		2. State if IP addresses are being logged
	rolling keys
	2.6 Provide a contact email address for the service
	6.2. Current policy and privacy statements		3. Specify clearly what data (including whether it is aggregated,
			pseudonymized or anonymized) is:
	NOTE: An analysis of these statements will clearly only provide a		* Collected and retained by the operator (and for how long)
	snapshot at the time of writing. It is included in this version of
	the draft to provide a basis for the assessment of the contents of
	the DPPPS and is expected to be removed or substantially re-worked in
	a future version.
	6.2.1. Quad9		* Shared with partners
	UDP/TCP and TLS (port 853) service provided on two addresses:		* Shared, sold or rented to third-parties
	o 'Secure': 9.9.9.9, 149.112.112.112, 2620:fe::fe, 2620:fe::9		4. Specify any exceptions to the above, for example technically
			malicious or anomalous behavior
	o 'Unsecured': 9.9.9.10, 149.112.112.10, 2620:fe::10		5. Declare any partners, third-party affiliations or sources of
			funding
	Policy:		6. Whether user DNS data is correlated or combined with any other
			personal information held by the operator
	o <https://www.quad9.net/policy/>		7. Result filtering. This section should explain whether the
			operator filters, edits or alters in any way the replies that it
			receives from the authoritative servers for each DNS zone, before
			forwarding them to the clients. For each category listed below,
			the operator should also specify how the filtering lists are
			created and managed, whether it employs any third-party sources
			for such lists, and which ones.
	o <https://www.quad9.net/privacy/>		* Specify if any replies are being filtered out or altered for
			network and computer security reasons (e.g. preventing
			connections to malware-spreading websites or botnet control
			servers)
	o <https://www.quad9.net/faq/>		* Specify if any replies are being filtered out or altered for
			mandatory legal reasons, due to applicable legislation or
			binding orders by courts and other public authorities
	6.2.2. Cloudflare		* Specify if any replies are being filtered out or altered for
			voluntary legal reasons, due to an internal policy by the
			operator aiming at reducing potential legal risks
	UDP/TCP and TLS (port 853) service provided on 1.1.1.1, 1.0.0.1,		* Specify if any replies are being filtered out or altered for
	2606:4700:4700::1111 and 2606:4700:4700::1001.		any other reason, including commercial ones
	Policy:		6.1.2. Practice.
	o <https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/		This section should explain the current operational practices of the
	privacy-policy/privacy-policy/>		service.
	DoH provided on: <https://cloudflare-dns.com/dns-query>		1. Specify any temporary or permanent deviations from the policy for
			operational reasons
	Policy:		2. With reference to section Section 5 provide specific details of
			which capabilities are provided on which client facing address
			and ports
	o <https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/		3. Specify the authentication name to be used (if any) and if TLSA
	privacy-policy/firefox/>		records are published (including options used in the TLSA
			records)
	Tor endpoint: <https://dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac		4. Specify the SPKI pinsets to be used (if any) and policy for
	6ap25zgqad.onion>.		rolling keys
	6.2.3. Google		5. Provide contact/support information for the service
	UDP/TCP service provided on 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888		6. Jurisdiction. This section should communicate the applicable
	and 2001:4860:4860::8844.		jurisdictions and law enforcement regimes under which the service
			is being provided.
	Policy: <https://developers.google.com/speed/public-dns/privacy>		* Specify the entity or entities that will control the data and
			be responsible for their treatment, and their legal place of
			business
	6.2.4. OpenDNS		* Specify, either directly or by pointing to the applicable
			privacy policy, the relevant privacy laws that apply to the
			treatment of the data, the rights that users enjoy in regard
			to their own personal information that is treated by the
			service, and how they can contact the operator to enforce them
	UDP/TCP service provided on 208.67.222.222 and 208.67.220.220 (no		* Specify the countries in which the servers handling the DNS
	IPv6).		requests and the data are located (if the operator applies a
			geolocation policy so that requests from certain countries are
			only served by certain servers, this should be specified as
			well)
	We could find no specific privacy policy for the DNS resolution, only		* Specify whether the operator has any agreement in place with
	a general one from Cisco that seems focussed on websites.		law enforcement agencies, or other public and private parties
			dealing with security and intelligence, to give them access to
			the servers and/or to the data
	Policy: <https://www.cisco.com/c/en/us/about/legal/privacy-full.html>		7. Describe how consent is obtained from the user of the DNS privacy
			service differentiating
	6.2.5. Comparison		* Uninformed users for whom this trust relationship is implicit
	The following tables provides a high-level comparison of the policy		* Privacy-conscious users, that make an explicit trust choice
	and practice statements above and also some observations of practice
	measured at dnsprivacy.org [7]. The data is not exhaustive and has
	not been reviewed or confirmed by the operators.
	A question mark indicates no clear statement or data could be located		this may prove relevant in the context of e.g. the GDPR as it relates
	on the issue. A dash indicates the category is not applicable to the		to consent.
	service.
	Table showing comparison of operators policies [8]		6.2. Current policy and privacy statements
	Table showing comparison of operators practices [9]		A tabular comparison of existing policy and privacy statements from
			various DNS Privacy service operators based on the proposed DPPPS
			structure can be found on dnsprivacy.org [10].
	NOTE: Review and correction of any inaccuracies in the table would be		We note that the existing set of policies vary widely in style,
	much appreciated.		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
			A4 text. It is a non-trivial task today for a user to extract a
			meaningful overview of the different services on offer.
	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 should be performed where possible of:		Independent monitoring or analysis could be performed where possible
			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
			that are currently available e.g. SSL Labs [11] or Internet.nl [12].
			Additionally operators could choose to engage the services of a third
			party auditor to verify their compliance with their published DPPPS.
	7. IANA considerations		7. IANA considerations
	None		None
	8. Security considerations		8. Security considerations
			Security considerations for DNS-over-TCP are given in [RFC7766], many
			of which are generally applicable to session based DNS.
	TODO: e.g. New issues for DoS defence, server admin policies		TODO: e.g. New issues for DoS defence, server admin policies
	9. Acknowledgements		9. Acknowledgements
	Many thanks to Amelia Andersdotter for a very thorough review of the		Many thanks to Amelia Andersdotter for a very thorough review of the
	first draft of this document. Thanks also to John Todd for		first draft of this document. Thanks to John Todd for discussions on
	discussions on this topic, and to Stephane Bortzmeyer for review.		this topic, and to Stephane Bortzmeyer, Puneet Sood and Vittorio
			Bertola for review. Thanks to Daniel Kahn Gillmor, Barry Green, Paul
			Hoffman, Dan York, John Reed, Lorenzo Colitti for comments at the
			mic. 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.
	10. Contributors		10. 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 Internet Technologies
	skipping to change at page 21, line 42 ¶		skipping to change at page 22, line 25 ¶
	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-00		draft-ietf-dprive-bcp-op-01
			o Many minor editorial fixes
			o Update DoH reference to RFC8484 and add more text on DoH
			o Split threat descriptions into ones directly referencing RFC6973
			and other DNS Privacy threats
			o Improve threat descriptions throughout
			o Remove reference to the DNSSEC TLS Chain Extension draft until new
			version submitted.
			o Clarify use of whitelisting for ECS
			o Re-structure the DPPPS, add Result filtering section.
			o Remove the direct inclusion of privacy policy comparison, now just
			reference dnsprivacy.org and an example of such work.
			o Add an appendix briefly discussing DNSSEC
			o Update affiliation of 1 author
			draft-ietf-dprive-bcp-op-00
	o Initial commit of re-named document after adoption to replace		o Initial commit of re-named document after adoption to replace
	draft-dickinson-dprive-bcp-op-01		draft-dickinson-dprive-bcp-op-01
	12. References		12. References
	12.1. Normative References
	[I-D.ietf-dnsop-terminology-bis]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", draft-ietf-dnsop-terminology-bis-11 (work in
	progress), July 2018.
	[I-D.ietf-doh-dns-over-https]		12.1. Normative References
	Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", draft-ietf-doh-dns-over-https-12 (work in
	progress), June 2018.
	[I-D.ietf-dprive-padding-policy]		[I-D.ietf-dnsop-session-signal]
	Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-		Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	dprive-padding-policy-06 (work in progress), July 2018.		Lemon, T., and T. Pusateri, "DNS Stateful Operations",
			draft-ietf-dnsop-session-signal-20 (work in progress),
			December 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011, <https://www.rfc-		DOI 10.17487/RFC6265, April 2011,
	editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013, <https://www.rfc-		DOI 10.17487/RFC6973, July 2013,
	editor.org/info/rfc6973>.		<https://www.rfc-editor.org/info/rfc6973>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
			[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
			<https://www.rfc-editor.org/info/rfc7766>.
	[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve		[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
	Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,		Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
	<https://www.rfc-editor.org/info/rfc7816>.		<https://www.rfc-editor.org/info/rfc7816>.
			[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
			edns-tcp-keepalive EDNS0 Option", RFC 7828,
			DOI 10.17487/RFC7828, April 2016,
			<https://www.rfc-editor.org/info/rfc7828>.
	[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,		[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
	DOI 10.17487/RFC7830, May 2016, <https://www.rfc-		DOI 10.17487/RFC7830, May 2016,
	editor.org/info/rfc7830>.		<https://www.rfc-editor.org/info/rfc7830>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
			[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
			Kumari, "Client Subnet in DNS Queries", RFC 7871,
			DOI 10.17487/RFC7871, May 2016,
			<https://www.rfc-editor.org/info/rfc7871>.
	[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)		[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
	Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,		Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
	<https://www.rfc-editor.org/info/rfc7873>.		<https://www.rfc-editor.org/info/rfc7873>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles		[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
	for DNS over TLS and DNS over DTLS", RFC 8310,		for DNS over TLS and DNS over DTLS", RFC 8310,
	DOI 10.17487/RFC8310, March 2018, <https://www.rfc-		DOI 10.17487/RFC8310, March 2018,
	editor.org/info/rfc8310>.		<https://www.rfc-editor.org/info/rfc8310>.
			[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
			Pervasive Encryption on Operators", RFC 8404,
			DOI 10.17487/RFC8404, July 2018,
			<https://www.rfc-editor.org/info/rfc8404>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
			for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
			October 2018, <https://www.rfc-editor.org/info/rfc8467>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/info/rfc8484>.
	12.2. Informative References		12.2. Informative References
	[I-D.bortzmeyer-dprive-rfc7626-bis]		[I-D.bortzmeyer-dprive-rfc7626-bis]
	Bortzmeyer, S. and S. Dickinson, "DNS Privacy		Bortzmeyer, S. and S. Dickinson, "DNS Privacy
	Considerations", draft-bortzmeyer-dprive-rfc7626-bis-01		Considerations", draft-bortzmeyer-dprive-rfc7626-bis-01
	(work in progress), July 2018.		(work in progress), July 2018.
			[I-D.dickinson-doh-dohpe]
			Dickinson, S. and W. Toorop, "DoHPE: DoH with Privacy
			Enhancements", draft-dickinson-doh-dohpe-00 (work in
			progress), July 2018.
	[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-07 (work in progress), May		ietf-dnsop-dns-capture-format-10 (work in progress),
	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-02 (work in progress), May 2018.		requirements-02 (work in progress), May 2018.
	[I-D.ietf-dnsop-session-signal]		[I-D.ietf-dnsop-terminology-bis]
	Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",		Terminology", draft-ietf-dnsop-terminology-bis-14 (work in
	draft-ietf-dnsop-session-signal-14 (work in progress),		progress), September 2018.
	August 2018.
	[I-D.ietf-tls-dnssec-chain-extension]
	Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
	Record and DNSSEC Authentication Chain Extension for TLS",
	draft-ietf-tls-dnssec-chain-extension-07 (work in
	progress), March 2018.
	[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.		[pcap] tcpdump.org, "PCAP", 2016, <http://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", 2014, <https://www.ietf.org/mail-archive/web/		Encryption", 2014, <https://www.ietf.org/mail-archive/web/
	dns-privacy/current/pdfWqAIUmEl47.pdf>.		dns-privacy/current/pdfWqAIUmEl47.pdf>.
			[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "DNS Security Introduction and Requirements",
			RFC 4033, DOI 10.17487/RFC4033, March 2005,
			<https://www.rfc-editor.org/info/rfc4033>.
	[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>.
	[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A		[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
	Framework for DNSSEC Policies and DNSSEC Practice		Framework for DNSSEC Policies and DNSSEC Practice
	Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,		Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
	<https://www.rfc-editor.org/info/rfc6841>.		<https://www.rfc-editor.org/info/rfc6841>.
	[RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the		[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
	Session Initiation Protocol (SIP) Common Log Format		Known Attacks on Transport Layer Security (TLS) and
	(CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013,		Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
	<https://www.rfc-editor.org/info/rfc6873>.		February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use		[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
	Domain Name", RFC 7686, DOI 10.17487/RFC7686, October		Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
	2015, <https://www.rfc-editor.org/info/rfc7686>.		2015, <https://www.rfc-editor.org/info/rfc7686>.
	[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root		[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
	Servers by Running One on Loopback", RFC 7706,		Servers by Running One on Loopback", RFC 7706,
	DOI 10.17487/RFC7706, November 2015, <https://www.rfc-		DOI 10.17487/RFC7706, November 2015,
	editor.org/info/rfc7706>.		<https://www.rfc-editor.org/info/rfc7706>.
	[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
	D. Wessels, "DNS Transport over TCP - Implementation
	Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
	<https://www.rfc-editor.org/info/rfc7766>.
	[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
	edns-tcp-keepalive EDNS0 Option", RFC 7828,
	DOI 10.17487/RFC7828, April 2016, <https://www.rfc-
	editor.org/info/rfc7828>.
	[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
	Kumari, "Client Subnet in DNS Queries", RFC 7871,
	DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
	editor.org/info/rfc7871>.
	[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram		[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	Transport Layer Security (DTLS)", RFC 8094,		Transport Layer Security (DTLS)", RFC 8094,
	DOI 10.17487/RFC8094, February 2017, <https://www.rfc-		DOI 10.17487/RFC8094, February 2017,
	editor.org/info/rfc8094>.		<https://www.rfc-editor.org/info/rfc8094>.
	[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of		[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
	DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,		DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
	July 2017, <https://www.rfc-editor.org/info/rfc8198>.		July 2017, <https://www.rfc-editor.org/info/rfc8198>.
	12.3. URIs		12.3. URIs
	[1] https://nginx.org/		[1] https://www.ietf.org/mail-archive/web/dns-privacy/current/
			pdfWqAIUmEl47.pdf
	[2] https://www.haproxy.org/		[2] https://petsymposium.org/2018/files/hotpets/4-siby.pdf
	[3] https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html		[3] https://nginx.org/
	[4] https://doi.org/10.1145/3182660		[4] https://www.haproxy.org/
	[5] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/draft-		[5] https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html
			[6] https://doi.org/10.1145/3182660
			[7] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/draft-
	00/ip_techniques_table.svg		00/ip_techniques_table.svg
	[6] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164		[8] https://pdfs.semanticscholar.org/7b34/12c951cebe71cd2cddac5fda164
	fb2138a44.pdf		fb2138a44.pdf
	[7] https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/		[9] https://kb.isc.org/docs/aa-00482
	[8] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/draft-		[10] https://dnsprivacy.org/wiki/display/DP/
	00/policy_table.svg		Comparison+of+policy+and+privacy+statements
	[9] https://github.com/Sinodun/draft-dprive-bcp-op/blob/master/draft-		[11] https://www.ssllabs.com/ssltest/
	00/practice_table.svg
	[10] https://support.google.com/analytics/answer/2763052?hl=en		[12] https://internet.nl
	[11] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-		[13] https://support.google.com/analytics/answer/2763052?hl=en
			[14] https://www.conversionworks.co.uk/blog/2017/05/19/anonymize-ip-
	geo-impact-test/		geo-impact-test/
	[12] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc		[15] https://github.com/edmonds/pdns/blob/master/pdns/dnswasher.cc
	[13] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html		[16] http://ita.ee.lbl.gov/html/contrib/tcpdpriv.html
	[14] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-		[17] http://an.kaist.ac.kr/~sbmoon/paper/intl-journal/2004-cn-
	anon.pdf		anon.pdf
	[15] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/		[18] https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/
	[16] http://mharvan.net/talks/noms-ip_anon.pdf		[19] http://mharvan.net/talks/noms-ip_anon.pdf
	[17] https://medium.com/@bert.hubert/on-ip-address-encryption-		[20] http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf
			[21] https://medium.com/@bert.hubert/on-ip-address-encryption-
	security-analysis-with-respect-for-privacy-dabe1201b476		security-analysis-with-respect-for-privacy-dabe1201b476
	[18] https://github.com/PowerDNS/ipcipher		[22] https://github.com/PowerDNS/ipcipher
	[19] https://github.com/veorq/ipcrypt		[23] https://github.com/veorq/ipcrypt
	[20] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html		[24] https://www.ietf.org/mail-archive/web/cfrg/current/msg09494.html
	[21] https://tnc18.geant.org/core/presentation/127		[25] https://tnc18.geant.org/core/presentation/127
	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
	clients and recursive resolvers:		clients and recursive resolvers:
	o 'Specification for DNS over Transport Layer Security (TLS)'		o 'Specification for DNS over Transport Layer Security (TLS)'
	[RFC7858], referred to here as 'DNS-over-TLS'.		[RFC7858], referred to here as 'DNS-over-TLS'.
	o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094],		o 'DNS over Datagram Transport Layer Security (DTLS)' [RFC8094],
	referred to here as 'DNS-over-DTLS'. Note that this document has		referred to here as 'DNS-over-DTLS'. Note that this document has
	the Category of Experimental.		the Category of Experimental.
	o 'DNS Queries over HTTPS (DoH)' [I-D.ietf-doh-dns-over-https]		o 'DNS Queries over HTTPS (DoH)' [RFC8484] referred to here as DoH.
	referred to here as DoH.
	o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310]		o 'Usage Profiles for DNS over TLS and DNS over DTLS' [RFC8310]
	o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for		o 'The EDNS(0) Padding Option' [RFC7830] and 'Padding Policy for
	EDNS(0)' [I-D.ietf-dprive-padding-policy]		EDNS(0)' [RFC8467]
	These documents apply to recursive to authoritative DNS but are		These documents apply to recursive to authoritative DNS but are
	relevant when considering the operation of a recursive server:		relevant when considering the operation of a recursive server:
	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
	skipping to change at page 27, line 25 ¶		skipping to change at page 28, line 39 ¶
	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		Note that depending on the specifics of the implementation [RFC8484]
	[I-D.ietf-doh-dns-over-https] 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. IP address techniques		Appendix B. Encryption and DNSSEC
			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 28, line 45 ¶		skipping to change at page 30, line 28 ¶
	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.
	B.1. Google Analytics non-prefix filtering		C.1. Google Analytics non-prefix filtering
	Since May 2010, Google Analytics has provided a facility [10] that		Since May 2010, Google Analytics has provided a facility [13] 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 [14] which suggest that the impact of
	There are some analysis results [11] 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).
	B.2. dnswasher		C.2. dnswasher
	Since 2006, PowerDNS have included a de-identification tool dnswasher		Since 2006, PowerDNS have included a de-identification tool dnswasher
	[12] with their PowerDNS product. This is a PCAP filter that		[15] 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.
	B.3. Prefix-preserving map		C.3. Prefix-preserving map
	Used in TCPdpriv [13], this algorithm stores a set of original and		Used in TCPdpriv [16], 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).
	B.4. Cryptographic Prefix-Preserving Pseudonymisation		C.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. [14] and implemented in the		in TCPdpriv, described in Xu et al. [17] and implemented in the
	Crypto-PAn tool [15]. Crypto-PAn is now frequently used as an		Crypto-PAn tool [18]. 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 [16] and implemented in snmpdump. This uses a		Schoenwaelder [19] 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).
	B.5. Top-hash Subtree-replicated Anonymisation		C.5. Top-hash Subtree-replicated Anonymisation
	Proposed in Ramaswamy & Wolf, Top-hash Subtree-replicated		Proposed in Ramaswamy & Wolf [20], 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).
	B.6. ipcipher		C.6. ipcipher
	A recently-released proposal from PowerDNS [17], ipcipher [18] is a		A recently-released proposal from PowerDNS [21], ipcipher [22] 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 [19]		encrypted, but using a recently proposed encryption ipcrypt [23]
	suitable for 32bit block lengths. However, the author of ipcrypt has		suitable for 32bit block lengths. However, the author of ipcrypt has
	since indicated [20] that it has low security, and further analysis		since indicated [24] 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.
	B.7. Bloom filters		C.7. Bloom filters
	van Rijswijk-Deij et al. [21] have recently described work using		van Rijswijk-Deij et al. [25] 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
	skipping to change at page 31, line 20 ¶		skipping to change at page 33, line 4 ¶
	Authors' Addresses		Authors' Addresses
	Sara Dickinson		Sara Dickinson
	Sinodun IT		Sinodun IT
	Magdalen Centre		Magdalen Centre
	Oxford Science Park		Oxford Science Park
	Oxford OX4 4GA		Oxford OX4 4GA
	United Kingdom		United Kingdom
	Email: sara@sinodun.com		Email: sara@sinodun.com
	Benno J. Overeinder		Benno J. Overeinder
	NLnet Labs		NLnet Labs
	Science Park 400		Science Park 400
	Amsterdam 1098 XH		Amsterdam 1098 XH
	The Netherlands		The Netherlands
	Email: benno@nlnetLabs.nl		Email: benno@nlnetLabs.nl
	Roland M. van Rijswijk-Deij		Roland M. van Rijswijk-Deij
	SURFnet bv		NLnet Labs
	PO Box 19035		Science Park 400
	Utrecht 3501 DA Utrecht		Amsterdam 1098 XH
	The Netherlands		The Netherlands
	Email: roland.vanrijswijk@surfnet.nl		Email: roland@nlnetLabs.nl
	Allison Mankin		Allison Mankin
	Salesforce		Salesforce
	Email: allison.mankin@gmail.com		Email: allison.mankin@gmail.com
End of changes. 186 change blocks.
	360 lines changed or deleted		473 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/