< draft-ietf-dprive-rfc7626-bis-07.txt		draft-ietf-dprive-rfc7626-bis-08.txt >
	dprive T. Wicinski, Ed.		dprive T. Wicinski, Ed.
	Internet-Draft October 7, 2020		Internet-Draft October 15, 2020
	Obsoletes: 7626 (if approved)		Obsoletes: 7626 (if approved)
	Intended status: Informational		Intended status: Informational
	Expires: April 10, 2021		Expires: April 18, 2021
	DNS Privacy Considerations		DNS Privacy Considerations
	draft-ietf-dprive-rfc7626-bis-07		draft-ietf-dprive-rfc7626-bis-08
	Abstract		Abstract
	This document describes the privacy issues associated with the use of		This document describes the privacy issues associated with the use of
	the DNS by Internet users. It is intended to be an analysis of the		the DNS by Internet users. It is intended to be an analysis of the
	present situation and does not prescribe solutions. This document		present situation and does not prescribe solutions. This document
	obsoletes RFC 7626.		obsoletes RFC 7626.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 10, 2021.		This Internet-Draft will expire on April 18, 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	of Section 8 of [RFC6973].		of Section 8 of [RFC6973].
	The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],		The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],
	and many later RFCs, which have never been consolidated. It is one		and many later RFCs, which have never been consolidated. It is one
	of the most important infrastructure components of the Internet and		of the most important infrastructure components of the Internet and
	often ignored or misunderstood by Internet users (and even by many		often ignored or misunderstood by Internet users (and even by many
	professionals). Almost every activity on the Internet starts with a		professionals). Almost every activity on the Internet starts with a
	DNS query (and often several). Its use has many privacy implications		DNS query (and often several). Its use has many privacy implications
	and this document is an attempt at a comprehensive and accurate list.		and this document is an attempt at a comprehensive and accurate list.
	Lets begin with a simplified reminder of how the DNS works (See also		Let us begin with a simplified reminder of how the DNS works (See
	[RFC8499]). A client, the stub resolver, issues a DNS query to a		also [RFC8499]). A client, the stub resolver, issues a DNS query to
	server, called the recursive resolver (also called caching resolver		a server, called the recursive resolver (also called caching resolver
	or full resolver or recursive name server). Let's use the query		or full resolver or recursive name server). Let's use the query
	"What are the AAAA records for www.example.com?" as an example. AAAA		"What are the AAAA records for www.example.com?" as an example. AAAA
	is the QTYPE (Query Type), and www.example.com is the QNAME (Query		is the QTYPE (Query Type), and www.example.com is the QNAME (Query
	Name). (The description that follows assumes a cold cache, for		Name). (The description that follows assumes a cold cache, for
	instance, because the server just started.) The recursive resolver		instance, because the server just started.) The recursive resolver
	will first query the root name servers. In most cases, the root name		will first query the root name servers. In most cases, the root name
	servers will send a referral. In this example, the referral will be		servers will send a referral. In this example, the referral will be
	to the .com name servers. The resolver repeats the query to one of		to the .com name servers. The resolver repeats the query to one of
	the .com name servers. The .com name servers, in turn, will refer to		the .com name servers. The .com name servers, in turn, will refer to
	the example.com name servers. The example.com name server will then		the example.com name servers. The example.com name server will then
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	unencrypted. However, there is increasing deployment of DNS-over-TLS		unencrypted. However, there is increasing deployment of DNS-over-TLS
	(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in		(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in
	mobile devices, browsers, and by providers of anycast recursive DNS		mobile devices, browsers, and by providers of anycast recursive DNS
	resolution services. There are a few cases where there is some		resolution services. There are a few cases where there is some
	alternative channel encryption, for instance, in an IPsec VPN tunnel,		alternative channel encryption, for instance, in an IPsec VPN tunnel,
	at least between the stub resolver and the resolver.		at least between the stub resolver and the resolver.
	Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].		Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
	This has practical consequences when considering encryption of the		This has practical consequences when considering encryption of the
	traffic as a possible privacy technique. Some encryption solutions		traffic as a possible privacy technique. Some encryption solutions
	are only designed for TCP, not UDP, and new solutions are still		are only designed for TCP, not UDP, although new solutions are still
	emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-dnsoquic].		emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-dnsoquic].
	Another important point to keep in mind when analyzing the privacy		Another important point to keep in mind when analyzing the privacy
	issues of DNS is the fact that DNS requests received by a server are		issues of DNS is the fact that DNS requests received by a server are
	triggered by different reasons. Let's assume an eavesdropper wants		triggered by different reasons. Let's assume an eavesdropper wants
	to know which web page is viewed by a user. For a typical web page,		to know which web page is viewed by a user. For a typical web page,
	there are three sorts of DNS requests being issued:		there are three sorts of DNS requests being issued:
	o Primary request: this is the domain name in the URL that the user		o Primary request: this is the domain name in the URL that the user
	typed, selected from a bookmark, or chose by clicking on an		typed, selected from a bookmark, or chose by clicking on an
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	user would need to take into account the set of devices used and the		user would need to take into account the set of devices used and the
	multiple dynamic contexts of each device. This document does not		multiple dynamic contexts of each device. This document does not
	attempt such a complex analysis, but instead it presents an overview		attempt such a complex analysis, but instead it presents an overview
	of the various considerations that could form the basis of such an		of the various considerations that could form the basis of such an
	analysis.		analysis.
	4. Risks in the DNS Data		4. Risks in the DNS Data
	4.1. The Public Nature of DNS Data		4.1. The Public Nature of DNS Data
	It is often stated that "the data in the DNS is public". This		It has been stated that "the data in the DNS is public". This
	sentence makes sense for an Internet-wide lookup system, and there		sentence makes sense for an Internet-wide lookup system, and there
	are multiple facets to the data and metadata involved that deserve a		are multiple facets to the data and metadata involved that deserve a
	more detailed look. First, access control lists (ACLs) and private		more detailed look. First, access control lists (ACLs) and private
	namespaces notwithstanding, the DNS operates under the assumption		namespaces notwithstanding, the DNS operates under the assumption
	that public-facing authoritative name servers will respond to "usual"		that public-facing authoritative name servers will respond to "usual"
	DNS queries for any zone they are authoritative for without further		DNS queries for any zone they are authoritative for without further
	authentication or authorization of the client (resolver). Due to the		authentication or authorization of the client (resolver). Due to the
	lack of search capabilities, only a given QNAME will reveal the		lack of search capabilities, only a given QNAME will reveal the
	resource records associated with that name (or that name's non-		resource records associated with that name (or that name's non-
	existence). In other words: one needs to know what to ask for, in		existence). In other words: one needs to know what to ask for, in
	order to receive a response. There are many ways in which supposed		order to receive a response. There are many ways in which supposedly
	"private" resources currently leak. A few examples are DNSSEC NSEC		"private" resources currently leak. A few examples are DNSSEC NSEC
	zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The		zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The
	zone transfer QTYPE [RFC5936] is often blocked or restricted to		zone transfer QTYPE [RFC5936] is often blocked or restricted to
	authenticated/authorized access to enforce this difference (and maybe		authenticated/authorized access to enforce this difference (and maybe
	for other reasons).		for other reasons).
	Another differentiation to be considered is between the DNS data		Another differencce between the DNS data and a particular DNS
	itself and a particular transaction (i.e., a DNS name lookup). DNS		transaction (i.e., a DNS name lookup). DNS data and the results of a
	data and the results of a DNS query are public, within the boundaries		DNS query are public, within the boundaries described above, and may
	described above, and may not have any confidentiality requirements.		not have any confidentiality requirements. However, the same is not
	However, the same is not true of a single transaction or a sequence		true of a single transaction or a sequence of transactions; those
	of transactions; those transactions are not / should not be public.		transactions are not / should not be public. A single transactions
	A single transactions reveals both the originator of the query and		reveals both the originator of the query and the query contents which
	the query contents which potentially leaks sensitive information		potentially leaks sensitive information about a specific user. A
	about a specific user. A typical example from outside the DNS world		typical example from outside the DNS world is: the web site of
	is: the web site of Alcoholics Anonymous is public; the fact that you		Alcoholics Anonymous is public; the fact that you visit it should not
	visit it should not be. Furthermore, the ability to link queries		be. Furthermore, the ability to link queries reveals information
	reveals information about individual use patterns.		about individual use patterns.
	4.2. Data in the DNS Request		4.2. Data in the DNS Request
	The DNS request includes many fields, but two of them seem		The DNS request includes many fields, but two of them seem
	particularly relevant for the privacy issues: the QNAME and the		particularly relevant for the privacy issues: the QNAME and the
	source IP address. "source IP address" is used in a loose sense of		source IP address. "source IP address" is used in a loose sense of
	"source IP address + maybe source port number", because the port		"source IP address + maybe source port number", because the port
	number is also in the request and can be used to differentiate		number is also in the request and can be used to differentiate
	between several users sharing an IP address (behind a Carrier-Grade		between several users sharing an IP address (behind a Carrier-Grade
	NAT (CGN), for instance [RFC6269]).		NAT (CGN), for instance [RFC6269]).
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 33 ¶
	becomes a lot more important. And email is just an example; there		becomes a lot more important. And email is just an example; there
	would be other really interesting uses for a more privacy-friendly		would be other really interesting uses for a more privacy-friendly
	DNS.		DNS.
	For the communication between the stub resolver and the recursive		For the communication between the stub resolver and the recursive
	resolver, the source IP address is the address of the user's machine.		resolver, the source IP address is the address of the user's machine.
	Therefore, all the issues and warnings about collection of IP		Therefore, all the issues and warnings about collection of IP
	addresses apply here. For the communication between the recursive		addresses apply here. For the communication between the recursive
	resolver and the authoritative name servers, the source IP address		resolver and the authoritative name servers, the source IP address
	has a different meaning; it does not have the same status as the		has a different meaning; it does not have the same status as the
	source address in an HTTP connection. It is typically the IP address		source address in an HTTP connection. It can be typically the IP
	of the recursive resolver that, in a way, "hides" the real user.		address of the recursive resolver that, in a way, "hides" the real
	However, hiding does not always work. Sometimes EDNS(0) Client		user. However, hiding does not always work. Sometimes EDNS(0)
	subnet [RFC7871] is used (see its privacy analysis in		Client subnet [RFC7871] is used (see one privacy analysis in
	[denis-edns-client-subnet]). Sometimes the end user has a personal		[denis-edns-client-subnet]). Sometimes the end user has a personal
	recursive resolver on her machine. In both cases, the IP address		recursive resolver on her machine. In both cases, the IP address
	originating queries to the authoritative server is as sensitive as it		originating queries to the authoritative server is as sensitive as it
	is for HTTP [sidn-entrada].		is for HTTP [sidn-entrada].
	A note about IP addresses: there is currently no IETF document that		A note about IP addresses: there is currently no IETF document that
	describes in detail all the privacy issues around IP addressing in		describes in detail all the privacy issues around IP addressing in
	general, although [RFC7721] does discuss privacy considerations for		general, although [RFC7721] does discuss privacy considerations for
	IPv6 address generation mechanisms. In the meantime, the discussion		IPv6 address generation mechanisms. In the meantime, the discussion
	here is intended to include both IPv4 and IPv6 source addresses. For		here is intended to include both IPv4 and IPv6 source addresses. For
	a number of reasons, their assignment and utilization characteristics		a number of reasons, their assignment and utilization characteristics
	are different, which may have implications for details of information		are different, which may have implications for details of information
	leakage associated with the collection of source addresses. (For		leakage associated with the collection of source addresses. (For
	example, a specific IPv6 source address seen on the public Internet		example, a specific IPv6 source address seen on the public Internet
	is less likely than an IPv4 address to originate behind an address		is less likely than an IPv4 address to originate behind an address
	sharing scheme.) However, for both IPv4 and IPv6 addresses, it is		sharing scheme.) However, for both IPv4 and IPv6 addresses, it is
	important to note that source addresses are propagated with queries		important to note that source addresses are propagated with queries
	and comprise metadata about the host, user, or application that		via EDNS(0) Client subnet and comprise metadata about the host, user,
	originated them.		or application that originated them.
	4.2.1. Data in the DNS Payload		4.2.1. Data in the DNS Payload
	At the time of writing there are no standardized client identifiers		At the time of writing there are no standardized client identifiers
	contained in the DNS payload itself (ECS [RFC7871] while widely used		contained in the DNS payload itself (ECS [RFC7871] while widely used
	is only of Category Informational).		is only of Category Informational).
	DNS Cookies [RFC7873] are a lightweight DNS transaction security		DNS Cookies [RFC7873] are a lightweight DNS transaction security
	mechanism that provides limited protection against a variety of		mechanism that provides limited protection against a variety of
	increasingly common denial-of-service and amplification/forgery or		increasingly common denial-of-service and amplification/forgery or
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	For unencrypted transports, DNS traffic can be seen by an		For unencrypted transports, DNS traffic can be seen by an
	eavesdropper like any other traffic. (DNSSEC, specified in		eavesdropper like any other traffic. (DNSSEC, specified in
	[RFC4033], explicitly excludes confidentiality from its goals.) So,		[RFC4033], explicitly excludes confidentiality from its goals.) So,
	if an initiator starts an HTTPS communication with a recipient, while		if an initiator starts an HTTPS communication with a recipient, while
	the HTTP traffic will be encrypted, the DNS exchange prior to it will		the HTTP traffic will be encrypted, the DNS exchange prior to it will
	not be. When other protocols will become more and more privacy-aware		not be. When other protocols will become more and more privacy-aware
	and secured against surveillance (e.g., [RFC8446],		and secured against surveillance (e.g., [RFC8446],
	[I-D.ietf-quic-transport]), the use of unencrypted transports for DNS		[I-D.ietf-quic-transport]), the use of unencrypted transports for DNS
	may become "the weakest link" in privacy. It is noted that at the		may become "the weakest link" in privacy. It is noted that at the
	time of writing there is on-going work attempting to encrypt the SNI		time of writing there is on-going work attempting to encrypt the SNI
	in the TLS handshake [RFC8744].		in the TLS handshake [RFC8744], which is one of the last remaining
			non-DNS cleartext identifiers of a connection target.
	An important specificity of the DNS traffic is that it may take a		An important specificity of the DNS traffic is that it may take a
	different path than the communication between the initiator and the		different path than the communication between the initiator and the
	recipient. For instance, an eavesdropper may be unable to tap the		recipient. For instance, an eavesdropper may be unable to tap the
	wire between the initiator and the recipient but may have access to		wire between the initiator and the recipient but may have access to
	the wire going to the recursive resolver, or to the authoritative		the wire going to the recursive resolver, or to the authoritative
	name servers.		name servers.
	The best place to tap, from an eavesdropper's point of view, is		The best place to tap, from an eavesdropper's point of view, is
	clearly between the stub resolvers and the recursive resolvers,		clearly between the stub resolvers and the recursive resolvers,
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	An increasing number of applications are offering application-		An increasing number of applications are offering application-
	specific encrypted DNS resolution settings, rather than defaulting to		specific encrypted DNS resolution settings, rather than defaulting to
	using only the system resolver. A variety of heuristics and		using only the system resolver. A variety of heuristics and
	resolvers are available in different applications including hard-		resolvers are available in different applications including hard-
	coded lists of recognized DoH/DoT servers.		coded lists of recognized DoH/DoT servers.
	Users will only be aware of and have the ability to control such		Users will only be aware of and have the ability to control such
	settings if applications provide the following functions:		settings if applications provide the following functions:
	o communicate clearly the change in default to users		o communicate clearly to users the change when the default
			application resolver changes away from the system resolver
	o provide configuration options to change the default		o provide configuration options to change the default
	o provide configuration options to always use the system resolver		o provide configuration options to always use the system resolver
	Application-specific changes to default destinations for users' DNS		Application-specific changes to default destinations for users' DNS
	queries might increase or decrease user privacy - it is highly		queries might increase or decrease user privacy - it is highly
	dependent on the network context and the application-specific		dependent on the network context and the application-specific
	default. This is an area of active debate and the IETF is working on		default. This is an area of active debate and the IETF is working on
	a number of issues related to application-specific DNS settings.		a number of issues related to application-specific DNS settings.
	skipping to change at page 14, line 40 ¶		skipping to change at page 14, line 41 ¶
	configured in a secure way with the server identity, an active		configured in a secure way with the server identity, an active
	attacker can impersonate the server. This implies that opportunistic		attacker can impersonate the server. This implies that opportunistic
	modes of DoH/DoT as well as modes where the client learns of the DoH/		modes of DoH/DoT as well as modes where the client learns of the DoH/
	DoT server via in-network mechanisms such as DHCP are vulnerable to		DoT server via in-network mechanisms such as DHCP are vulnerable to
	attack. In addition, if the client is compromised, the attacker can		attack. In addition, if the client is compromised, the attacker can
	replace the DNS configuration with one of its own choosing.		replace the DNS configuration with one of its own choosing.
	6.1.3. Blocking of User Selected DNS Resolution Services		6.1.3. Blocking of User Selected DNS Resolution Services
	User privacy can also be at risk if there is blocking of access to		User privacy can also be at risk if there is blocking of access to
	remote recursive servers that offer encrypted transports when the		remote recursive servers that offer encrypted transports e.g., when
	local resolver does not offer encryption and/or has very poor privacy		the local resolver does not offer encryption and/or has very poor
	policies. For example, active blocking of port 853 for DoT or of		privacy policies. For example, active blocking of port 853 for DoT
	specific IP addresses could restrict the resolvers available to the		or of specific IP addresses could restrict the resolvers available to
	user. The extent of the risk to end user privacy is highly dependent		the user. The extent of the risk to end user privacy is highly
	on the specific network and user context; a user on a network that is		dependent on the specific network and user context; a user on a
	known to perform surveillance would be compromised if they could not		network that is known to perform surveillance would be compromised if
	access such services, whereas a user on a trusted network might have		they could not access such services, whereas a user on a trusted
	no privacy motivation to do so.		network might have no privacy motivation to do so.
	As a matter of policy, some recursive resolvers use their position in		As a matter of policy, some recursive resolvers use their position in
	the query path to selectively block access to certain DNS records.		the query path to selectively block access to certain DNS records.
	This is a form of Rendezvous-Based Blocking as described in		This is a form of Rendezvous-Based Blocking as described in
	Section 4.3 of [RFC7754]. Such blocklists often include servers		Section 4.3 of [RFC7754]. Such blocklists often include servers
	known to be used for malware, bots or other security risks. In order		known to be used for malware, bots or other security risks. In order
	to prevent circumvention of their blocking policies, some networks		to prevent circumvention of their blocking policies, some networks
	also block access to resolvers with incompatible policies.		also block access to resolvers with incompatible policies.
	It is also noted that attacks on remote resolver services, e.g.,		It is also noted that attacks on remote resolver services, e.g.,
	DDoS, could force users to switch to other services that do not offer		DDoS, could force users to switch to other services that do not offer
	encrypted transports for DNS.		encrypted transports for DNS.
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 6 ¶
	authoritative name server sees the original IP address (or prefix,		authoritative name server sees the original IP address (or prefix,
	depending on the setup).		depending on the setup).
	As of today, all the instances of one root name server, L-root,		As of today, all the instances of one root name server, L-root,
	receive together around 50,000 queries per second. While most of it		receive together around 50,000 queries per second. While most of it
	is "junk" (errors on the Top-Level Domain (TLD) name), it gives an		is "junk" (errors on the Top-Level Domain (TLD) name), it gives an
	idea of the amount of big data that pours into name servers. (And		idea of the amount of big data that pours into name servers. (And
	even "junk" can leak information; for instance, if there is a typing		even "junk" can leak information; for instance, if there is a typing
	error in the TLD, the user will send data to a TLD that is not the		error in the TLD, the user will send data to a TLD that is not the
	usual one.)		usual one.)
	Many domains, including TLDs, are partially hosted by third-party		Many domains, including TLDs, are partially hosted by third-party
	servers, sometimes in a different country. The contracts between the		servers, sometimes in a different country. The contracts between the
	domain manager and these servers may or may not take privacy into		domain manager and these servers may or may not take privacy into
	account. Whatever the contract, the third-party hoster may be honest		account. Whatever the contract, the third-party hoster may be honest
	or not but, in any case, it will have to follow its local laws. So,		or not but, in any case, it will have to follow its local laws. For
	requests to a given ccTLD may go to servers managed by organizations		example, requests to a given ccTLD may go to servers managed by
	outside of the ccTLD's country. End users may not anticipate that,		organizations outside of the ccTLD's country. End users may not
	when doing a security analysis.		anticipate that, when doing a security analysis.
	Also, it seems (see the survey described in [aeris-dns]) that there		Also, it seems (see the survey described in [aeris-dns]) that there
	is a strong concentration of authoritative name servers among		is a strong concentration of authoritative name servers among
	"popular" domains (such as the Alexa Top N list). For instance,		"popular" domains (such as the Alexa Top N list). For instance,
	among the Alexa Top 100K [7], one DNS provider hosts today 10% of the		among the Alexa Top 100K [7], one DNS provider hosts today 10% of the
	domains. The ten most important DNS providers host together one		domains. The ten most important DNS providers host together one
	third of the domains. With the control (or the ability to sniff the		third of the domains. With the control (or the ability to sniff the
	traffic) of a few name servers, you can gather a lot of information.		traffic) of a few name servers, you can gather a lot of information.
	7. Other risks		7. Other risks
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 7 ¶
	browsing behavior, equally characteristic patterns may be produced		browsing behavior, equally characteristic patterns may be produced
	even in machine-to-machine communications or without a user taking		even in machine-to-machine communications or without a user taking
	specific actions, e.g., at reboot time if a characteristic set of		specific actions, e.g., at reboot time if a characteristic set of
	services are accessed by the device.		services are accessed by the device.
	For instance, one could imagine that an intelligence agency		For instance, one could imagine that an intelligence agency
	identifies people going to a site by putting in a very long DNS name		identifies people going to a site by putting in a very long DNS name
	and looking for queries of a specific length. Such traffic analysis		and looking for queries of a specific length. Such traffic analysis
	could weaken some privacy solutions.		could weaken some privacy solutions.
	The IAB privacy and security program also have a work in progress		The IAB privacy and security program also have a document [RFC7624]
	[RFC7624] that considers such inference-based attacks in a more		that considers such inference-based attacks in a more general
	general framework.		framework.
	7.2. More Information		7.2. More Information
	Useful background information can also be found in [tor-leak] (about		Useful background information can also be found in [tor-leak] (about
	the risk of privacy leak through DNS) and in a few academic papers:		the risk of privacy leak through DNS) and in a few academic papers:
	[yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and		[yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and
	[federrath-fuchs-herrmann-piosecny].		[federrath-fuchs-herrmann-piosecny].
	8. Actual "Attacks"		8. Actual "Attacks"
	skipping to change at page 27, line 17 ¶		skipping to change at page 27, line 17 ¶
	Update many references; Add discussions of encrypted transports		Update many references; Add discussions of encrypted transports
	including DoT and DoH; Added section on DNS payload; Add section on		including DoT and DoH; Added section on DNS payload; Add section on
	authentication of servers; Add section on blocking of services. With		authentication of servers; Add section on blocking of services. With
	the publishing of RFC7816 on QNAME minimisation, text, references,		the publishing of RFC7816 on QNAME minimisation, text, references,
	and initial attempts to measure deployment were added to reflect		and initial attempts to measure deployment were added to reflect
	this. The text and references on the Snowden revelations were		this. The text and references on the Snowden revelations were
	updated.		updated.
	The "Risks overview" section was changed to "Scope" to help clarify		The "Risks overview" section was changed to "Scope" to help clarify
	the risks being considered. Text was adding on cellular network DNS,		the risks being considered. Text was adding on cellular network DNS,
	blocking and security		blocking and security. Considerations for recursive resolvers were
			collected and placed together. Addded a discussion on resolver
			selection.
	o Collect considerations for recursive resolvers together		Appendix B. Changelog
	o Re-work several sections here to clarify their context (e.g.,		draft-ietf-dprive-rfc7626-bis-05
	'Rogue servers' becomes 'Active attacks on resolver
	configuration')
	o Add discussion of resolver selection		o Second batch of Editorial updates from IESG last call
	Appendix B. Changelog		draft-ietf-dprive-rfc7626-bis-07
			o First batch of Editorial updates from IESG last call
	draft-ietf-dprive-rfc7626-bis-06		draft-ietf-dprive-rfc7626-bis-06
	o Removed Sara and Stephane as editors, made chairs as Editor.		o Removed Sara and Stephane as editors, made chairs as Editor.
	o Replaced the text in 6.1.1.2 with the text from the -04 version.		o Replaced the text in 6.1.1.2 with the text from the -04 version.
	o Clarified text about resolver selection in 6.1.1.		o Clarified text about resolver selection in 6.1.1.
	draft-ietf-dprive-rfc7626-bis-05		draft-ietf-dprive-rfc7626-bis-05
End of changes. 23 change blocks.
	53 lines changed or deleted		59 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/