< draft-ietf-dprive-bcp-op-04.txt		draft-ietf-dprive-bcp-op-05.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: April 6, 2020 R. van Rijswijk-Deij		Expires: May 3, 2020 R. van Rijswijk-Deij
	NLnet Labs		NLnet Labs
	A. Mankin		A. Mankin
	Salesforce		Salesforce
	October 4, 2019		October 31, 2019
	Recommendations for DNS Privacy Service Operators		Recommendations for DNS Privacy Service Operators
	draft-ietf-dprive-bcp-op-04		draft-ietf-dprive-bcp-op-05
	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 framework to assist writers of a DNS		This document also presents a framework to assist writers of a DNS
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 6, 2020.		This Internet-Draft will expire on May 3, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Privacy related documents . . . . . . . . . . . . . . . . . . 5		3. Privacy related documents . . . . . . . . . . . . . . . . . . 5
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Recommendations for DNS privacy services . . . . . . . . . . 6		5. Recommendations for DNS privacy services . . . . . . . . . . 6
	5.1. On the wire between client and server . . . . . . . . . . 7		5.1. On the wire between client and server . . . . . . . . . . 7
	5.1.1. Transport recommendations . . . . . . . . . . . . . . 7		5.1.1. Transport recommendations . . . . . . . . . . . . . . 7
	5.1.2. Authentication of DNS privacy services . . . . . . . 8		5.1.2. Authentication of DNS privacy services . . . . . . . 8
	5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9		5.1.3. Protocol recommendations . . . . . . . . . . . . . . 9
	5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11		5.1.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 12		5.1.5. Availability . . . . . . . . . . . . . . . . . . . . 11
	5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12		5.1.6. Service options . . . . . . . . . . . . . . . . . . . 12
	5.1.7. Impact on DNS Privacy Service Operators . . . . . . . 12		5.1.7. Impact on DNS Privacy Service Operators . . . . . . . 12
	5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13		5.1.8. Limitations of using a pure TLS proxy . . . . . . . . 13
	5.2. Data at rest on the server . . . . . . . . . . . . . . . 14		5.2. Data at rest on the server . . . . . . . . . . . . . . . 13
	5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 14		5.2.1. Data handling . . . . . . . . . . . . . . . . . . . . 13
	5.2.2. Data minimization of network traffic . . . . . . . . 15		5.2.2. Data minimization of network traffic . . . . . . . . 14
	5.2.3. IP address pseudonymization and anonymization methods 16		5.2.3. IP address pseudonymization and anonymization methods 15
	5.2.4. Pseudonymization, anonymization or discarding of		5.2.4. Pseudonymization, anonymization or discarding of
	other correlation data . . . . . . . . . . . . . . . 17		other correlation data . . . . . . . . . . . . . . . 17
	5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 18		5.2.5. Cache snooping . . . . . . . . . . . . . . . . . . . 17
	5.3. Data sent onwards from the server . . . . . . . . . . . . 18		5.3. Data sent onwards from the server . . . . . . . . . . . . 18
	5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18		5.3.1. Protocol recommendations . . . . . . . . . . . . . . 18
	5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19		5.3.2. Client query obfuscation . . . . . . . . . . . . . . 19
	5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 20		5.3.3. Data sharing . . . . . . . . . . . . . . . . . . . . 19
	6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 21		6. DNS Recursive Operator Privacy (DROP) statement . . . . . . . 20
	6.1. Recommended contents of a DROP statement . . . . . . . . 21		6.1. Recommended contents of a DROP statement . . . . . . . . 20
	6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 21		6.1.1. Policy . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 22		6.1.2. Practice . . . . . . . . . . . . . . . . . . . . . . 21
	6.2. Current policy and privacy statements . . . . . . . . . . 23		6.2. Current policy and privacy statements . . . . . . . . . . 22
	6.3. Enforcement/accountability . . . . . . . . . . . . . . . 24		6.3. Enforcement/accountability . . . . . . . . . . . . . . . 23
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
	8. Security considerations . . . . . . . . . . . . . . . . . . . 24		8. Security considerations . . . . . . . . . . . . . . . . . . . 23
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	12.1. Normative References . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . 26
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31		Appendix A. Documents . . . . . . . . . . . . . . . . . . . . . 31
	A.1. Potential increases in DNS privacy . . . . . . . . . . . 32		A.1. Potential increases in DNS privacy . . . . . . . . . . . 31
	A.2. Potential decreases in DNS privacy . . . . . . . . . . . 32		A.2. Potential decreases in DNS privacy . . . . . . . . . . . 31
	A.3. Related operational documents . . . . . . . . . . . . . . 33		A.3. Related operational documents . . . . . . . . . . . . . . 32
	Appendix B. IP address techniques . . . . . . . . . . . . . . . 33		Appendix B. IP address techniques . . . . . . . . . . . . . . . 32
	B.1. Google Analytics non-prefix filtering . . . . . . . . . . 34		B.1. Google Analytics non-prefix filtering . . . . . . . . . . 33
	B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 34		B.2. dnswasher . . . . . . . . . . . . . . . . . . . . . . . . 33
	B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 35		B.3. Prefix-preserving map . . . . . . . . . . . . . . . . . . 34
	B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 35		B.4. Cryptographic Prefix-Preserving Pseudonymisation . . . . 34
	B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 35		B.5. Top-hash Subtree-replicated Anonymisation . . . . . . . . 34
	B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 36		B.6. ipcipher . . . . . . . . . . . . . . . . . . . . . . . . 35
	B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 36		B.7. Bloom filters . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix C. Example DROP statement . . . . . . . . . . . . . . . 36		Appendix C. Example DROP statement . . . . . . . . . . . . . . . 35
	C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 37		C.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 36
	C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 39		C.2. Practice . . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is at the core of the Internet; almost		The Domain Name System (DNS) is at the core of the Internet; almost
	every activity on the Internet starts with a DNS query (and often		every activity on the Internet starts with a DNS query (and often
	several). However the DNS was not originally designed with strong		several). However the DNS was not originally designed with strong
	security or privacy mechanisms. A number of developments have taken		security or privacy mechanisms. A number of developments have taken
	place in recent years which aim to increase the privacy of the DNS		place in recent years which aim to increase the privacy of the DNS
	system and these are now seeing some deployment. This latest		system and these are now seeing some deployment. This latest
	evolution of the DNS presents new challenges to operators and this		evolution of the DNS presents new challenges to operators and this
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 38 ¶
	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		provide credentials in the form of either X.509 certificates
	[RFC5280] or SPKI pin sets [RFC8310].		[RFC5280] or 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.
	Optimizations:
	DNS privacy services can also consider the following capabilities/
	options:
	o As recommended in [RFC8310] providing DANE TLSA records for the
	nameserver
	* In particular, the service could provide TLSA records such that
	authenticating solely via the PKIX infrastructure can be
	avoided.
	5.1.2.1. Certificate management		5.1.2.1. Certificate management
	Anecdotal evidence to date highlights the management of certificates		Anecdotal evidence to date highlights the management of certificates
	as one of the more challenging aspects for operators of traditional		as one of the more challenging aspects for operators of traditional
	DNS resolvers that choose to additionally provide a DNS privacy		DNS resolvers that choose to additionally provide a DNS privacy
	service as management of such credentials is new to those DNS		service as management of such credentials is new to those DNS
	operators.		operators.
	It is noted that SPKI pin set management is described in [RFC7858]		It is noted that SPKI pin set management is described in [RFC7858]
	but that key pinning mechanisms in general have fallen out of favor		but that key pinning mechanisms in general have fallen out of favor
	skipping to change at page 9, line 34 ¶		skipping to change at page 9, line 19 ¶
	Mitigations:		Mitigations:
	It is recommended that operators:		It is recommended that operators:
	o Follow the guidance in Section 6.5 of [RFC7525] with regards to		o Follow the guidance in Section 6.5 of [RFC7525] with regards to
	certificate revocation		certificate revocation
	o Choose a short, memorable authentication name for the service		o Choose a short, memorable authentication name for the service
	o Automate the generation and publication of certificates		o Automate the generation, publication and renewal of certificates.
			For example, ACME [RFC8555] provides a mechanism to actively
			manage certificates through automation and has been implemented by
			a number of certificate authorities.
	o Monitor certificates to prevent accidental expiration of		o Monitor certificates to prevent accidental expiration of
	certificates		certificates
	5.1.3. Protocol recommendations		5.1.3. Protocol recommendations
	5.1.3.1. DNS-over-TLS		5.1.3.1. DNS-over-TLS
	DNS Privacy Threats:		DNS Privacy Threats:
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 4 ¶
	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
	[RFC8467] or a successor specification.		[RFC8467] or a successor specification.
	o Clients should not be required to use TLS session resumption		o Servers should not degrade in any way the query service level
	[RFC5077] with TLS 1.2 or Domain Name System (DNS) Cookies		provided to clients that do not use any form of session resumption
			mechanism, such as TLS session resumption [RFC5077] with TLS 1.2,
			section 2.2 of RFC8446, or Domain Name System (DNS) Cookies
	[RFC7873].		[RFC7873].
	o A DNS-over-TLS privacy service on both port 853 and 443. This		o A DNS-over-TLS privacy service on both port 853 and 443. This
	practice may not be possible if e.g. the operator deploys DoH on		practice may not be possible if e.g. the operator deploys DoH on
	the same IP address.		the same IP address.
	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 [RFC8490]		* DNS Stateful Operations [RFC8490]
	Additional options that providers may consider:
	o Offer a .onion [RFC7686] service endpoint
	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 Traffic analysis, for example: DNS Privacy not so private: the		o Traffic analysis, for example: DNS Privacy not so private: the
	traffic analysis perspective [1]		traffic analysis perspective [1]
	o Potential for client tracking via transport identifiers		o Potential for client tracking via transport identifiers
	skipping to change at page 17, line 51 ¶		skipping to change at page 17, line 13 ¶
	ensuring packets are captured by the target and the attacker can send		ensuring packets are captured by the target and the attacker can send
	forged traffic with arbitrary source and destination addresses to		forged traffic with arbitrary source and destination addresses to
	that target, any format-preserving pseudonymization is vulnerable to		that target, any format-preserving pseudonymization is vulnerable to
	an attack along the lines of a cryptographic chosen plaintext attack.		an attack along the lines of a cryptographic chosen plaintext attack.
	5.2.4. Pseudonymization, anonymization or discarding of other		5.2.4. Pseudonymization, anonymization or discarding of other
	correlation data		correlation data
	DNS Privacy Threats:		DNS Privacy Threats:
	o IP TTL/Hoplimit can be used to fingerprint client OS		o Fingerprinting of the client OS via various means including: IP
	o TLS version/Cipher suite combinations can be used to fingerprint		TTL/Hoplimit, TCP parameters (e.g. window size, ECN support,
	the client application or TLS library		SACK), OS specific DNS query patterns (e.g. for network
			connectivity, captive portal detection or OS specific updates).
	o Tracking of TCP sessions		o Fingerprinting of the client application or TLS library by e.g.
			TLS version/Cipher suite combinations or other connection
			parameters.
	o Tracking of TLS sessions and session resumption mechanisms		o Correlation of queries on multiple TCP session originating from
			the same IP address
			o Correlating of queries on multiple TLS sessions originating from
			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 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 (e.g., User-Agent, Accept, Accept-Encoding)
	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:
	o Surveillance:		o Surveillance:
	skipping to change at page 20, line 32 ¶		skipping to change at page 20, line 4 ¶
	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:		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
	minimization techniques such as those described in Section 5.2.1 if
	data is shared with third-parties.
	Operators should consider including specific guidelines for the		Operators should consider including specific guidelines for the
	collection of aggregated and/or anonymized data for research		collection of aggregated and/or anonymized data for research
	purposes, within or outside of their own organization. This can		purposes, within or outside of their own organization. This can
	benefit not only the operator (through inclusion in novel research)		benefit not only the operator (through inclusion in novel research)
	but also the wider Internet community. See SURFnet's policy [11] on		but also the wider Internet community. See SURFnet's policy [11] on
	data sharing for research as an example.		data sharing for research as an example.
	6. DNS Recursive Operator Privacy (DROP) statement		6. DNS Recursive Operator Privacy (DROP) statement
	The following section outlines the recommended contents of a DROP		The following section outlines the recommended contents of a DROP
	skipping to change at page 22, line 31 ¶		skipping to change at page 21, line 48 ¶
	service.		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 Section 5		2. Client facing capabilities. With reference to section Section 5
	provide specific details of which capabilities are provided on		provide specific details of which capabilities are provided on
	which client facing addresses and ports:		which client facing addresses and ports:
	1. For DoT, specify the authentication name to be used (if any)		1. For DoT, specify the authentication name to be used (if any)
	and if TLSA records are published (including options used in
	the TLSA records)
	2. For DoT, specify the SPKI pin sets to be used (if any) and		2. For DoT, specify the SPKI pin sets to be used (if any) and
	policy for rolling keys		policy for rolling 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.
	skipping to change at page 23, line 23 ¶		skipping to change at page 22, line 37 ¶
	handling the DNS requests and the data are located (if the		handling the DNS requests and the data are located (if the
	operator applies a geolocation policy so that requests from		operator applies a geolocation policy so that requests from
	certain countries are only served by certain servers, this		certain countries are only served by certain servers, this
	should be specified as well).		should be specified as well).
	4. Specify whether the operator has any agreement in place with		4. Specify whether the operator has any agreement in place with
	law enforcement agencies, or other public and private parties		law enforcement agencies, or other public and private parties
	dealing with security and intelligence, to give them access		dealing with security and intelligence, to give them access
	to the servers and/or to the data.		to the servers and/or to the data.
	6. Consent. For any activity which is documented in this statement
	as 'requiring consent' before being performed, describe the full
	process of what you as an operator consider 'obtaining consent',
	distinguishing clearly between any implicit and explicit consent
	models. Additionally, state if these processes are considered by
	you the operator to conform to any relevant legislation (this may
	prove relevant in the context of e.g. the GDPR as it relates to
	consent).
	6.2. Current policy and privacy statements		6.2. Current policy and privacy statements
	A tabular comparison of existing policy and privacy statements from		A tabular comparison of existing policy and privacy statements from
	various DNS Privacy service operators based loosely on the proposed		various DNS Privacy service operators based loosely on the proposed
	DROP structure can be found on dnsprivacy.org [12].		DROP structure can be found on dnsprivacy.org [12].
	We note that the existing set of policies vary widely in style,		We note that the existing set of policies vary widely in style,
	content and detail and it is not uncommon for the full text for a		content and detail and it is not uncommon for the full text for a
	given operator to equate to more than 10 pages of moderate font sized		given operator to equate to more than 10 pages of moderate font sized
	A4 text. It is a non-trivial task today for a user to extract a		A4 text. It is a non-trivial task today for a user to extract a
	skipping to change at page 25, line 25 ¶		skipping to change at page 24, 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-05
			o Remove some text on consent:
			* Paragraph 2 in section 5.3.3
			* Item 6 in the DROP Practice statement (and example)
			o Remove .onion and TLSA options
			o Include ACME as a reference for certificate management
			o Update text on session resumption usage
			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
	o Add example DROP statement		o Add example DROP statement
	o Add text about restricting access to full logs		o Add text about restricting access to full logs
	skipping to change at page 29, line 42 ¶		skipping to change at page 29, line 10 ¶
	[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>.
	[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing		[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
	Known Attacks on Transport Layer Security (TLS) and		Known Attacks on Transport Layer Security (TLS) and
	Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,		Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
	February 2015, <https://www.rfc-editor.org/info/rfc7457>.		February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
	Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
	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, <https://www.rfc-
	editor.org/info/rfc7706>.		editor.org/info/rfc7706>.
	[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>.
	skipping to change at page 30, line 23 ¶		skipping to change at page 29, line 33 ¶
	[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",		Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	RFC 8490, DOI 10.17487/RFC8490, March 2019,		RFC 8490, DOI 10.17487/RFC8490, March 2019,
	<https://www.rfc-editor.org/info/rfc8490>.		<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>.
			[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
			Kasten, "Automatic Certificate Management Environment
			(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
			<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>.
	12.3. URIs		12.3. URIs
	[1] https://petsymposium.org/2018/files/hotpets/4-siby.pdf		[1] https://petsymposium.org/2018/files/hotpets/4-siby.pdf
	[2] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/		[2] http://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/
	skipping to change at page 39, line 48 ¶		skipping to change at page 39, line 4 ¶
	form (insert link) if you believe we are blocking a		form (insert link) if you believe we are blocking a
	domain in error.		domain in error.
	C.2. Practice		C.2. Practice
	1. Deviations from Policy. None currently in place.		1. Deviations from Policy. None currently in place.
	2. Client facing capabilities.		2. Client facing capabilities.
	1. We offer UDP and TCP DNS on port 53 on (insert IP address)		1. We offer UDP and TCP DNS on port 53 on (insert IP address)
	2. We offer DNS-over-TLS as specified in RFC7858 on (insert IP		2. We offer DNS-over-TLS as specified in RFC7858 on (insert IP
	address). It is available on port 853 and port 443. We also		address). It is available on port 853 and port 443. We also
	implement RFC7766.		implement RFC7766.
	1. The DoT authentication name used is (insert domain name).		1. The DoT authentication name used is (insert domain name).
	No TLSA records are available for this domain name.
	2. We do not publish SPKI pin sets.		2. We do not publish SPKI pin sets.
	3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert		3. We offer DNS-over-HTTPS as specified in RFC8484 on (insert
	URI template). Both POST and GET are supported.		URI template). Both POST and GET are supported.
	4. Both services offer TLS 1.2 and TLS 1.3.		4. Both services offer TLS 1.2 and TLS 1.3.
	5. Both services pad DNS responses according to RFC8467.		5. Both services pad DNS responses according to RFC8467.
	skipping to change at page 40, line 49 ¶		skipping to change at page 40, line 5 ¶
	3. We operate servers in the following countries (insert list).		3. We operate servers in the following countries (insert list).
	4. We have no agreements in place with law enforcement agencies		4. We have no agreements in place with law enforcement agencies
	to give them access to the data. Apart from as stated in the		to give them access to the data. Apart from as stated in the
	Policy section of this document with regard to cyber threat		Policy section of this document with regard to cyber threat
	intelligence, we have no agreements in place with other		intelligence, we have no agreements in place with other
	public and private parties dealing with security and		public and private parties dealing with security and
	intelligence, to give them access to the servers and/or to		intelligence, to give them access to the servers and/or to
	the data.		the data.
	6. Consent. As described, we do not intentionally share, sell, or
	rent individual personal information associated with the
	requestor with anyone without your consent. In order to provide
	consent you must have a user account for our service - this can
	be set up via our support page (insert link). We may contact
	existing users with accounts to enquire if you would be willing
	to provide consent for specific situations. Users can then
	provide explicit consent by choosing to enable certain account
	options which are disabled by default.
	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
End of changes. 29 change blocks.
	98 lines changed or deleted		82 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/