draft-ietf-dprive-problem-statement-02.txt		draft-ietf-dprive-problem-statement-03.txt
	DNS PRIVate Exchange (dprive) Working Group S. Bortzmeyer		DNS PRIVate Exchange (dprive) Working Group S. Bortzmeyer
	Internet-Draft AFNIC		Internet-Draft AFNIC
	Intended status: Informational February 19, 2015		Intended status: Informational March 9, 2015
	Expires: August 23, 2015		Expires: September 10, 2015
	DNS privacy considerations		DNS privacy considerations
	draft-ietf-dprive-problem-statement-02		draft-ietf-dprive-problem-statement-03
	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.		present situation and does not prescribe solutions.
	Discussions of the document should take place on the DPRIVE working		(REMOVE BEFORE PUBLICATION: Discussions of the document should take
	group mailing list [dprive].		place on the DPRIVE working group mailing list [dprive].)
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at 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 August 23, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. The alleged public nature of DNS data . . . . . . . . . . 4		2.1. The alleged public nature of DNS data . . . . . . . . . . 5
	2.2. Data in the DNS request . . . . . . . . . . . . . . . . . 5		2.2. Data in the DNS request . . . . . . . . . . . . . . . . . 5
	2.3. Cache snooping . . . . . . . . . . . . . . . . . . . . . 6		2.3. Cache snooping . . . . . . . . . . . . . . . . . . . . . 6
	2.4. On the wire . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. On the wire . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5. In the servers . . . . . . . . . . . . . . . . . . . . . 8		2.5. In the servers . . . . . . . . . . . . . . . . . . . . . 8
	2.5.1. In the recursive resolvers . . . . . . . . . . . . . 8		2.5.1. In the recursive resolvers . . . . . . . . . . . . . 8
	2.5.2. In the authoritative name servers . . . . . . . . . . 8		2.5.2. In the authoritative name servers . . . . . . . . . . 9
	2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 10		2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 10
			2.6. Re-identification and other inferences . . . . . . . . . 10
	3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 10		3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 10
	4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security considerations . . . . . . . . . . . . . . . . . . . 11		5. Security considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document is an analysis of the DNS privacy issues, in the spirit		This document is an analysis of the DNS privacy issues, in the spirit
	of section 8 of [RFC6973].		of section 8 of [RFC6973].
	The Domain Name System is specified in [RFC1034] and [RFC1035]. It		The Domain Name System is specified in [RFC1034] and [RFC1035]. It
	is one of the most important infrastructure components of the		is one of the most important infrastructure components of the
	Internet and often ignored or misunderstood. Almost every activity		Internet and often ignored or misunderstood. Almost every activity
	on the Internet starts with a DNS query (and often several). Its use		on the Internet starts with a DNS query (and often several). Its use
	skipping to change at page 2, line 50		skipping to change at page 2, line 51
	comprehensive and accurate list.		comprehensive and accurate list.
	Let us begin with a simplified reminder of how the DNS works.		Let us begin with a simplified reminder of how the DNS works.
	(REMOVE BEFORE PUBLICATION: We hope that the document		(REMOVE BEFORE PUBLICATION: We hope that the document
	[I-D.hoffman-dns-terminology] will be published as a RFC so most of		[I-D.hoffman-dns-terminology] will be published as a RFC so most of
	this section could be replaced by a reference to it.) A client, the		this section could be replaced by a reference to it.) A client, the
	stub resolver, issues a DNS query to a server, called the recursive		stub resolver, issues a DNS query to a server, called the recursive
	resolver (also called caching resolver or full resolver or recursive		resolver (also called caching resolver or full resolver or recursive
	name server). Let's use the query "What are the AAAA records for		name server). Let's use the query "What are the AAAA records for
	www.example.com?" as an example. AAAA is the qtype (Query Type), and		www.example.com?" as an example. AAAA is the qtype (Query Type), and
	www.example.com is the qname (Query Name). The recursive resolver		www.example.com is the qname (Query Name). (The description which
	will first query the root nameservers. In most cases, the root		follows assume a cold cache, for instance because the server just
	nameservers will send a referral. In this example, the referral will		started.) The recursive resolver will first query the root
	be to the .com nameservers. The resolver repeats the query to one of		nameservers. In most cases, the root nameservers will send a
	the .com nameservers. The .com nameservers, in turn, will refer to		referral. In this example, the referral will be to the .com
	the example.com nameservers. The example.com nameserver will then		nameservers. The resolver repeats the query to one of the .com
	return the answer. The root name servers, the name servers of .com		nameservers. The .com nameservers, in turn, will refer to the
	and the name servers of example.com are called authoritative name		example.com nameservers. The example.com nameserver will then return
	servers. It is important, when analyzing the privacy issues, to		the answer. The root name servers, the name servers of .com and the
	remember that the question asked to all these name servers is always		name servers of example.com are called authoritative name servers.
	the original question, not a derived question. The question sent to		It is important, when analyzing the privacy issues, to remember that
	the root name servers is "What are the AAAA records for		the question asked to all these name servers is always the original
	www.example.com?", not "What are the name servers of .com?". By		question, not a derived question. The question sent to the root name
	repeating the full question, instead of just the relevant part of the		servers is "What are the AAAA records for www.example.com?", not
	question to the next in line, the DNS provides more information than		"What are the name servers of .com?". By repeating the full
	necessary to the nameserver.		question, instead of just the relevant part of the question to the
			next in line, the DNS provides more information than necessary to the
			nameserver.
	Because DNS relies on caching heavily, not all questions are sent to		Because DNS relies on caching heavily, the algorithm described just
	the authoritative name servers. If a few seconds later the stub		above is actually a bit more complicated, and not all questions are
	resolver asks to the recursive resolver, "What are the SRV records of		sent to the authoritative name servers. If a few seconds later the
	_xmpp-server._tcp.example.com?", the recursive resolver will remember		stub resolver asks to the recursive resolver, "What are the SRV
	that it knows the name servers of example.com and will just query		records of _xmpp-server._tcp.example.com?", the recursive resolver
	them, bypassing the root and .com. Because there is typically no		will remember that it knows the name servers of example.com and will
	caching in the stub resolver, the recursive resolver, unlike the		just query them, bypassing the root and .com. Because there is
	authoritative servers, sees all the DNS traffic. (Applications, like		typically no caching in the stub resolver, the recursive resolver,
	Web browsers, may have some form of caching, which do not follow DNS		unlike the authoritative servers, sees all the DNS traffic.
	rules. So, the recursive resolver does not see all the name		(Applications, like Web browsers, may have some form of caching,
	resolution activity.)		which do not follow DNS rules. So, the recursive resolver does not
			see all the name resolution activity.)
	It should be noted that DNS recursive resolvers sometimes forward		It should be noted that DNS recursive resolvers sometimes forward
	requests to other recursive resolvers, typically bigger machines,		requests to other recursive resolvers, typically bigger machines,
	with a larger and more shared cache (and the query hierarchy can be		with a larger and more shared cache (and the query hierarchy can be
	even deeper, with more than two levels of recursive resolvers). From		even deeper, with more than two levels of recursive resolvers). From
	the point of view of privacy, these forwarders are like resolvers,		the point of view of privacy, these forwarders are like resolvers,
	except that they do not see all of the requests being made (due to		except that they do not see all of the requests being made (due to
	caching in the first resolver).		caching in the first resolver).
	All this DNS traffic is currently sent in clear (unencryted), except		All this DNS traffic is currently sent in clear (unencryted), except
	skipping to change at page 5, line 41		skipping to change at page 5, line 49
	address (behind a CGN for instance [RFC6269]).		address (behind a CGN for instance [RFC6269]).
	The qname is the full name sent by the user. It gives information		The qname is the full name sent by the user. It gives information
	about what the user does ("What are the MX records of example.net?"		about what the user does ("What are the MX records of example.net?"
	means he probably wants to send email to someone at example.net,		means he probably wants to send email to someone at example.net,
	which may be a domain used by only a few persons and therefore very		which may be a domain used by only a few persons and therefore very
	revealing about communication relationships). Some qnames are more		revealing about communication relationships). Some qnames are more
	sensitive than others. For instance, querying the A record of		sensitive than others. For instance, querying the A record of
	google-analytics.com reveals very little (everybody visits Web sites		google-analytics.com reveals very little (everybody visits Web sites
	which use Google Analytics) but querying the A record of		which use Google Analytics) but querying the A record of
	www.verybad.example where verybad.example is the domain of an illegal		www.verybad.example where verybad.example is the domain of an
	or very offensive organization may create more problems for the user.		organization that some people find offensive or objectionable, may
	Also, sometimes, the qname embeds the software one uses, which could		create more problems for the user. Also, sometimes, the qname embeds
	be a privacy issue. For instance, _ldap._tcp.Default-First-Site-		the software one uses, which could be a privacy issue. For instance,
	Name._sites.gc._msdcs.example.org. There are also some BitTorrent		_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
	clients that query a SRV record for _bittorrent-		There are also some BitTorrent clients that query a SRV record for
	tracker._tcp.domain.example.		_bittorrent-tracker._tcp.domain.example.
	Another important thing about the privacy of the qname is the future		Another important thing about the privacy of the qname is the future
	usages. Today, the lack of privacy is an obstacle to putting		usages. Today, the lack of privacy is an obstacle to putting
	potentially sensitive or personally identifiable data in the DNS. At		potentially sensitive or personally identifiable data in the DNS. At
	the moment your DNS traffic might reveal that you are doing email but		the moment your DNS traffic might reveal that you are doing email but
	not with whom. If your MUA starts looking up PGP keys in the DNS		not with whom. If your MUA starts looking up PGP keys in the DNS
	[I-D.wouters-dane-openpgp] then privacy becomes a lot more important.		[I-D.wouters-dane-openpgp] then privacy becomes a lot more important.
	And email is just an example; there would be other really interesting		And email is just an example; there would be other really interesting
	uses for a more privacy-friendly DNS.		uses for a more privacy-friendly DNS.
	skipping to change at page 10, line 18		skipping to change at page 10, line 22
	configuration altered by malicious parties, can direct you to a rogue		configuration altered by malicious parties, can direct you to a rogue
	recursive resolver. Most of the time, it seems to be done to divert		recursive resolver. Most of the time, it seems to be done to divert
	traffic, by providing lies for some domain names. But it could be		traffic, by providing lies for some domain names. But it could be
	used just to capture the traffic and gather information about you.		used just to capture the traffic and gather information about you.
	Same thing for malware like DNSchanger[dnschanger] which changes the		Same thing for malware like DNSchanger[dnschanger] which changes the
	recursive resolver in the machine's configuration, or with		recursive resolver in the machine's configuration, or with
	transparent DNS proxies in the network that will divert the traffic		transparent DNS proxies in the network that will divert the traffic
	intended for a legitimate DNS server (for instance		intended for a legitimate DNS server (for instance
	[turkey-googledns]).		[turkey-googledns]).
			2.6. Re-identification and other inferences
			An observer has access not only to the data he/she directly collects
			but also to the results of various inferences about these data.
			For instance, an user can be re-identified via DNS queries. If the
			adversary knows a user's identity and can watch their DNS queries for
			a period, then that same adversary may be able to re-identify the
			user solely based on their pattern of DNS queries later on regardless
			of the location from which the user makes those queries. For
			example, one study [herrmann-reidentification] found that such re-
			identification is possible so that "73.1% of all day-to-day links
			were correctly established, i.e. user u was either re-identified
			unambiguously (1) or the classifier correctly reported that u was not
			present on day t+1 any more (2)". While that study related to web
			browsing behaviour, equally characteristic patterns may be produced
			even in machine-to-machine communications or without a user taking
			specific actions, e.g. at reboot time if a characteristic set of
			services are accessed by the device.
			The IAB privacy and security programme also have a work in progress
			[I-D.iab-privsec-confidentiality-threat] that considers such
			inference based attacks in a more general framework.
	3. Actual "attacks"		3. Actual "attacks"
	A very quick examination of DNS traffic may lead to the false		A very quick examination of DNS traffic may lead to the false
	conclusion that extracting the needle from the haystack is difficult.		conclusion that extracting the needle from the haystack is difficult.
	"Interesting" primary DNS requests are mixed with useless (for the		"Interesting" primary DNS requests are mixed with useless (for the
	eavesdropper) secondary and tertiary requests (see the terminology in		eavesdropper) secondary and tertiary requests (see the terminology in
	Section 1). But, in this time of "big data" processing, powerful		Section 1). But, in this time of "big data" processing, powerful
	techniques now exist to get from the raw data to what the		techniques now exist to get from the raw data to what the
	eavesdropper is actually interested in.		eavesdropper is actually interested in.
	skipping to change at page 10, line 50		skipping to change at page 11, line 30
	And there is still the potential problems with revealing qnames.		And there is still the potential problems with revealing qnames.
	The revelations (from the Edward Snowden documents, leaked from the		The revelations (from the Edward Snowden documents, leaked from the
	NSA) of the MORECOWBELL surveillance program [morecowbell], which		NSA) of the MORECOWBELL surveillance program [morecowbell], which
	uses the DNS, both passively and actively, to gather surreptitiously		uses the DNS, both passively and actively, to gather surreptitiously
	information about the users, is another good example that the lack of		information about the users, is another good example that the lack of
	privacy protections in the DNS is actively exploited.		privacy protections in the DNS is actively exploited.
	4. Legalities		4. Legalities
	To our knowledge, there are no specific privacy laws for DNS data.		To our knowledge, there are no specific privacy laws for DNS data, in
	Interpreting general privacy laws like [data-protection-directive]		any country. Interpreting general privacy laws like
	(European Union) in the context of DNS traffic data is not an easy		[data-protection-directive] (European Union) in the context of DNS
	task and it seems there is no court precedent here.		traffic data is not an easy task and it seems there is no court
			precedent here.
	5. Security considerations		5. Security considerations
	This document is entirely about security, more precisely privacy. It		This document is entirely about security, more precisely privacy. It
	just lays out the problem, it does not try to set requirments (with		just lays out the problem, it does not try to set requirments (with
	the choices and compromises they imply), much less to define		the choices and compromises they imply), much less to define
	solutions. A possible document on requirments for DNS privacy is		solutions. A possible document on requirments for DNS privacy is
	[I-D.hallambaker-dnse]. Possible solutions to the issues described		[I-D.hallambaker-dnse]. Possible solutions to the issues described
	here are discussed in other documents (currently too many to all be		here are discussed in other documents (currently too many to all be
	mentioned), see for instance [I-D.ietf-dnsop-qname-minimisation] for		mentioned), see for instance [I-D.ietf-dnsop-qname-minimisation] for
	the minimisation of data, or [I-D.hzhwm-start-tls-for-dns] about		the minimisation of data, or [I-D.hzhwm-start-tls-for-dns] about
	encryption.		encryption.
	6. Acknowledgments		6. Acknowledgments
	Thanks to Nathalie Boulvard and to the CENTR members for the original		Thanks to Nathalie Boulvard and to the CENTR members for the original
	work which leaded to this document. Thanks to Ondrej Sury for the		work which leaded to this document. Thanks to Ondrej Sury for the
	interesting discussions. Thanks to Mohsen Souissi and John Heidemann		interesting discussions. Thanks to Mohsen Souissi and John Heidemann
	for proofreading, to Paul Hoffman, Marcos Sanz, Tim Wicinski, Allison		for proofreading, to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim
	Mankin and Warren Kumari for proofreading, technical remarks, and		Wicinski, Allison Mankin and Warren Kumari for proofreading,
	many readability improvements. Thanks to Dan York, Suzanne Woolf,		technical remarks, and many readability improvements. Thanks to Dan
	Tony Finch, Peter Koch and Frank Denis for good written		York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter Koch and
	contributions.		Frank Denis for good written contributions.
	7. IANA considerations		7. IANA considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	skipping to change at page 12, line 27		skipping to change at page 13, line 14
	[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.		[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
	Roberts, "Issues with IP Address Sharing", RFC 6269, June		Roberts, "Issues with IP Address Sharing", RFC 6269, June
	2011.		2011.
	[I-D.ietf-dnsop-edns-client-subnet]		[I-D.ietf-dnsop-edns-client-subnet]
	Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,		Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,
	"Client Subnet in DNS Requests", draft-ietf-dnsop-edns-		"Client Subnet in DNS Requests", draft-ietf-dnsop-edns-
	client-subnet-00 (work in progress), November 2014.		client-subnet-00 (work in progress), November 2014.
			[I-D.iab-privsec-confidentiality-threat]
			Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
			Trammell, B., Huitema, C., and D. Borkmann,
			"Confidentiality in the Face of Pervasive Surveillance: A
			Threat Model and Problem Statement", draft-iab-privsec-
			confidentiality-threat-03 (work in progress), February
			2015.
	[I-D.hallambaker-dnse]		[I-D.hallambaker-dnse]
	Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases		Hallam-Baker, P., "DNS Privacy and Censorship: Use Cases
	and Requirements.", draft-hallambaker-dnse-02 (work in		and Requirements.", draft-hallambaker-dnse-02 (work in
	progress), November 2014.		progress), November 2014.
	[I-D.wouters-dane-openpgp]		[I-D.wouters-dane-openpgp]
	Wouters, P., "Using DANE to Associate OpenPGP public keys		Wouters, P., "Using DANE to Associate OpenPGP public keys
	with email addresses", draft-wouters-dane-openpgp-02 (work		with email addresses", draft-wouters-dane-openpgp-02 (work
	in progress), February 2014.		in progress), February 2014.
	[I-D.hzhwm-start-tls-for-dns]		[I-D.hzhwm-start-tls-for-dns]
	Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D.		Zi, Z., Zhu, L., Heidemann, J., Mankin, A., and D.
	Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls-		Wessels, "Starting TLS over DNS", draft-hzhwm-start-tls-
	for-dns-01 (work in progress), July 2014.		for-dns-01 (work in progress), July 2014.
	[I-D.ietf-dnsop-qname-minimisation]		[I-D.ietf-dnsop-qname-minimisation]
	Bortzmeyer, S., "DNS query name minimisation to improve		Bortzmeyer, S., "DNS query name minimisation to improve
	privacy", draft-ietf-dnsop-qname-minimisation-01 (work in		privacy", draft-ietf-dnsop-qname-minimisation-02 (work in
	progress), February 2015.		progress), March 2015.
	[I-D.hoffman-dns-terminology]		[I-D.hoffman-dns-terminology]
	Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", draft-hoffman-dns-terminology-01 (work in		Terminology", draft-hoffman-dns-terminology-02 (work in
	progress), January 2015.		progress), March 2015.
	[dprive] IETF, DPRIVE., "The DPRIVE working group", March 2014,		[dprive] IETF, DPRIVE., "The DPRIVE working group", March 2014,
	<http://www.ietf.org/mail-archive/web/dns-privacy/>.		<http://www.ietf.org/mail-archive/web/dns-privacy/>.
	[denis-edns-client-subnet]		[denis-edns-client-subnet]
	Denis, F., "Security and privacy issues of edns-client-		Denis, F., "Security and privacy issues of edns-client-
	subnet", August 2013, <https://00f.net/2013/08/07/edns-		subnet", August 2013, <https://00f.net/2013/08/07/edns-
	client-subnet/>.		client-subnet/>.
	[dagon-malware]		[dagon-malware]
	skipping to change at page 15, line 17		skipping to change at page 16, line 17
	"Privacy-Preserving DNS: Analysis of Broadcast, Range		"Privacy-Preserving DNS: Analysis of Broadcast, Range
	Queries and Mix-Based Protection Methods", 2011,		Queries and Mix-Based Protection Methods", 2011,
	<https://svs.informatik.uni-hamburg.de/publications/2011/2		<https://svs.informatik.uni-hamburg.de/publications/2011/2
	011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.		011-09-14_FFHP_PrivacyPreservingDNS_ESORICS2011.pdf>.
	[aeris-dns]		[aeris-dns]
	Vinot, N., "[In French] Vie privee : et le DNS alors ?",		Vinot, N., "[In French] Vie privee : et le DNS alors ?",
	2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-		2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-
	alors.html>.		alors.html>.
			[herrmann-reidentification]
			Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
			"Analyzing characteristic host access patterns for re-
			identification of web user sessions", 2012,
			<http://epub.uni-regensburg.de/21103/1/
			Paper_PUL_nordsec_published.pdf>.
	8.3. URIs		8.3. URIs
	[1] https://developers.google.com/speed/public-dns/privacy		[1] https://developers.google.com/speed/public-dns/privacy
	Author's Address		Author's Address
	Stephane Bortzmeyer		Stephane Bortzmeyer
	AFNIC		AFNIC
	1, rue Stephenson		1, rue Stephenson
	Montigny-le-Bretonneux 78180		Montigny-le-Bretonneux 78180
End of changes. 21 change blocks.
	63 lines changed or deleted		107 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/