< draft-ietf-dprive-bcp-op-10.txt		draft-ietf-dprive-bcp-op-11.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: December 20, 2020 R. van Rijswijk-Deij		Expires: January 3, 2021 R. van Rijswijk-Deij
	NLnet Labs		NLnet Labs
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	June 18, 2020		July 2, 2020
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-10		draft-ietf-dprive-bcp-op-11
	Abstract		Abstract
	This document presents operational, policy, and security		This document presents operational, policy, and security
	considerations for DNS recursive resolver operators who choose to		considerations for DNS recursive resolver operators who choose to
	offer DNS Privacy services. With these recommendations, the operator		offer DNS Privacy services. With these recommendations, the operator
	can make deliberate decisions regarding which services to provide,		can make deliberate decisions regarding which services to provide,
	and how the decisions and alternatives impact the privacy of users.		and how the decisions and alternatives impact the privacy of users.
	This document also presents a non-normative framework to assist		This document also presents a non-normative framework to assist
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 20, 2020.		This Internet-Draft will expire on January 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17		5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
	5.3. Data sent onwards from the server . . . . . . . . . . . . 17		5.3. Data sent onwards from the server . . . . . . . . . . . . 17
	5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17		5.3.1. Protocol recommendations . . . . . . . . . . . . . . 17
	5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18		5.3.2. Client query obfuscation . . . . . . . . . . . . . . 18
	5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19		5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
	6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19		6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 19
	6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20		6.1. Outline of a DROP statement . . . . . . . . . . . . . . . 20
	6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20		6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21		6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22		6.2. Enforcement/accountability . . . . . . . . . . . . . . . 22
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
	8. Security considerations . . . . . . . . . . . . . . . . . . . 23		8. Security considerations . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . 26
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33		Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 33
	A.1. Potential increases in DNS privacy . . . . . . . . . . . 33		A.1. Potential increases in DNS privacy . . . . . . . . . . . 33
	A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34		A.2. Potential decreases in DNS privacy . . . . . . . . . . . 34
	A.3. Related operational documents . . . . . . . . . . . . . . 34		A.3. Related operational documents . . . . . . . . . . . . . . 34
	Appendix B. IP address techniques . . . . . . . . . . . . . . . 35		Appendix B. IP address techniques . . . . . . . . . . . . . . . 35
	B.1. Categorization of techniques . . . . . . . . . . . . . . 36		B.1. Categorization of techniques . . . . . . . . . . . . . . 36
	B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37		B.2. Specific techniques . . . . . . . . . . . . . . . . . . . 37
	B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37		B.2.1. Google Analytics non-prefix filtering . . . . . . . . 37
	B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37		B.2.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . 37
	B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 37		B.2.3. Prefix-preserving map . . . . . . . . . . . . . . . . 38
	B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38		B.2.4. Cryptographic Prefix-Preserving Pseudonymization . . 38
	B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38		B.2.5. Top-hash Subtree-replicated Anonymization . . . . . . 38
	B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 38		B.2.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . 39
	B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39		B.2.7. Bloom filters . . . . . . . . . . . . . . . . . . . . 39
	Appendix C. Current policy and privacy statements . . . . . . . 39		Appendix C. Current policy and privacy statements . . . . . . . 39
	Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40		Appendix D. Example DROP statement . . . . . . . . . . . . . . . 40
	D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40		D.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40
	D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43		D.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is at the core of the Internet; almost		The Domain Name System (DNS) is at the core of the Internet; almost
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	feature (e.g., good reachability or encrypted transport) or because		feature (e.g., good reachability or encrypted transport) or because
	the network resolver lacks a specific feature (e.g., strong privacy		the network resolver lacks a specific feature (e.g., strong privacy
	policy or unfiltered responses). These open resolvers have tended to		policy or unfiltered responses). These open resolvers have tended to
	be at the forefront of adoption of privacy-related enhancements but		be at the forefront of adoption of privacy-related enhancements but
	it is anticipated that operators of other resolver services will		it is anticipated that operators of other resolver services will
	follow.		follow.
	Whilst protocols that encrypt DNS messages on the wire provide		Whilst protocols that encrypt DNS messages on the wire provide
	protection against certain attacks, the resolver operator still has		protection against certain attacks, the resolver operator still has
	(in principle) full visibility of the query data and transport		(in principle) full visibility of the query data and transport
	identifiers for each user. Therefore, a trust relationship exists.		identifiers for each user. Therefore, a trust relationship (whether
	The ability of the operator to provide a transparent, well		explicit or implicit) is assumed to exist between each user and the
	documented, and secure privacy service will likely serve as a major		operator of the resolver(s) used by that user. The ability of the
	differentiating factor for privacy conscious users if they make an		operator to provide a transparent, well documented, and secure
	active selection of which resolver to use.		privacy service will likely serve as a major differentiating factor
			for privacy conscious users if they make an active selection of which
			resolver to use.
	It should also be noted that the choice of a user to configure a		It should also be noted that the choice of a user to configure a
	single resolver (or a fixed set of resolvers) and an encrypted		single resolver (or a fixed set of resolvers) and an encrypted
	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		disadvantages. For example, the user has a clear expectation of
	which resolvers have visibility of their query data. However, this		which resolvers have visibility of their query data. However, this
	resolver/transport selection may provide an added mechanism to track		resolver/transport selection may provide an added mechanism to track
	them as they move across network environments. Commitments from		them as they move across network environments. Commitments from
	resolver operators to minimize such tracking as users move between		resolver operators to minimize such tracking as users move between
	networks are also likely to play a role in user selection of		networks are also likely to play a role in user selection of
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 40 ¶
	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 Recursive Operator Privacy (DROP) statement		o To introduce the DNS Recursive Operator Privacy (DROP) statement
	and present a framework to assist writers of a DROP statement. A		and present a framework to assist writers of a DROP statement. A
	DROP statement is a document that an operator should publish which		DROP statement is a document that an operator should publish which
	outlines their operational practices and commitments with regard		outlines their operational practices and commitments with regard
	to privacy, thereby providing a means for clients to evaluate the		to privacy, thereby providing a means for clients to evaluate both
	measurable and claimed privacy properties of a given DNS privacy		the measurable and claimed privacy properties of a given DNS
	service. The framework identifies a set of elements and specifies		privacy service. The framework identifies a set of elements and
	an outline order for them. This document does not, however,		specifies an outline order for them. This document does not,
	define a particular Privacy statement, nor does it seek to provide		however, define a particular Privacy statement, nor does it seek
	legal advice as to the contents.		to provide legal advice as to the contents.
	A desired operational impact is that all operators (both those		A desired operational impact is that all operators (both those
	providing resolvers within networks and those operating large public		providing resolvers within networks and those operating large public
	services) can demonstrate their commitment to user privacy thereby		services) can demonstrate their commitment to user privacy thereby
	driving all DNS resolution services to a more equitable footing.		driving all DNS resolution services to a more equitable footing.
	Choices for users would (in this ideal world) be driven by other		Choices for users would (in this ideal world) be driven by other
	factors, e.g., differing security policies or minor difference in		factors, e.g., differing security policies or minor difference in
	operator policy, rather than gross disparities in privacy concerns.		operator policy, rather than gross disparities in privacy concerns.
	Community insight [or judgment?] about operational practices can		Community insight [or judgment?] about operational practices can
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 45 ¶
	Whilst the issues raised here are targeted at those operators who		Whilst the issues raised here are targeted at those operators who
	choose to offer a DNS privacy service, considerations for areas 2 and		choose to offer a DNS privacy service, considerations for areas 2 and
	3 could equally apply to operators who only offer DNS over		3 could equally apply to operators who only offer DNS over
	unencrypted transports but who would otherwise like to align with		unencrypted transports but who would otherwise like to align with
	privacy best practice.		privacy best practice.
	3. Privacy-related documents		3. Privacy-related documents
	There are various documents that describe protocol changes that have		There are various documents that describe protocol changes that have
	the potential to either increase or decrease the privacy properties		the potential to either increase or decrease the privacy properties
	of the DNS. Note this does not imply that some documents are good or		of the DNS in various ways. Note this does not imply that some
	bad, better or worse, just that (for example) some features may bring		documents are good or bad, better or worse, just that (for example)
	functional benefits at the price of a reduction in privacy and		some features may bring functional benefits at the price of a
	conversely some features increase privacy with an accompanying		reduction in privacy and conversely some features increase privacy
	increase in complexity. A selection of the most relevant documents		with an accompanying increase in complexity. A selection of the most
	are listed in Appendix A for reference.		relevant documents are listed in 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] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	DNS terminology is as described in [RFC8499] with one modification:		DNS terminology is as described in [RFC8499] with one modification:
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	This document does not specify policy - only best practice, however		This document does not specify policy - only best practice, however
	for DNS Privacy services to be considered compliant with these best		for 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.
	In other words, these requirements are specified here as all being		The rest of this document does not use normative language but instead
	normative requirements, and are classified only by different levels		refers only to the three differing classes of action which correspond
	of compliance in the rest of the document.		to the three named levels of compliance stated above. However,
			compliance (to the indicated level) remains a normative requirement.
	5.1. On the wire between client and server		5.1. On the wire between client and server
	In this section we consider both data on the wire and the service		In this section we consider both data on the wire and the service
	provided to the client.		provided to the client.
	5.1.1. Transport recommendations		5.1.1. Transport recommendations
	[RFC6973] Threats:		[RFC6973] Threats:
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	o DNS over TLS (DoT) [RFC7858] and [RFC8310].		o DNS over TLS (DoT) [RFC7858] and [RFC8310].
	o DNS over HTTPS (DoH) [RFC8484].		o DNS over HTTPS (DoH) [RFC8484].
	It is noted that a DNS privacy service can also be provided over DNS-		It is noted that a DNS privacy service can also be provided over DNS-
	over-DTLS [RFC8094], however this is an Experimental specification		over-DTLS [RFC8094], however this is an Experimental specification
	and there are no known implementations at the time of writing.		and there are no known implementations at the time of writing.
	It is also noted that DNS privacy service might be provided over		It is also noted that DNS privacy service might be provided over
	IPSec, DNSCrypt, or VPNs. However, use of these transports for DNS		IPSec, DNSCrypt, or VPNs. However, there are no specific RFCs that
	are not standardized in DNS specific RFCs and any discussion of best		cover the use of these transports for DNS and any discussion of best
	practice for providing such a service is out of scope for this		practice for providing such a service is out of scope for this
	document.		document.
	Whilst encryption of DNS traffic can protect against active injection		Whilst encryption of DNS traffic can protect against active injection
	this does not diminish the need for DNSSEC, see Section 5.1.4.		this does not diminish the need for DNSSEC, see Section 5.1.4.
	5.1.2. Authentication of DNS privacy services		5.1.2. Authentication of DNS privacy services
	[RFC6973] Threats:		[RFC6973] Threats:
	o Surveillance:		o Surveillance:
	* Active attacks on client resolver configuration		* Active attacks on client resolver configuration
	Mitigations:		Mitigations:
	DNS privacy services should ensure clients can authenticate the		DNS privacy services should ensure clients can authenticate the
	server. Note that this, in effect, commits the DNS privacy service		server. Note that this, in effect, commits the DNS privacy service
	to a public identity users will trust.		to a public identity users will trust.
	When using DoT clients that select a 'Strict Privacy' usage profile		When using DoT, clients that select a 'Strict Privacy' usage profile
	[RFC8310] (to mitigate the threat of active attack on the client)		[RFC8310] (to mitigate the threat of active attack on the client)
	require the ability to authenticate the DNS server. To enable this,		require the ability to authenticate the DNS server. To enable this,
	DNS privacy services that offer DNS-over-TLS need to provide		DNS privacy services that offer DNS-over-TLS need to provide
	credentials in the form of either X.509 certificates [RFC5280] or		credentials that will be accepted by the client's trust model, in the
	Subject Public Key Info (SPKI) pin sets [RFC8310].		form of either X.509 certificates [RFC5280] or Subject Public Key
			Info (SPKI) pin sets [RFC8310].
	When offering DoH [RFC8484], HTTPS requires authentication of the		When offering DoH [RFC8484], HTTPS requires authentication of the
	server as part of the protocol.		server as part of the protocol.
	Server operators should also follow the best practices with regard to		Server operators should also follow the best practices with regard to
	certificate revocation as described in [RFC7525].		certificate revocation as described in [RFC7525].
	5.1.2.1. Certificate management		5.1.2.1. Certificate management
	Anecdotal evidence to date highlights the management of certificates		Anecdotal evidence to date highlights the management of certificates
	skipping to change at page 10, line 50 ¶		skipping to change at page 10, line 50 ¶
	Management of TLS connections to optimize performance for clients		Management of TLS connections to optimize performance for clients
	using DNS Stateful Operations [RFC8490].		using DNS Stateful Operations [RFC8490].
	5.1.3.2. DoH		5.1.3.2. DoH
	DNS Privacy Threats:		DNS Privacy Threats:
	o Known attacks on TLS such as those described in [RFC7457].		o Known attacks on TLS such as those described in [RFC7457].
	o Use of HTTP/2 padding and/or EDNS(0) padding as described in
	Section 9 of [RFC8484]
	o Traffic analysis, for example: [DNS-Privacy-not-so-private].		o Traffic analysis, for example: [DNS-Privacy-not-so-private].
	o Potential for client tracking via transport identifiers.		o Potential for client tracking via transport identifiers.
	Mitigations:		Mitigations:
	o Clients must be able to forgo the use of HTTP Cookies [RFC6265]		o Clients must be able to forgo the use of HTTP Cookies [RFC6265]
	and still use the service.		and still use the service.
			o Use of HTTP/2 padding and/or EDNS(0) padding as described in
			Section 9 of [RFC8484]
	o Clients should not be required to include any headers beyond the		o Clients should not be required to include any headers beyond the
	absolute minimum to obtain service from a DoH server. (See		absolute minimum to obtain service from a DoH server. (See
	Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)		Section 6.1 of [I-D.ietf-httpbis-bcp56bis].)
	5.1.4. DNSSEC		5.1.4. DNSSEC
	DNS Privacy Threats:		DNS Privacy Threats:
	o Users may be directed to bogus IP addresses which, depending on		o Users may be directed to bogus IP addresses which, depending on
	the application, protocol and authentication method, might lead		the application, protocol and authentication method, might lead
	skipping to change at page 14, line 32 ¶		skipping to change at page 14, line 32 ¶
	o Disclosure.		o Disclosure.
	Other Threats		Other Threats
	o Contravention of legal requirements not to process user data.		o Contravention of legal requirements not to process user data.
	Mitigations:		Mitigations:
	The following are recommendations relating to common activities for		The following are recommendations relating to common activities for
	DNS service operators and in all cases such activities should be		DNS service operators and in all cases data retention should be
	minimized or completely avoided if possible for DNS privacy services.		minimized or completely avoided if possible for DNS privacy services.
	If data is retained it should be encrypted and either aggregated,		If data is retained it should be encrypted and either aggregated,
	pseudonymized, or anonymized whenever possible. In general the		pseudonymized, or anonymized whenever possible. In general the
	principle of data minimization described in [RFC6973] should be		principle of data minimization described in [RFC6973] should be
	applied.		applied.
	o Transient data (e.g., that is used for real time monitoring and		o Transient data (e.g., that is used for real time monitoring and
	threat analysis which might be held only in memory) should be		threat analysis which might be held only in memory) should be
	retained for the shortest possible period deemed operationally		retained for the shortest possible period deemed operationally
	feasible.		feasible.
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 42 ¶
	5.2.4. Pseudonymization, anonymization, or discarding of other		5.2.4. Pseudonymization, anonymization, or discarding of other
	correlation data		correlation data
	DNS Privacy Threats:		DNS Privacy Threats:
	o Fingerprinting of the client OS via various means including: IP		o Fingerprinting of the client OS via various means including: IP
	TTL/Hoplimit, TCP parameters (e.g., window size, ECN support,		TTL/Hoplimit, TCP parameters (e.g., window size, ECN support,
	SACK), OS specific DNS query patterns (e.g., for network		SACK), OS specific DNS query patterns (e.g., for network
	connectivity, captive portal detection, or OS specific updates).		connectivity, captive portal detection, or OS specific updates).
	o Fingerprinting of the client application or TLS library by e.g.,		o Fingerprinting of the client application or TLS library by, e.g.,
	HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS		HTTP headers (e.g., User-Agent, Accept, Accept-Encoding), TLS
	version/Cipher suite combinations, or other connection parameters.		version/Cipher suite combinations, or other connection parameters.
	o Correlation of queries on multiple TCP sessions originating from		o Correlation of queries on multiple TCP sessions originating from
	the same IP address.		the same IP address.
	o Correlating of queries on multiple TLS sessions originating from		o Correlating of queries on multiple TLS sessions originating from
	the same client, including via session resumption mechanisms.		the same client, including via 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 Customer-premises equipment (CPE)		in EDNS(0) options - some Customer-premises equipment (CPE)
	devices are known to add them [MAC-address-EDNS].		devices are known to add them [MAC-address-EDNS].
	Mitigations:		Mitigations:
	o Data minimization or discarding of such correlation data.		o Data minimization or discarding of such correlation data.
	5.2.5. Cache snooping		5.2.5. Cache snooping
	[RFC6973] Threats:		[RFC6973] Threats:
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 13 ¶
	o As per Section 2 of [RFC7871] the server should either:		o As per Section 2 of [RFC7871] the server should either:
	* not use the ECS option in upstream queries at all, or		* not use the ECS option in upstream queries at all, or
	* offer alternative services, one that sends ECS and one that		* offer alternative services, one that sends ECS and one that
	does not.		does not.
	If operators do offer a service that sends the ECS options upstream		If operators do offer a service that sends the ECS options upstream
	they should use the shortest prefix that is operationally feasible		they should use the shortest prefix that is operationally feasible
	and ideally use a policy of allowlisting upstream servers to send ECS		and ideally use a policy of allowlisting upstream servers to send ECS
	to in order to minimize data leakage. Operators should make clear in		to in order to reduce data leakage. Operators should make clear in
	any policy statement what prefix length they actually send and the		any policy statement what prefix length they actually send and the
	specific policy used.		specific policy used.
	Allowlisting has the benefit that not only does the operator know		Allowlisting has the benefit that not only does the operator know
	which upstream servers can use ECS but also allows the operator to		which upstream servers can use ECS but also allows the operator to
	decide which upstream servers apply privacy policies that the		decide which upstream servers apply privacy policies that the
	operator is happy with. However some operators consider allowlisting		operator is happy with. However some operators consider allowlisting
	to incur significant operational overhead compared to dynamic		to incur significant operational overhead compared to dynamic
	detection of ECS on authoritative servers.		detection of ECS support on authoritative servers.
	Additional options:		Additional options:
	o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]		o Aggressive Use of DNSSEC-Validated Cache [RFC8198] and [RFC8020]
	(NXDOMAIN: There Really Is Nothing Underneath) to reduce the		(NXDOMAIN: There Really Is Nothing Underneath) 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.
	skipping to change at page 21, line 44 ¶		skipping to change at page 21, line 44 ¶
	[NOTE FOR RFC EDITOR: Please update this section to use letters for		[NOTE FOR RFC EDITOR: Please update this section to use letters for
	the sub-bullet points instead of numbers. This was not done during		the sub-bullet points instead of numbers. This was not done during
	review because the markdown tool used to write the document did not		review because the markdown tool used to write the document did not
	support it.]		support it.]
	Communicate the current operational practices of the service.		Communicate the current operational practices of the service.
	1. Deviations. Specify any temporary or permanent deviations from		1. Deviations. Specify any temporary or permanent deviations from
	the policy for operational reasons.		the policy for operational reasons.
	2. Client facing capabilities. With reference to Section 5 provide		2. Client facing capabilities. With reference to each subsection of
	specific details of which capabilities are provided on which		Section 5.1 provide specific details of which capabilities
	client facing addresses and ports:		(transport, DNSSEC, padding, etc.) are provided on which client
			facing addresses/port combination or DoH URI template. For
			Section 5.1.2, clearly specify which specific authentication
			mechanisms are supported for each endpoint that offers DoT:
	1. For DoT, specify the authentication domain name to be used		1. The authentication domain name to be used (if any).
	(if any).
	2. For DoT, specify the SPKI pin sets to be used (if any) and		2. The SPKI pin sets to be used (if any) and policy for rolling
	policy for rolling keys.		keys.
	3. Upstream capabilities. With reference to section Section 5.3		3. Upstream capabilities. With reference to section Section 5.3
	provide specific details of which capabilities are provided		provide specific details of which capabilities are provided
	upstream for data sent to authoritative servers.		upstream for data sent to authoritative servers.
	4. Support. Provide contact/support information for the service.		4. Support. Provide contact/support information for the service.
	5. Jurisdiction. This section should communicate the applicable		5. Data Processing. This section can optionally communicate links
	jurisdictions and law enforcement regimes under which the service		to and the high level contents of any separate statements the
	is being provided.		operator has published which cover applicable data processing
			legislation or agreements with regard to the location(s) of
	1. Specify the operator entity or entities that will control the		service provision.
	data and be responsible for their treatment, and their legal
	place of business.
	2. 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 exercise
	them.
	3. Additionally specify the countries in which the servers
	handling the DNS 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).
	4. Specify whether the operator has any agreement in place with
	law enforcement agencies, or other public and private
	parties, to give them access to the servers and/or to the
	data.
	6.2. Enforcement/accountability		6.2. Enforcement/accountability
	Transparency reports may help with building user trust that operators		Transparency reports may help with building user trust that operators
	adhere to their policies and practices.		adhere to their policies and practices.
	Independent monitoring or analysis could be performed where possible		Independent monitoring or analysis could be performed where possible
	of:		of:
	o ECS, QNAME minimization, EDNS(0) padding, etc.		o ECS, QNAME minimization, EDNS(0) padding, etc.
	skipping to change at page 23, line 18 ¶		skipping to change at page 22, line 50 ¶
	7. IANA considerations		7. IANA considerations
	None		None
	8. Security considerations		8. Security considerations
	Security considerations for DNS-over-TCP are given in [RFC7766], many		Security considerations for DNS-over-TCP are given in [RFC7766], many
	of which are generally applicable to session based DNS. Guidance on		of which are generally applicable to session based DNS. Guidance on
	operational requirements for DNS-over-TCP are also available in [I-		operational requirements for DNS-over-TCP are also available in [I-
	D.dnsop-dns-tcp-requirements].		D.dnsop-dns-tcp-requirements]. Security considerations for DoT are
			given in [RFC7858] and [RFC8310], those for DoH in [RFC8484].
			Security considerations for DNSSEC are given in [RFC4033], [RFC4034]
			and [RFC4035].
	9. Acknowledgements		9. Acknowledgements
	Many thanks to Amelia Andersdotter for a very thorough review of the		Many thanks to Amelia Andersdotter for a very thorough review of the
	first draft of this document and Stephen Farrell for a thorough		first draft of this document and Stephen Farrell for a thorough
	review at WGLC and for suggesting the inclusion of an example DROP		review at WGLC and for suggesting the inclusion of an example DROP
	statement. Thanks to John Todd for discussions on this topic, and to		statement. Thanks to John Todd for discussions on this topic, and to
	Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review.		Stephane Bortzmeyer, Puneet Sood and Vittorio Bertola for review.
	Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York,		Thanks to Daniel Kahn Gillmor, Barry Green, Paul Hoffman, Dan York,
	Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to		Jon Reed, Lorenzo Colitti for comments at the mic. Thanks to
	skipping to change at page 24, line 7 ¶		skipping to change at page 23, line 42 ¶
	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-10		draft-ietf-dprive-bcp-op-11
			o Improve text around use of normative language
			o Fix section 5.1.3.2 bullets
			o Improve text in 6.1.2. item 2.
			o Rework text of 6.1.2. item 5 and update example DROP
			o Various editorial improvements
	o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead		o Remove direct references to draft-ietf-dprive-rfc7626-bis, instead
	have one general reference RFC7626		have one general reference RFC7626
	o Clarify that the DROP statement outline is non-normative and add		o Clarify that the DROP statement outline is non-normative and add
	some further qualifications about content		some further qualifications about content
	o Update wording on data sharing to remove explicit discussion of		o Update wording on data sharing to remove explicit discussion of
	consent		consent
	o Move table in section 5.2.3 to an appendix		o Move table in section 5.2.3 to an appendix
	skipping to change at page 25, line 4 ¶		skipping to change at page 24, line 48 ¶
	draft-ietf-dprive-bcp-op-05		draft-ietf-dprive-bcp-op-05
	o Remove some text on consent:		o Remove some text on consent:
	* Paragraph 2 in section 5.3.3		* Paragraph 2 in section 5.3.3
	* Item 6 in the DROP Practice statement (and example)		* Item 6 in the DROP Practice statement (and example)
	o Remove .onion and TLSA options		o Remove .onion and TLSA options
	o Include ACME as a reference for certificate management
			o Include ACME as a reference for certificate management
	o Update text on session resumption usage		o Update text on session resumption usage
	o Update section 5.2.4 on client fingerprinting		o Update section 5.2.4 on client fingerprinting
	draft-ietf-dprive-bcp-op-04		draft-ietf-dprive-bcp-op-04
	o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement		o Change DPPPS to DROP (DNS Recursive Operator Privacy) statement
	o Update structure of DROP slightly		o Update structure of DROP slightly
	skipping to change at page 27, line 22 ¶		skipping to change at page 27, line 17 ¶
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[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, <https://www.rfc-
	editor.org/info/rfc6973>.		editor.org/info/rfc6973>.
			[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
			Known Attacks on Transport Layer Security (TLS) and
			Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
			February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[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>.
			[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
			Servers by Running One on Loopback", RFC 7706,
			DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
			editor.org/info/rfc7706>.
	[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and		[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
	D. Wessels, "DNS Transport over TCP - Implementation		D. Wessels, "DNS Transport over TCP - Implementation
	Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,		Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
	<https://www.rfc-editor.org/info/rfc7766>.		<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		[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 10 ¶
	[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, <https://www.rfc-
	editor.org/info/rfc7830>.		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>.
			[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
			Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
			November 2016, <https://www.rfc-editor.org/info/rfc8020>.
	[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>.
			[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
			DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
			July 2017, <https://www.rfc-editor.org/info/rfc8198>.
	[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, <https://www.rfc-
	editor.org/info/rfc8310>.		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>.
	[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms		[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
	for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,		for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
	October 2018, <https://www.rfc-editor.org/info/rfc8467>.		October 2018, <https://www.rfc-editor.org/info/rfc8467>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
			[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
			Lemon, T., and T. Pusateri, "DNS Stateful Operations",
			RFC 8490, DOI 10.17487/RFC8490, March 2019,
			<https://www.rfc-editor.org/info/rfc8490>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
	12.2. Informative References		12.2. Informative References
	[Bloom-filter]		[Bloom-filter]
	van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.		van Rijswijk-Deij, R., Rijnders, G., Bomhoff, M., and L.
	Allodi, "Privacy-Conscious Threat Intelligence Using		Allodi, "Privacy-Conscious Threat Intelligence Using
	DNSBLOOM", 2019,		DNSBLOOM", 2019,
	skipping to change at page 31, line 27 ¶		skipping to change at page 31, line 44 ¶
	PowerDNS, "dnswasher", 2019,		PowerDNS, "dnswasher", 2019,
	<https://github.com/PowerDNS/pdns/blob/master/pdns/		<https://github.com/PowerDNS/pdns/blob/master/pdns/
	dnswasher.cc>.		dnswasher.cc>.
	[Ramaswamy-and-Wolf]		[Ramaswamy-and-Wolf]
	Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving		Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving
	IP Address Anonymization for Passive Measurement Systems",		IP Address Anonymization for Passive Measurement Systems",
	2007,		2007,
	<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.		<http://www.ecs.umass.edu/ece/wolf/pubs/ton2007.pdf>.
			[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "Resource Records for the DNS Security Extensions",
			RFC 4034, DOI 10.17487/RFC4034, March 2005,
			<https://www.rfc-editor.org/info/rfc4034>.
			[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
			Rose, "Protocol Modifications for the DNS Security
			Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
			<https://www.rfc-editor.org/info/rfc4035>.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without		"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, DOI 10.17487/RFC5077,		Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
	January 2008, <https://www.rfc-editor.org/info/rfc5077>.		January 2008, <https://www.rfc-editor.org/info/rfc5077>.
	[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization		[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
	Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,		Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
	<https://www.rfc-editor.org/info/rfc6235>.		<https://www.rfc-editor.org/info/rfc6235>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011, <https://www.rfc-		DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
	editor.org/info/rfc6265>.		editor.org/info/rfc6265>.
	[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
	Known Attacks on Transport Layer Security (TLS) and
	Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
	February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,		[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
	DOI 10.17487/RFC7626, August 2015, <https://www.rfc-		DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
	editor.org/info/rfc7626>.		editor.org/info/rfc7626>.
	[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
	Servers by Running One on Loopback", RFC 7706,
	DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
	editor.org/info/rfc7706>.
	[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>.
	[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
	Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
	November 2016, <https://www.rfc-editor.org/info/rfc8020>.
	[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,		[RFC8027] Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
	"DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,		"DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
	DOI 10.17487/RFC8027, November 2016, <https://www.rfc-		DOI 10.17487/RFC8027, November 2016, <https://www.rfc-
	editor.org/info/rfc8027>.		editor.org/info/rfc8027>.
	[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, <https://www.rfc-
	editor.org/info/rfc8094>.		editor.org/info/rfc8094>.
	[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of		[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
	DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,		Pervasive Encryption on Operators", RFC 8404,
	July 2017, <https://www.rfc-editor.org/info/rfc8198>.		DOI 10.17487/RFC8404, July 2018, <https://www.rfc-
			editor.org/info/rfc8404>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	RFC 8490, DOI 10.17487/RFC8490, March 2019,
	<https://www.rfc-editor.org/info/rfc8490>.
	[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.		[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
	Kasten, "Automatic Certificate Management Environment		Kasten, "Automatic Certificate Management Environment
	(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,		(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
	<https://www.rfc-editor.org/info/rfc8555>.		<https://www.rfc-editor.org/info/rfc8555>.
	[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,		[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
	and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS		and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
	Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September		Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
	2019, <https://www.rfc-editor.org/info/rfc8618>.		2019, <https://www.rfc-editor.org/info/rfc8618>.
	skipping to change at page 34, line 34 ¶		skipping to change at page 34, line 38 ¶
	resumption.		resumption.
	o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS		o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS
	1.3		1.3
	o 'A DNS Packet Capture Format' [RFC8618].		o 'A DNS Packet Capture Format' [RFC8618].
	o Passive DNS [RFC8499].		o Passive DNS [RFC8499].
	o Section 8 of [RFC8484] outlines the privacy considerations of DoH.		o Section 8 of [RFC8484] outlines the privacy considerations of DoH.
	Note that depending on the specifics of a DoH implementation there		Note that (while that document advises exposing the minimal set of
	may be increased identification and tracking compared to other DNS		data needed to achieve the desired feature set) depending on the
	transports.		specifics of a DoH implementation there may be increased
			identification and tracking compared to other DNS transports.
	A.3. Related operational documents		A.3. Related operational documents
	o 'DNS Transport over TCP - Implementation Requirements' [RFC7766].		o 'DNS Transport over TCP - Implementation Requirements' [RFC7766].
	o 'Operational requirements for DNS-over-TCP'		o 'Operational requirements for DNS-over-TCP'
	[I-D.ietf-dnsop-dns-tcp-requirements].		[I-D.ietf-dnsop-dns-tcp-requirements].
	o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828].		o 'The edns-tcp-keepalive EDNS0 Option' [RFC7828].
	skipping to change at page 35, line 49 ¶		skipping to change at page 35, line 49 ¶
	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 [RFC8618]		be in an existing data format such as PCAP [pcap] or C-DNS [RFC8618]
	that can be used as input to existing analysis tools. In that case,		that can be used as input to existing analysis tools. In that case,
	use of a format-preserving technique is essential. This, though, is		use of a format-preserving technique is essential. This, though, is
	not cost-free - several authors (e.g., [Brenker-and-Arnes] have		not cost-free - several authors (e.g., [Brenker-and-Arnes] have
	observed that, as the entropy in an IPv4 address is limited, given a		observed that, as the entropy in an IPv4 address is limited, if an
	de-identified log from a target, if an attacker is capable of		attacker can
	ensuring packets are captured by the target and the attacker can send
	forged traffic with arbitrary source and destination addresses to		o ensure packets are captured by the target and
	that target, any format-preserving pseudonymization is vulnerable to		o send forged traffic with arbitrary source and destination
	an attack along the lines of a cryptographic chosen plaintext attack.		addresses to that target and
			o obtain a de-identified log of said traffic from that target
			any format-preserving pseudonymization is vulnerable to an attack
			along the lines of a cryptographic chosen plaintext attack.
	B.1. Categorization of techniques		B.1. Categorization of 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
	skipping to change at page 36, line 33 ¶		skipping to change at page 36, line 38 ¶
	addresses. Prefix preservation ensures that prefixes are de-		addresses. Prefix preservation ensures that prefixes are de-
	identified consistently; e.g., if two IP addresses are from the		identified consistently; e.g., if two IP addresses are from the
	same subnet, a prefix preserving de-identification will ensure		same subnet, a prefix preserving de-identification will ensure
	that their de-identified counterparts will also share a subnet.		that their de-identified counterparts will also share a subnet.
	Prefix preservation may be fixed (i.e. based on a user selected		Prefix preservation may be fixed (i.e. based on a user selected
	prefix length identified in advance to be preserved ) or general.		prefix length identified in advance to be preserved ) or general.
	o Replacement. A one-to-one replacement of a field to a new value		o Replacement. A one-to-one replacement of a field to a new value
	of the same type, for example, using a regular expression.		of the same type, for example, using a regular expression.
	o Filtering. Removing (and thus truncating) or replacing data in a		o Filtering. Removing or replacing data in a field. Field data can
	field. Field data can be overwritten, often with zeros, either		be overwritten, often with zeros, either partially (truncation or
	partially (grey marking) or completely (black marking).		reverse truncation) or completely (black-marker anonymization).
	o Generalization. Data is replaced by more general data with		o Generalization. Data is replaced by more general data with
	reduced specificity. One example would be to replace all TCP/UDP		reduced specificity. One example would be to replace all TCP/UDP
	port numbers with one of two fixed values indicating whether the		port numbers with one of two fixed values indicating whether the
	original port was ephemeral (>=1024) or non-ephemeral (>1024).		original port was ephemeral (>=1024) or non-ephemeral (>1024).
	Another example, precision degradation, reduces the accuracy of		Another example, precision degradation, reduces the accuracy of
	e.g., a numeric value or a timestamp.		e.g., a numeric value or a timestamp.
	o Enumeration. With data from a well-ordered set, replace the first		o Enumeration. With data from a well-ordered set, replace the first
	data item data using a random initial value and then allocate		data item data using a random initial value and then allocate
	skipping to change at page 37, line 29 ¶		skipping to change at page 37, line 34 ¶
	Analytics processing. This very basic anonymization simply sets to		Analytics processing. This very basic anonymization simply sets to
	zero the least significant 8 bits of IPv4 addresses, and the least		zero the least significant 8 bits of IPv4 addresses, and the least
	significant 80 bits of IPv6 addresses. The level of anonymization		significant 80 bits of IPv6 addresses. The level of anonymization
	this produces is perhaps questionable. There are some analysis		this produces is perhaps questionable. There are some analysis
	results [Geolocation-Impact-Assessement] which suggest that the		results [Geolocation-Impact-Assessement] which suggest that the
	impact of this on reducing the accuracy of determining the user's		impact of this on reducing the accuracy of determining the user's
	location from their IP address is less than might be hoped; the		location from their IP address is less than might be hoped; the
	average discrepancy in identification of the user city for UK users		average discrepancy in identification of the user city for UK users
	is no more than 17%.		is no more than 17%.
	Anonymization: Format-preserving, Filtering (grey marking).		Anonymization: Format-preserving, Filtering (trucation).
	B.2.2. dnswasher		B.2.2. dnswasher
	Since 2006, PowerDNS have included a de-identification tool dnswasher		Since 2006, PowerDNS have included a de-identification tool dnswasher
	[PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP		[PowerDNS-dnswasher] with their PowerDNS product. This is a PCAP
	filter that performs a one-to-one mapping of end user IP addresses		filter that performs a one-to-one mapping of end user IP addresses
	with an anonymized address. A table of user IP addresses and their		with an anonymized address. A table of user IP addresses and their
	de-identified counterparts is kept; the first IPv4 user addresses is		de-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
	skipping to change at page 41, line 22 ¶		skipping to change at page 41, line 28 ¶
	DoH		DoH
	+ Origin IP general geolocation information: i.e. geocode,		+ Origin IP general geolocation information: i.e. geocode,
	region ID, city ID, and metro code		region ID, city ID, and metro code
	+ IP protocol version - IPv4 or IPv6		+ IP protocol version - IPv4 or IPv6
	+ Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN,		+ Response code sent, e.g., SUCCESS, SERVFAIL, NXDOMAIN,
	etc.		etc.
	+ Absolute arrival time		+ Absolute arrival time using a precision in ms
	+ Name of the specific instance that processed this request		+ Name of the specific instance that processed this request
	+ IP address of the specific instance to which this request		+ IP address of the specific instance to which this request
	was addressed (no relation to the requestor's IP address)		was addressed (no relation to the requestor's IP address)
	We may keep the following data as summary information,		We may keep the following data as summary information,
	including all the above EXCEPT for data about the DNS record		including all the above EXCEPT for data about the DNS record
	requested:		requested:
	skipping to change at page 43, line 40 ¶		skipping to change at page 43, line 48 ¶
	3. Upstream capabilities.		3. Upstream capabilities.
	1. Our servers implement QNAME minimization.		1. Our servers implement QNAME minimization.
	2. Our servers do not send ECS upstream.		2. Our servers do not send ECS upstream.
	4. Support. Support information for this service is available at		4. Support. Support information for this service is available at
	(insert link).		(insert link).
	5. Jurisdiction.		5. Data Processing. We operate as the legal entity (insert entity)
			registered in (insert country); as such we operate under (insert
	1. We operate as the legal entity (insert entity) registered in		country/region) law. Our separate statement regarding the
	(insert country) as (insert company identifier e.g Company		specifics of our data processing policy, practice, and agreements
	Number). Our Headquarters are located at (insert address).		can be found here (insert link).
	2. As such we operate under (insert country) law. For details
	of our company privacy policy see (insert link). For
	questions on this policy and enforcement contact our Data
	Protection Officer on (insert email address).
	3. We operate servers in the following countries (insert list).
	4. We have no agreements in place with law enforcement agencies
	to give them access to the data. Apart from as stated in the
	Policy section of this document with regard to cyber threat
	intelligence, we have no agreements in place with other
	public and private parties dealing with security and
	intelligence, to give them access to the servers and/or to
	the data.
	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
End of changes. 50 change blocks.
	144 lines changed or deleted		144 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/