draft-ietf-dprive-rfc7626-bis-02.txt   draft-ietf-dprive-rfc7626-bis-03.txt 
dprive S. Bortzmeyer dprive S. Bortzmeyer
Internet-Draft AFNIC Internet-Draft AFNIC
Obsoletes: 7626 (if approved) S. Dickinson Obsoletes: 7626 (if approved) S. Dickinson
Intended status: Informational Sinodun IT Intended status: Informational Sinodun IT
Expires: April 18, 2020 October 16, 2019 Expires: May 21, 2020 November 18, 2019
DNS Privacy Considerations DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-02 draft-ietf-dprive-rfc7626-bis-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. This document present situation and does not prescribe solutions. This document
obsoletes RFC 7626. obsoletes RFC 7626.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 April 18, 2020. This Internet-Draft will expire on May 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8 3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8
3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 9 3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 9
3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 10 3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 10
3.5.1. In the Recursive Resolvers . . . . . . . . . . . . . 11 3.5.1. In the Recursive Resolvers . . . . . . . . . . . . . 11
3.5.2. In the Authoritative Name Servers . . . . . . . . . . 15 3.5.2. In the Authoritative Name Servers . . . . . . . . . . 15
3.6. Re-identification and Other Inferences . . . . . . . . . 16 3.6. Re-identification and Other Inferences . . . . . . . . . 16
3.7. More Information . . . . . . . . . . . . . . . . . . . . 17 3.7. More Information . . . . . . . . . . . . . . . . . . . . 17
4. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 17 4. Actual "Attacks" . . . . . . . . . . . . . . . . . . . . . . 17
5. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Legalities . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 21
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 (DNS) is specified in [RFC1034], [RFC1035], The Domain Name System (DNS) is specified in [RFC1034], [RFC1035],
and many later RFCs, which have never been consolidated. It is one and many later RFCs, which have never been consolidated. It is one
of the most important infrastructure components of the Internet and of the most important infrastructure components of the Internet and
skipping to change at page 6, line 19 skipping to change at page 6, line 19
be. be.
3.2. Data in the DNS Request 3.2. Data in the DNS Request
The DNS request includes many fields, but two of them seem The DNS request includes many fields, but two of them seem
particularly relevant for the privacy issues: the QNAME and the particularly relevant for the privacy issues: the QNAME and the
source IP address. "source IP address" is used in a loose sense of source IP address. "source IP address" is used in a loose sense of
"source IP address + maybe source port number", because the port "source IP address + maybe source port number", because the port
number is also in the request and can be used to differentiate number is also in the request and can be used to differentiate
between several users sharing an IP address (behind a Carrier-Grade between several users sharing an IP address (behind a Carrier-Grade
NAT (CGN) or a NPTv6, for instance [RFC6269]). NAT (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 is therefore which may be a domain used by only a few persons and is therefore
very revealing about communication relationships). Some QNAMEs are very revealing about communication relationships). Some QNAMEs are
more sensitive than others. For instance, querying the A record of a more sensitive than others. For instance, querying the A record of a
well-known web statistics domain reveals very little (everybody well-known web statistics domain reveals very little (everybody
visits web sites that use this analytics service), but querying the A visits web sites that use this analytics service), but querying the A
record of www.verybad.example where verybad.example is the domain of record of www.verybad.example where verybad.example is the domain of
skipping to change at page 7, line 13 skipping to change at page 7, line 13
has a different meaning; it does not have the same status as the has a different meaning; it does not have the same status as the
source address in an HTTP connection. It is typically the IP address source address in an HTTP connection. It is typically the IP address
of the recursive resolver that, in a way, "hides" the real user. of the recursive resolver that, in a way, "hides" the real user.
However, hiding does not always work. Sometimes EDNS(0) Client However, hiding does not always work. Sometimes EDNS(0) Client
subnet [RFC7871] is used (see its privacy analysis in subnet [RFC7871] is used (see its privacy analysis in
[denis-edns-client-subnet]). Sometimes the end user has a personal [denis-edns-client-subnet]). Sometimes the end user has a personal
recursive resolver on her machine. In both cases, the IP address is recursive resolver on her machine. In both cases, the IP address is
as sensitive as it is for HTTP [sidn-entrada]. as sensitive as it is for HTTP [sidn-entrada].
A note about IP addresses: there is currently no IETF document that A note about IP addresses: there is currently no IETF document that
describes in detail all the privacy issues around IP addressing. In describes in detail all the privacy issues around IP addressing in
the meantime, the discussion here is intended to include both IPv4 general, although [RFC7721] does discuss privacy considerations for
and IPv6 source addresses. For a number of reasons, their assignment IPv6 address generation mechanisms. In the meantime, the discussion
and utilization characteristics are different, which may have here is intended to include both IPv4 and IPv6 source addresses. For
implications for details of information leakage associated with the a number of reasons, their assignment and utilization characteristics
collection of source addresses. (For example, a specific IPv6 source are different, which may have implications for details of information
address seen on the public Internet is less likely than an IPv4 leakage associated with the collection of source addresses. (For
address to originate behind an address sharing scheme.) However, for example, a specific IPv6 source address seen on the public Internet
both IPv4 and IPv6 addresses, it is important to note that source is less likely than an IPv4 address to originate behind an address
addresses are propagated with queries and comprise metadata about the sharing scheme.) However, for both IPv4 and IPv6 addresses, it is
host, user, or application that originated them. important to note that source addresses are propagated with queries
and comprise metadata about the host, user, or application that
originated them.
3.2.1. Data in the DNS payload 3.2.1. Data in the DNS payload
At the time of writing there are no standardized client identifiers At the time of writing there are no standardized client identifiers
contained in the DNS payload itself (ECS [RFC7871] while widely used contained in the DNS payload itself (ECS [RFC7871] while widely used
is only of Category Informational). is only of Category Informational).
DNS Cookies [RFC7873] are a lightweight DNS transaction security DNS Cookies [RFC7873] are a lightweight DNS transaction security
mechanism that provides limited protection against a variety of mechanism that provides limited protection against a variety of
increasingly common denial-of-service and amplification/forgery or increasingly common denial-of-service and amplification/forgery or
skipping to change at page 9, line 34 skipping to change at page 9, line 35
end user's connection and the public DNS service. end user's connection and the public DNS service.
It is also noted that typically a device connected _only_ to a modern It is also noted that typically a device connected _only_ to a modern
cellular network is cellular network is
o directly configured with only the recursive resolvers of the IAP o directly configured with only the recursive resolvers of the IAP
and and
o all traffic (including DNS) between the device and the cellular o all traffic (including DNS) between the device and the cellular
network is encrypted following an encryption profile edited by the network is encrypted following an encryption profile edited by the
IPv6 for Third Generation Partnership Project (3GPP [2]). Third Generation Partnership Project (3GPP [2]).
The attack surface for this specific scenario is not considered here. The attack surface for this specific scenario is not considered here.
3.4.2. Encrypted Transports 3.4.2. Encrypted Transports
The use of encrypted transports directly mitigates passive The use of encrypted transports directly mitigates passive
surveillance of the DNS payload, however there are still some privacy surveillance of the DNS payload, however there are still some privacy
attacks possible. This section enumerates the residual privacy risks attacks possible. This section enumerates the residual privacy risks
to an end user when an attacker can passively monitor encrypted DNS to an end user when an attacker can passively monitor encrypted DNS
traffic flows on the wire. traffic flows on the wire.
skipping to change at page 13, line 10 skipping to change at page 13, line 10
used in the absence of an active attack) and that the potential used in the absence of an active attack) and that the potential
attacker was purely passive. But, in reality, we can have active attacker was purely passive. But, in reality, we can have active
attackers in the network redirecting the traffic, not just to observe attackers in the network redirecting the traffic, not just to observe
it but also potentially change it. it but also potentially change it.
For instance, a DHCP server controlled by an attacker can direct you For instance, a DHCP server controlled by an attacker can direct you
to a recursive resolver also controlled by that attacker. Most of to a recursive resolver also controlled by that attacker. Most of
the time, it seems to be done to divert traffic in order to also the time, it seems to be done to divert traffic in order to also
direct the user to a web server controlled by the attacker. However direct the user to a web server controlled by the attacker. However
it could be used just to capture the traffic and gather information it could be used just to capture the traffic and gather information
about you. about you. Similarly, attacks on NDP/ARP might be used to re-direct
DNS queries to attacker controlled servers.
Other attacks, besides using DHCP, are possible. The cleartext Other attacks, besides using DHCP, are possible. The cleartext
traffic from a DNS client to a DNS server can be intercepted along traffic from a DNS client to a DNS server can be intercepted along
its way from originator to intended source, for instance, by its way from originator to intended source, for instance, by
transparent attacker controlled DNS proxies in the network that will transparent attacker controlled DNS proxies in the network that will
divert the traffic intended for a legitimate DNS server. This server divert the traffic intended for a legitimate DNS server. This server
can masquerade as the intended server and respond with data to the can masquerade as the intended server and respond with data to the
client. (Attacker controlled servers that inject malicious data are client. (Attacker controlled servers that inject malicious data are
possible, but it is a separate problem not relevant to privacy.) A possible, but it is a separate problem not relevant to privacy.) A
server controlled by an attacker may respond correctly for a long server controlled by an attacker may respond correctly for a long
skipping to change at page 13, line 34 skipping to change at page 13, line 35
resolver in the machine's configuration, or the routing itself can be resolver in the machine's configuration, or the routing itself can be
subverted (for instance, [ripe-atlas-turkey]). subverted (for instance, [ripe-atlas-turkey]).
3.5.1.3. Blocking of User Selected Services 3.5.1.3. Blocking of User Selected Services
User privacy can also be at risk if there is blocking (by local User privacy can also be at risk if there is blocking (by local
network operators or more general mechanisms) of access to remote network operators or more general mechanisms) of access to remote
recursive servers that offer encrypted transports when the local recursive servers that offer encrypted transports when the local
resolver does not offer encryption and/or has very poor privacy resolver does not offer encryption and/or has very poor privacy
policies. For example, active blocking of port 853 for DoT or of policies. For example, active blocking of port 853 for DoT or of
specific IP addresses (e.g., 1.1.1.1 or 2606:4700:4700::1111) could specific IP addresses could restrict the resolvers available to the
restrict the resolvers available to the user. The extent of the risk user. The extent of the risk to end user privacy is highly dependent
to end user privacy is highly dependent on the specific network and on the specific network and user context; a user on a network that is
user context; a user on a network that is known to perform known to perform surveillance would be compromised if they could not
surveillance would be compromised if they could not access such access such services, whereas a user on a trusted network might have
services, whereas a user on a trusted network might have no privacy no privacy motivation to do so.
motivation to do so.
In some cases, networks might block access to remote resolvers for In some cases, networks might block access to remote resolvers for
security reasons, for example to cripple malware and bots or to security reasons, for example to cripple malware and bots or to
prevent data exfiltration methods that use encrypted DNS prevent data exfiltration methods that use encrypted DNS
communications as transport. In these cases, if the network fully communications as transport. In these cases, if the network fully
respects user privacy in other ways (i.e. encrypted DNS and good respects user privacy in other ways (i.e. encrypted DNS and good
data handling policies) the block can serve to further protect user data handling policies) the block can serve to further protect user
privacy by ensuring such security precautions. privacy by ensuring such security precautions.
It is also noted that attacks on remote resolver services, e.g., DDoS It is also noted that attacks on remote resolver services, e.g., DDoS
skipping to change at page 16, line 40 skipping to change at page 16, line 40
domain manager and these servers may or may not take privacy into domain manager and these servers may or may not take privacy into
account. Whatever the contract, the third-party hoster may be honest account. Whatever the contract, the third-party hoster may be honest
or not but, in any case, it will have to follow its local laws. So, or not but, in any case, it will have to follow its local laws. So,
requests to a given ccTLD may go to servers managed by organizations requests to a given ccTLD may go to servers managed by organizations
outside of the ccTLD's country. End users may not anticipate that, outside of the ccTLD's country. End users may not anticipate that,
when doing a security analysis. when doing a security analysis.
Also, it seems (see the survey described in [aeris-dns]) that there Also, it seems (see the survey described in [aeris-dns]) that there
is a strong concentration of authoritative name servers among is a strong concentration of authoritative name servers among
"popular" domains (such as the Alexa Top N list). For instance, "popular" domains (such as the Alexa Top N list). For instance,
among the Alexa Top 100K, one DNS provider hosts today 10% of the among the Alexa Top 100K [11], one DNS provider hosts today 10% of
domains. The ten most important DNS providers host together one the domains. The ten most important DNS providers host together one
third of the domains. With the control (or the ability to sniff the third of the domains. With the control (or the ability to sniff the
traffic) of a few name servers, you can gather a lot of information. traffic) of a few name servers, you can gather a lot of information.
3.6. Re-identification and Other Inferences 3.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 this data. The but also to the results of various inferences about this data. The
term 'observer' here is used very generally, it might be one that is term 'observer' here is used very generally, it might be one that is
passively observing cleartext DNS traffic, one in the network that is passively observing cleartext DNS traffic, one in the network that is
actively attacking the user by re-directing DNS resolution, or it actively attacking the user by re-directing DNS resolution, or it
skipping to change at page 18, line 20 skipping to change at page 18, line 20
responses, and not the source IP address of the client, precisely for responses, and not the source IP address of the client, precisely for
privacy reasons. Other passive DNS systems may not be so careful. privacy reasons. Other passive DNS systems may not be so careful.
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, which were leaked The revelations from the Edward Snowden documents, which were leaked
from the National Security Agency (NSA) provide evidence of the use from the National Security Agency (NSA) provide evidence of the use
of the DNS in mass surveillance operations [morecowbell]. For of the DNS in mass surveillance operations [morecowbell]. For
example the MORECOWBELL surveillance program, which uses a dedicated example the MORECOWBELL surveillance program, which uses a dedicated
covert monitoring infrastructure to actively query DNS servers and covert monitoring infrastructure to actively query DNS servers and
perform HTTP requests to obtain meta information about services and perform HTTP requests to obtain meta information about services and
to check their availability. Also the QUANTUMTHEORY project which to check their availability. Also the QUANTUMTHEORY [12] project
includes detecting lookups for certain addresses and injecting bogus which includes detecting lookups for certain addresses and injecting
replies is another good example showing that the lack of privacy bogus replies is another good example showing that the lack of
protections in the DNS is actively exploited. privacy protections in the DNS is actively exploited.
5. Legalities 5. Legalities
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] or GDPR [11] applicable in the European [data-protection-directive] or GDPR [13] applicable in the European
Union in the context of DNS traffic data is not an easy task, and we Union in the context of DNS traffic data is not an easy task, and we
do not know a court precedent here. See an interesting analysis in do not know a court precedent here. See an interesting analysis in
[sidn-entrada]. [sidn-entrada].
6. Security Considerations 6. 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 requirements (with just lays out the problem; it does not try to set requirements (with
the choices and compromises they imply), much less define solutions. the choices and compromises they imply), much less define solutions.
Possible solutions to the issues described here are discussed in Possible solutions to the issues described here are discussed in
other documents (currently too many to all be mentioned); see, for other documents (currently too many to all be mentioned); see, for
instance, 'Recommendations for DNS Privacy Operators' instance, 'Recommendations for DNS Privacy Operators'
[I-D.ietf-dprive-bcp-op]. [I-D.ietf-dprive-bcp-op].
7. Acknowledgments 7. IANA Considerations
This document makes no requests of the IANA.
8. 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 that led to this document. Thanks to Ondrej Sury for the work that led 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 and to Paul Hoffman, Matthijs Mekking, Marcos Sanz, for proofreading and to Paul Hoffman, Matthijs Mekking, Marcos Sanz,
Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for Tim Wicinski, Francis Dupont, Allison Mankin, and Warren Kumari for
proofreading, providing technical remarks, and making many proofreading, providing technical remarks, and making many
readability improvements. Thanks to Dan York, Suzanne Woolf, Tony readability improvements. Thanks to Dan York, Suzanne Woolf, Tony
Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis Finch, Stephen Farrell, Peter Koch, Simon Josefsson, and Frank Denis
for good written contributions. Thanks to Vittorio Bertola and for good written contributions. Thanks to Vittorio Bertola and
Mohamed Boucadair for a detailed review of the -bis. And thanks to Mohamed Boucadair for a detailed review of the -bis. And thanks to
the IESG members for the last remarks. the IESG members for the last remarks.
8. Changelog 9. Changelog
draft-ietf-dprive-rfc7626-bis-03
o Address 2 minor nits (typo in section 3.4.1 and adding an IANA
section)
o Minor updates from AD review
draft-ietf-dprive-rfc7626-bis-02 draft-ietf-dprive-rfc7626-bis-02
o Numerous editorial corrections thanks to Mohamed Boucadair and o Numerous editorial corrections thanks to Mohamed Boucadair and
* Minor additions to Scope section * Minor additions to Scope section
* New text on cellular network DNS * New text on cellular network DNS
o Additional text from Vittorio Bertola on blocking and security o Additional text from Vittorio Bertola on blocking and security
skipping to change at page 20, line 4 skipping to change at page 20, line 21
o Clarify what risks are considered in section 3.4.2 o Clarify what risks are considered in section 3.4.2
draft-ietf-dprive-rfc7626-bis-00 draft-ietf-dprive-rfc7626-bis-00
o Rename after WG adoption o Rename after WG adoption
o Use DoT acronym throughout o Use DoT acronym throughout
o Minor updates to status of deployment and other drafts o Minor updates to status of deployment and other drafts
draft-bortzmeyer-dprive-rfc7626-bis-02
o Update various references and fix some nits. o Update various references and fix some nits.
draft-bortzmeyer-dprive-rfc7626-bis-01 draft-bortzmeyer-dprive-rfc7626-bis-01
o Update reference for dickinson-bcp-op to draft-dickinson-dprive- o Update reference for dickinson-bcp-op to draft-dickinson-dprive-
bcp-op bcp-op
draft-borztmeyer-dprive-rfc7626-bis-00: draft-borztmeyer-dprive-rfc7626-bis-00:
Initial commit. Differences to RFC7626: Initial commit. Differences to RFC7626:
skipping to change at page 20, line 25 skipping to change at page 20, line 45
o Update many references o Update many references
o Add discussions of encrypted transports including DoT and DoH o Add discussions of encrypted transports including DoT and DoH
o Add section on DNS payload o Add section on DNS payload
o Add section on authentication of servers o Add section on authentication of servers
o Add section on blocking of services o Add section on blocking of services
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
9.2. Informative References 10.2. Informative References
[aeris-dns] [aeris-dns]
Vinot, N., "Vie privee: et le DNS alors?", (In French), Vinot, N., "Vie privee: et le DNS alors?", (In French),
2015, <https://blog.imirhil.fr/vie-privee-et-le-dns- 2015, <https://blog.imirhil.fr/vie-privee-et-le-dns-
alors.html>. alors.html>.
[castillo-garcia] [castillo-garcia]
Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous Castillo-Perez, S. and J. Garcia-Alfaro, "Anonymous
Resolution of DNS Queries", 2008, Resolution of DNS Queries", 2008,
<http://deic.uab.es/~joaquin/papers/is08.pdf>. <http://deic.uab.es/~joaquin/papers/is08.pdf>.
skipping to change at page 23, line 27 skipping to change at page 23, line 41
regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>. regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.
[I-D.ietf-dnsop-resolver-information] [I-D.ietf-dnsop-resolver-information]
Sood, P., Arends, R., and P. Hoffman, "DNS Resolver Sood, P., Arends, R., and P. Hoffman, "DNS Resolver
Information Self-publication", draft-ietf-dnsop-resolver- Information Self-publication", draft-ietf-dnsop-resolver-
information-00 (work in progress), August 2019. information-00 (work in progress), August 2019.
[I-D.ietf-dprive-bcp-op] [I-D.ietf-dprive-bcp-op]
Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A.
Mankin, "Recommendations for DNS Privacy Service Mankin, "Recommendations for DNS Privacy Service
Operators", draft-ietf-dprive-bcp-op-04 (work in Operators", draft-ietf-dprive-bcp-op-05 (work in
progress), October 2019. progress), October 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-23 (work and Secure Transport", draft-ietf-quic-transport-23 (work
in progress), September 2019. in progress), September 2019.
[I-D.ietf-tls-sni-encryption] [I-D.ietf-tls-sni-encryption]
Huitema, C. and E. Rescorla, "Issues and Requirements for Huitema, C. and E. Rescorla, "Issues and Requirements for
SNI Encryption in TLS", draft-ietf-tls-sni-encryption-08 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-09
(work in progress), October 2019. (work in progress), October 2019.
[I-D.livingood-doh-implementation-risks-issues] [I-D.livingood-doh-implementation-risks-issues]
Livingood, J., Antonakakis, M., Sleigh, B., and A. Livingood, J., Antonakakis, M., Sleigh, B., and A.
Winfield, "Centralized DNS over HTTPS (DoH) Implementation Winfield, "Centralized DNS over HTTPS (DoH) Implementation
Issues and Risks", draft-livingood-doh-implementation- Issues and Risks", draft-livingood-doh-implementation-
risks-issues-04 (work in progress), September 2019. risks-issues-04 (work in progress), September 2019.
[morecowbell] [morecowbell]
Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
skipping to change at page 25, line 12 skipping to change at page 25, line 22
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] 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", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, <https://www.rfc- DOI 10.17487/RFC7624, August 2015, <https://www.rfc-
editor.org/info/rfc7624>. editor.org/info/rfc7624>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>. <https://www.rfc-editor.org/info/rfc7816>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
skipping to change at page 26, line 42 skipping to change at page 27, line 10
[tor-leak] [tor-leak]
Tor, "DNS leaks in Tor", 2013, Tor, "DNS leaks in Tor", 2013,
<https://www.torproject.org/docs/ <https://www.torproject.org/docs/
faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>. faq.html.en#WarningsAboutSOCKSandDNSInformationLeaks>.
[yanbin-tsudik] [yanbin-tsudik]
Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks Yanbin, L. and G. Tsudik, "Towards Plugging Privacy Leaks
in the Domain Name System", October 2009, in the Domain Name System", October 2009,
<http://arxiv.org/abs/0910.2472>. <http://arxiv.org/abs/0910.2472>.
9.3. URIs 10.3. URIs
[1] https://lists.dns-oarc.net/pipermail/dns- [1] https://lists.dns-oarc.net/pipermail/dns-
operations/2016-January/014141.html operations/2016-January/014141.html
[2] https://www.3gpp.org [2] https://www.3gpp.org
[3] http://netres.ec/?b=11B99BD [3] http://netres.ec/?b=11B99BD
[4] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS- [4] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS-
based_De-NAT_Scheme based_De-NAT_Scheme
skipping to change at page 27, line 17 skipping to change at page 27, line 34
[6] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/ [6] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/
[7] https://www.quad9.net [7] https://www.quad9.net
[8] https://developers.google.com/speed/public-dns/privacy [8] https://developers.google.com/speed/public-dns/privacy
[9] https://mailarchive.ietf.org/arch/browse/static/add [9] https://mailarchive.ietf.org/arch/browse/static/add
[10] https://www.encrypted-dns.org [10] https://www.encrypted-dns.org
[11] https://www.eugdpr.org/the-regulation.html [11] https://www.alexa.com/topsites
[12] https://theintercept.com/document/2014/03/12/nsa-gchqs-
quantumtheory-hacking-tactics/
[13] https://www.eugdpr.org/the-regulation.html
Authors' Addresses Authors' Addresses
Stephane Bortzmeyer Stephane Bortzmeyer
AFNIC AFNIC
1, rue Stephenson 1, rue Stephenson
Montigny-le-Bretonneux Montigny-le-Bretonneux
France 78180 France 78180
Email: bortzmeyer+ietf@nic.fr Email: bortzmeyer+ietf@nic.fr
 End of changes. 23 change blocks. 
46 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/