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/