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/