draft-ietf-dprive-problem-statement-03.txt		draft-ietf-dprive-problem-statement-04.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 March 9, 2015		Intended status: Informational March 23, 2015
	Expires: September 10, 2015		Expires: September 24, 2015
	DNS privacy considerations		DNS privacy considerations
	draft-ietf-dprive-problem-statement-03		draft-ietf-dprive-problem-statement-04
	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.
	(REMOVE BEFORE PUBLICATION: Discussions of the document should take
	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 September 10, 2015.		This Internet-Draft will expire on September 24, 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 . . . . . . . . . . 5		2.1. The alleged public nature of DNS data . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. On the wire . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . 9		2.5.2. In the authoritative name servers . . . . . . . . . . 8
	2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 10		2.5.3. Rogue servers . . . . . . . . . . . . . . . . . . . . 9
	2.6. Re-identification and other inferences . . . . . . . . . 10		2.6. Re-identification and other inferences . . . . . . . . . 10
	3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 10		3. Actual "attacks" . . . . . . . . . . . . . . . . . . . . . . 10
	4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security considerations . . . . . . . . . . . . . . . . . . . 11		5. Security considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		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
	has many privacy implications and this is an attempt at a		has many privacy implications and this is an attempt at a
	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. (See
	(REMOVE BEFORE PUBLICATION: We hope that the document		also [I-D.hoffman-dns-terminology].) A client, the stub resolver,
	[I-D.hoffman-dns-terminology] will be published as a RFC so most of		issues a DNS query to a server, called the recursive resolver (also
	this section could be replaced by a reference to it.) A client, the		called caching resolver or full resolver or recursive name server).
	stub resolver, issues a DNS query to a server, called the recursive		Let's use the query "What are the AAAA records for www.example.com?"
	resolver (also called caching resolver or full resolver or recursive		as an example. AAAA is the qtype (Query Type), and www.example.com
	name server). Let's use the query "What are the AAAA records for		is the qname (Query Name). (The description which follows assume a
	www.example.com?" as an example. AAAA is the qtype (Query Type), and		cold cache, for instance because the server just started.) The
	www.example.com is the qname (Query Name). (The description which		recursive resolver will first query the root nameservers. In most
	follows assume a cold cache, for instance because the server just		cases, the root nameservers will send a referral. In this example,
	started.) The recursive resolver will first query the root		the referral will be to the .com nameservers. The resolver repeats
	nameservers. In most cases, the root nameservers will send a		the query to one of the .com nameservers. The .com nameservers, in
	referral. In this example, the referral will be to the .com		turn, will refer to the example.com nameservers. The example.com
	nameservers. The resolver repeats the query to one of the .com		nameserver will then return the answer. The root name servers, the
	nameservers. The .com nameservers, in turn, will refer to the		name servers of .com and the name servers of example.com are called
	example.com nameservers. The example.com nameserver will then return		authoritative name servers. It is important, when analyzing the
	the answer. The root name servers, the name servers of .com and the		privacy issues, to remember that the question asked to all these name
	name servers of example.com are called authoritative name servers.		servers is always the original question, not a derived question. The
	It is important, when analyzing the privacy issues, to remember that		question sent to the root name servers is "What are the AAAA records
	the question asked to all these name servers is always the original		for 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, the algorithm described just		Because DNS relies on caching heavily, the algorithm described just
	above is actually a bit more complicated, and not all questions are		above is actually a bit more complicated, and not all questions are
	sent to the authoritative name servers. If a few seconds later the		sent to the authoritative name servers. If a few seconds later the
	stub resolver asks to the recursive resolver, "What are the SRV		stub resolver asks to the recursive resolver, "What are the SRV
	records of _xmpp-server._tcp.example.com?", the recursive resolver		records of _xmpp-server._tcp.example.com?", the recursive resolver
	will remember that it knows the name servers of example.com and will		will remember that it knows the name servers of example.com and will
	just query them, bypassing the root and .com. Because there is		just query them, bypassing the root and .com. Because there is
	typically no caching in the stub resolver, the recursive resolver,		typically no caching in the stub resolver, the recursive resolver,
	unlike the authoritative servers, sees all the DNS traffic.		unlike the authoritative servers, sees all the DNS traffic.
	(Applications, like Web browsers, may have some form of caching,		(Applications, like Web browsers, may have some form of caching which
	which do not follow DNS rules. So, the recursive resolver does not		do not follow DNS rules, for instance because it may ignore the TTL.
	see all the name resolution activity.)		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 (unencrypted), except
	a few cases when the IP traffic is protected, for instance in an		a few cases when the IP traffic is protected, for instance in an
	IPsec VPN.		IPsec VPN.
	Today, almost all DNS queries are sent over UDP. This has practical		Today, almost all DNS queries are sent over UDP. This has practical
	consequences when considering encryption of the traffic as a possible		consequences when considering encryption of the traffic as a possible
	privacy technique. Some encryption solutions are only designed for		privacy technique. Some encryption solutions are only designed for
	TCP, not UDP.		TCP, not UDP.
	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 mix of many sort of DNS requests received by a		issues of DNS is the mix of many sort of DNS requests received by a
	skipping to change at page 10, line 16		skipping to change at page 10, line 6
	(or the ability to sniff the traffic) of a few name servers, you can		(or the ability to sniff the traffic) of a few name servers, you can
	gather a lot of information.		gather a lot of information.
	2.5.3. Rogue servers		2.5.3. Rogue servers
	A rogue DHCP server, or a trusted DHCP server that has had its		A rogue DHCP server, or a trusted DHCP server that has had its
	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		2.6. Re-identification and other inferences
	An observer has access not only to the data he/she directly collects		An observer has access not only to the data he/she directly collects
	but also to the results of various inferences about these data.		but also to the results of various inferences about these data.
	skipping to change at page 11, line 39		skipping to change at page 11, line 29
	To our knowledge, there are no specific privacy laws for DNS data, in		To our knowledge, there are no specific privacy laws for DNS data, in
	any country. Interpreting general privacy laws like		any country. Interpreting general privacy laws like
	[data-protection-directive] (European Union) in the context of DNS		[data-protection-directive] (European Union) in the context of DNS
	traffic data is not an easy task and it seems there is no court		traffic data is not an easy task and it seems there is no court
	precedent here.		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 requirements (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, Matthijs Mekking, Marcos Sanz, Tim		for proofreading, to Paul Hoffman, Matthijs Mekking, Marcos Sanz, Tim
	Wicinski, Allison Mankin and Warren Kumari for proofreading,		Wicinski, Francis Dupont, Allison Mankin and Warren Kumari for
	technical remarks, and many readability improvements. Thanks to Dan		proofreading, technical remarks, and many readability improvements.
	York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter Koch and		Thanks to Dan York, Suzanne Woolf, Tony Finch, Stephen Farrell, Peter
	Frank Denis for good written contributions.		Koch and 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 13, line 19		skipping to change at page 13, line 10
	[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]		[I-D.iab-privsec-confidentiality-threat]
	Barnes, R., Schneier, B., Jennings, C., Hardie, T.,		Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
	Trammell, B., Huitema, C., and D. Borkmann,		Trammell, B., Huitema, C., and D. Borkmann,
	"Confidentiality in the Face of Pervasive Surveillance: A		"Confidentiality in the Face of Pervasive Surveillance: A
	Threat Model and Problem Statement", draft-iab-privsec-		Threat Model and Problem Statement", draft-iab-privsec-
	confidentiality-threat-03 (work in progress), February		confidentiality-threat-04 (work in progress), March 2015.
	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.
End of changes. 15 change blocks.
	50 lines changed or deleted		44 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/