draft-ietf-dprive-rfc7626-bis-03.txt   draft-ietf-dprive-rfc7626-bis-04.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: May 21, 2020 November 18, 2019 Expires: July 19, 2020 January 16, 2020
DNS Privacy Considerations DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-03 draft-ietf-dprive-rfc7626-bis-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. 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 May 21, 2020. This Internet-Draft will expire on July 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Alleged Public Nature of DNS Data . . . . . . . . . . 5 3.1. The Alleged Public Nature of DNS Data . . . . . . . . . . 5
3.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6 3.2. Data in the DNS Request . . . . . . . . . . . . . . . . . 6
3.2.1. Data in the DNS payload . . . . . . . . . . . . . . . 7 3.2.1. Data in the DNS payload . . . . . . . . . . . . . . . 7
3.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 7 3.3. Cache Snooping . . . . . . . . . . . . . . . . . . . . . 8
3.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. On the Wire . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8 3.4.1. Unencrypted Transports . . . . . . . . . . . . . . . 8
3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 9 3.4.2. Encrypted Transports . . . . . . . . . . . . . . . . 10
3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 10 3.5. In the Servers . . . . . . . . . . . . . . . . . . . . . 11
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 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],
skipping to change at page 4, line 11 skipping to change at page 4, line 11
of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
particularly in mobile devices, browsers, and by providers of anycast particularly in mobile devices, browsers, and by providers of anycast
recursive DNS resolution services. There are a few cases where there recursive DNS resolution services. There are a few cases where there
is some alternative channel encryption, for instance, in an IPsec VPN is some alternative channel encryption, for instance, in an IPsec VPN
tunnel, at least between the stub resolver and the resolver. tunnel, at least between the stub resolver and the resolver.
Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
This has practical consequences when considering encryption of the This has practical consequences when considering encryption of the
traffic as a possible privacy technique. Some encryption solutions traffic as a possible privacy technique. Some encryption solutions
are only designed for TCP, not UDP and new solutions are still are only designed for TCP, not UDP and new solutions are still
emerging [I-D.ietf-quic-transport]. emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic].
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 fact that DNS requests received by a server are issues of DNS is the fact that DNS requests received by a server are
triggered by different reasons. Let's assume an eavesdropper wants triggered by different reasons. Let's assume an eavesdropper wants
to know which web page is viewed by a user. For a typical web page, to know which web page is viewed by a user. For a typical web page,
there are three sorts of DNS requests being issued: there are three sorts of DNS requests being issued:
o Primary request: this is the domain name in the URL that the user o Primary request: this is the domain name in the URL that the user
typed, selected from a bookmark, or chose by clicking on an typed, selected from a bookmark, or chose by clicking on an
hyperlink. Presumably, this is what is of interest for the hyperlink. Presumably, this is what is of interest for the
skipping to change at page 5, line 13 skipping to change at page 5, line 13
[RFC6973]. [RFC6973].
2. Scope 2. Scope
This document focuses mostly on the study of privacy risks for the This document focuses mostly on the study of privacy risks for the
end user (the one performing DNS requests). We consider the risks of end user (the one performing DNS requests). We consider the risks of
pervasive surveillance [RFC7258] as well as risks coming from a more pervasive surveillance [RFC7258] as well as risks coming from a more
focused surveillance. focused surveillance.
This document does not attempt a comparison of specific privacy This document does not attempt a comparison of specific privacy
protections provided by individual networks or organisations, it protections provided by individual networks or organizations, it
makes only general observations about typical current practices. makes only general observations about typical current practices.
Privacy risks for the holder of a zone (the risk that someone gets Privacy risks for the holder of a zone (the risk that someone gets
the data) are discussed in [RFC5936] and [RFC5155]. the data) are discussed in [RFC5936] and [RFC5155].
Privacy risks for recursive operators (including access providers and Privacy risks for recursive operators (including access providers and
operators in enterprise networks) such as leakage of private operators in enterprise networks) such as leakage of private
namespaces or blocklists are out of scope for this document. namespaces or blocklists are out of scope for this document.
Non-privacy risks (e.g security related concerns such as cache Non-privacy risks (e.g security related considerations such as cache
poisoning) are also out of scope. poisoning) are also out of scope.
The privacy risks associated with the use of other protocols, e.g., The privacy risks associated with the use of other protocols that
unencrypted TLS SNI extensions or HTTPS destination IP address make use of DNS information are not considered here.
fingerprinting are not considered here.
3. Risks 3. Risks
This section outlines the privacy considerations associated with
different aspects of the DNS for the end user. When reading this
section it needs to be kept in mind that many of the considerations
(for example, recursive resolver and transport protocol) can be
specific to the network context that a device is using at a given
point in time. A user may have many devices and each device might
utilize many different networks (e.g. home, work, public or cellular)
over a period of time or even concurrently. An exhaustive analysis
of the privacy considerations for an individual user would need to
take into account the set of devices used and the multiple dynamic
contexts of each device. This document does not attempt such a
complex analysis, instead it presents an overview of the various
considerations that could form the basis of such an analysis.
3.1. The Alleged Public Nature of DNS Data 3.1. The Alleged Public Nature of DNS Data
It has long been claimed that "the data in the DNS is public". While It has long been claimed that "the data in the DNS is public". While
this sentence makes sense for an Internet-wide lookup system, there this sentence makes sense for an Internet-wide lookup system, there
are multiple facets to the data and metadata involved that deserve a are multiple facets to the data and metadata involved that deserve a
more detailed look. First, access control lists (ACLs) and private more detailed look. First, access control lists (ACLs) and private
namespaces notwithstanding, the DNS operates under the assumption namespaces notwithstanding, the DNS operates under the assumption
that public-facing authoritative name servers will respond to "usual" that public-facing authoritative name servers will respond to "usual"
DNS queries for any zone they are authoritative for without further DNS queries for any zone they are authoritative for without further
authentication or authorization of the client (resolver). Due to the authentication or authorization of the client (resolver). Due to the
skipping to change at page 9, line 33 skipping to change at page 9, line 47
resolvers rather than operating their own resolvers. In this resolvers rather than operating their own resolvers. In this
case, the attack surface is the entire public Internet between the case, the attack surface is the entire public Internet between the
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 afforded some level of protection against some types of
network is encrypted following an encryption profile edited by the eavesdropping for all traffic (including DNS traffic) due to the
Third Generation Partnership Project (3GPP [2]). cellular network link-layer encryption.
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.
These are cases where user identification, fingerprinting or These are cases where user identification, fingerprinting or
correlations may be possible due to the use of certain transport correlations may be possible due to the use of certain transport
layers or clear text/observable features. These issues are not layers or clear text/observable features. These issues are not
specific to DNS, but DNS traffic is susceptible to these attacks when specific to DNS, but DNS traffic is susceptible to these attacks when
using specific transports. using specific transports.
There are some general examples, for example, certain studies have There are some general examples, for example, certain studies have
highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os- highlighted that IPv4 TTL, IPv6 Hop Limit, or TCP Window sizes os-
fingerprint [3] values can be used to fingerprint client OS's or that fingerprint [2] values can be used to fingerprint client OS's or that
various techniques can be used to de-NAT DNS queries dns-de-nat [4]. various techniques can be used to de-NAT DNS queries dns-de-nat [3].
The use of clear text transport options to optimize latency may also Note that even when using encrypted transports the use of clear text
identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413]. transport options to decrease latency can provide correlation of a
users' connections e.g. using TCP Fast Open [RFC7413] with TLS 1.2.
More specifically, (since the deployment of encrypted transports is More specifically, (since the deployment of encrypted transports is
not widespread at the time of writing) users wishing to use encrypted not widespread at the time of writing) users wishing to use encrypted
transports for DNS may in practice be limited in the resolver transports for DNS may in practice be limited in the resolver
services available. Given this, the choice of a user to configure a services available. Given this, the choice of a user to configure a
single resolver (or a fixed set of resolvers) and an encrypted single resolver (or a fixed set of resolvers) and an encrypted
transport to use in all network environments can actually serve to transport to use in all network environments can actually serve to
identify the user as one that desires privacy and can provide an identify the user as one that desires privacy and can provide an
added mechanism to track them as they move across network added mechanism to track them as they move across network
environments. environments.
Users of encrypted transports are also highly likely to re-use Implementations that support encrypted transports also commonly re-
sessions for multiple DNS queries to optimize performance (e.g., via use sessions for multiple DNS queries to optimize performance (e.g.
DNS pipelining or HTTPS multiplexing). Certain configuration options via DNS pipelining or HTTPS multiplexing). Default configuration
for encrypted transports could also in principle fingerprint a user options for encrypted transports could in principle fingerprint a
or client application. For example: specific client application. For example:
o TLS version or cipher suite selection o TLS version or cipher suite selection
o session resumption o session resumption
o the maximum number of messages to send or o the maximum number of messages to send or
o a maximum connection time before closing a connections and re- o a maximum connection time before closing a connections and re-
opening. opening.
If libraries or applications offer user configuration of such options
(e.g. [getdns]) then they could in principle help to identify a
specific user. Users may want to use only the defaults to avoid this
issue.
Whilst there are known attacks on older versions of TLS the most Whilst there are known attacks on older versions of TLS the most
recent recommendations [RFC7525] and developments [RFC8446] in this recent recommendations [RFC7525] and the development of TLS 1.3
area largely mitigate those. [RFC8446] largely mitigate those.
Traffic analysis of unpadded encrypted traffic is also possible Traffic analysis of unpadded encrypted traffic is also possible
[pitfalls-of-dns-encrption] because the sizes and timing of encrypted [pitfalls-of-dns-encryption] because the sizes and timing of
DNS requests and responses can be correlated to unencrypted DNS encrypted DNS requests and responses can be correlated to unencrypted
requests upstream of a recursive resolver. DNS requests upstream of a recursive resolver.
3.5. In the Servers 3.5. In the Servers
Using the terminology of [RFC6973], the DNS servers (recursive Using the terminology of [RFC6973], the DNS servers (recursive
resolvers and authoritative servers) are enablers: they facilitate resolvers and authoritative servers) are enablers: they facilitate
communication between an initiator and a recipient without being communication between an initiator and a recipient without being
directly in the communications path. As a result, they are often directly in the communications path. As a result, they are often
forgotten in risk analysis. But, to quote again [RFC6973], "Although forgotten in risk analysis. But, to quote again [RFC6973], "Although
[...] enablers may not generally be considered as attackers, they may [...] enablers may not generally be considered as attackers, they may
all pose privacy threats (depending on the context) because they are all pose privacy threats (depending on the context) because they are
skipping to change at page 11, line 44 skipping to change at page 12, line 17
3.5.1.1. Resolver Selection 3.5.1.1. Resolver Selection
Given all the above considerations, the choice of recursive resolver Given all the above considerations, the choice of recursive resolver
has direct privacy considerations for end users. Historically, end has direct privacy considerations for end users. Historically, end
user devices have used the DHCP-provided local network recursive user devices have used the DHCP-provided local network recursive
resolver, which may have strong, medium, or weak privacy policies resolver, which may have strong, medium, or weak privacy policies
depending on the network. Privacy policies for these servers may or depending on the network. Privacy policies for these servers may or
may not be available and users need to be aware that privacy may not be available and users need to be aware that privacy
guarantees will vary with network. guarantees will vary with network.
More recently some networks and end users have actively chosen to use More recently, some networks and end users have actively chosen to
a large public resolver instead, e.g., Google Public DNS [5], use a large public resolver, e.g., Google Public DNS [4], Cloudflare
Cloudflare [6], or Quad9 [7]. There can be many reasons: cost [5], or Quad9 [6]. There can be many reasons: cost considerations
considerations for network operators, better reliability or anti- for network operators, better reliability or anti-censorship
censorship considerations are just a few. Such services typically do considerations are just a few. Such services typically do provide a
provide a privacy policy and the end user can get an idea of the data privacy policy and the end user can get an idea of the data collected
collected by such operators by reading one e.g., Google Public DNS - by such operators by reading one e.g., Google Public DNS - Your
Your Privacy [8]. Privacy [7].
Even more recently some applications have announced plans to deploy In general, as with many other protocols, issues around
application-specific DNS settings which might be enabled by default. centralization also arise with DNS. The picture is fluid with
For example, current proposals by Firefox [firefox] revolve around a several competing factors contributing which can also vary by
default based on the geographic region, using a pre-configured list geographic region. These include:
of large public resolver services which offer DoH, combined with non-
standard probing and signalling mechanism to disable DoH in
particular networks. Whereas Chrome [chrome] is experimenting with
using DoH to the DHCP-provided resolver if it is on a list of DoH-
compatible providers. At the time of writing, efforts to provide
standardized signalling mechanisms for applications to discover the
services offered by local resolvers are in progress
[I-D.ietf-dnsop-resolver-information].
If applications enable application-specific DNS settings without o ISP outsourcing, including to third party and public resolvers
properly informing the user of the change (or do not provide an
option for user configuration of the application's recursive
resolver) there is a potential privacy issue; depending on the
network context and the application default, the application might
use a recursive server that provides less privacy protection than the
default network-provided server without the user's full knowledge.
Users that are fully aware of an application specific DNS setting may
want to actively override any default in favour of their chosen
recursive resolver.
There are also concerns that, should the trend towards using large o regional market domination by one or only a few ISPs
public resolvers increase, this will itself provide a privacy
concern, due to a small number of operators having visibility of the
majority of DNS requests globally and the potential for aggregating
data across services about a user. Additionally the operating
organisation of the resolver may be in a different legal jurisdiction
than the user, which creates further privacy concerns around legal
protections of and access to the data collected by the operator.
At the time of writing the deployment models for DNS are evolving, An increased proportion of the global DNS resolution traffic being
their implications are complex and extend beyond the scope of this served by only a few entities means that the privacy considerations
document. They are the subject of much other work including for end users are highly dependent on the privacy policies and
[I-D.livingood-doh-implementation-risks-issues], the IETF ADD mailing practices of those entities. Many of the issues around
list [9] and the Encrypted DNS Deployment Initiative [10]. centralization are discussed in
[centralisation-and-data-sovereignty].
3.5.1.1.1. Dynamic Discovery of DoH and Strict DoT
Whilst support for opportunistic DoT can be determined by probing a
resolver on port 853, there is currently no standardized discovery
mechanism for DoH and Strict DoT servers.
This means that clients which might want to dynamically discover such
encrypted services, and where users are willing to trust such
services, are not able to do so. At the time of writing, efforts to
provide standardized signaling mechanisms to discover the services
offered by local resolvers are in progress
[I-D.ietf-dnsop-resolver-information]. Note that an increasing
numbers of ISPs are deploying encrypted DNS and publishing DNS
privacy polices, for example see the Encrypted DNS Deployment
Initiative [EDDI].
3.5.1.1.2. Application-specific Resolver Selection
An increasing number of applications are offering application-
specific encrypted DNS resolution settings, rather than defaulting to
using only the system resolver. A variety of heuristics and
resolvers are available in different applications including hard-
coded lists of recognized DoH/DoT servers.
Users will only be aware of and have the ability to control such
settings if applications provide the following functions:
o communicate clearly the change in default to users
o provide configuration options to change the default
o provide configuration options to always use the system resolver
Application-specific changes to default destinations for users' DNS
queries might increase or decrease user privacy - it is highly
dependent on the network context and the application-specific
default. This is an area of active debate and the IETF is working on
a number of issues related to application-specific DNS settings.
3.5.1.2. Active Attacks on Resolver Configuration 3.5.1.2. Active Attacks on Resolver Configuration
The previous section discussed DNS privacy, assuming that all the The previous section discussed DNS privacy, assuming that all the
traffic was directed to the intended servers (i.e those that would be traffic was directed to the intended servers (i.e those that would be
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.
it but also potentially change it.
For instance, a DHCP server controlled by an attacker can direct you
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
direct the user to a web server controlled by the attacker. However
it could be used just to capture the traffic and gather information
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
traffic from a DNS client to a DNS server can be intercepted along
its way from originator to intended source, for instance, by
transparent attacker controlled DNS proxies in the network that will
divert the traffic intended for a legitimate DNS server. This server
can masquerade as the intended server and respond with data to the
client. (Attacker controlled servers that inject malicious data are
possible, but it is a separate problem not relevant to privacy.) A
server controlled by an attacker may respond correctly for a long
period of time, thereby foregoing detection.
Also, malware like DNSchanger [dnschanger] can change the recursive The Internet Threat model, as described in [RFC3552], assumes that
resolver in the machine's configuration, or the routing itself can be the attacker controls the network. Such an attacker can completely
subverted (for instance, [ripe-atlas-turkey]). control any insecure DNS resolution, both passively monitoring the
queries and responses and substituting their own responses. Even if
encrypted DNS such as DoH or DoT is used, unless the client has been
configured in a secure way with the server identity, an active
attacker can impersonate the server. This implies that opportunistic
modes of DoH/DoT as well as modes where the client learns of the DoH/
DoT server via in-network mechanisms such as DHCP are vulnerable to
attack. In addition, if the client is compromised, the attacker can
replace the DNS configuration with one of its own choosing.
3.5.1.3. Blocking of User Selected Services 3.5.1.3. Blocking of User Selected DNS Resolution 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 could restrict the resolvers available to the specific IP addresses could restrict the resolvers available to the
user. The extent of the risk to end user privacy is highly dependent user. The extent of the risk to end user privacy is highly dependent
on the specific network and user context; a user on a network that is on the specific network and user context; a user on a network that is
known to perform surveillance would be compromised if they could not known to perform surveillance would be compromised if they could not
access such services, whereas a user on a trusted network might have access such services, whereas a user on a trusted network might have
no privacy motivation to do so. no privacy motivation to do so.
In some cases, networks might block access to remote resolvers for As a matter of policy, some recursive resolvers use their position in
security reasons, for example to cripple malware and bots or to the query path to selectively block access to certain DNS records.
prevent data exfiltration methods that use encrypted DNS This is a form of Rendezvous-Based Blocking as described in
communications as transport. In these cases, if the network fully Section 4.3 of [RFC7754]. Such blocklists often include servers know
respects user privacy in other ways (i.e. encrypted DNS and good to be used for malware, bots or other security risks. In order to
data handling policies) the block can serve to further protect user prevent circumvention of their blocking policies, some networks also
privacy by ensuring such security precautions. block access to resolvers with incompatible policies.
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
could force users to switch to other services that do not offer could force users to switch to other services that do not offer
encrypted transports for DNS. encrypted transports for DNS.
3.5.1.4. Authentication of Servers 3.5.1.4. Encrypted Transports and Recursive Resolvers
Both DoH and Strict mode for DoT [RFC8310] require authentication of
the server and therefore as long as the authentication credentials
are obtained over a secure channel then using either of these
transports defeats the attack of re-directing traffic to rogue
servers. Of course attacks on these secure channels are also
possible, but out of the scope of this document.
3.5.1.5. Encrypted Transports
3.5.1.5.1. DoT and DoH 3.5.1.4.1. DoT and DoH
Use of encrypted transports does not reduce the data available in the Use of encrypted transports does not reduce the data available in the
recursive resolver and ironically can actually expose more recursive resolver and ironically can actually expose more
information about users to operators. As mentioned in Section 3.4 information about users to operators. As described in Section 3.4.2
use of session based encrypted transports (TCP/TLS) can expose use of session based encrypted transports (TCP/TLS) can expose
correlation data about users. Such concerns in the TCP/TLS layers correlation data about users.
apply equally to DoT and DoH which both use TLS as the underlying
transport, some examples are:
o fingerprinting based on TLS version and/or cipher suite selection
o user tracking via session resumption in TLS 1.2
3.5.1.5.2. DoH Specific Considerations
Section 8 of [RFC8484] highlights some of the privacy consideration 3.5.1.4.2. DoH Specific Considerations
differences between HTTP and DNS. As a deliberate design choice DoH
inherits the privacy properties of the HTTPS stack and as a
consequence introduces new privacy concerns when compared with DNS
over UDP, TCP or TLS [RFC7858]. The rationale for this decision is
that retaining the ability to leverage the full functionality of the
HTTP ecosystem is more important than placing specific constraints on
this new protocol based on privacy considerations (modulo limiting
the use of HTTP cookies).
In analyzing the new issues introduced by DoH it is helpful to DoH inherits the full privacy properties of the HTTPS stack and as a
recognize that there exists a natural tension between consequence introduces new privacy considerations when compared with
DNS over UDP, TCP or TLS [RFC7858]. Section 8.2 of [RFC8484]
describes the privacy consideration in the server of the DoH
protocol.
o the wide practice in HTTP to use various headers to optimize HTTP A brief summary of some of the issues includes:
connections, functionality and behaviour (which can facilitate
user identification and tracking)
o and the fact that the DNS payload is currently very tightly o HTTPS presents new considerations for correlation, such as
encoded and contains no standardized user identifiers. explicit HTTP cookies and implicit fingerprinting of the unique
set and ordering of HTTP request header fields.
DoT, for example, would normally contain no client identifiers above o The User-Agent and Accept-Language request header fields often
the TLS layer and a resolver would see only a stream of DNS query convey specific information about the client version or locale.
payloads originating within one or more connections from a client IP
address. Whereas if DoH clients commonly include several headers in
a DNS message (e.g., user-agent and accept-language) this could lead
to the DoH server being able to identify the source of individual DNS
requests not only to a specific end user device but to a specific
application.
Additionally, depending on the client architecture, isolation of DoH o Utilizing the full set of HTTP features enables DoH to be more
queries from other HTTP traffic may or may not be feasible or than an HTTP tunnel, but it is at the cost of opening up
desirable. Depending on the use case, isolation of DoH queries from implementations to the full set of privacy considerations of HTTP.
other HTTP traffic may or may not increase privacy.
The picture for privacy considerations and user expectations for DoH o Implementations are advised to expose the minimal set of data
with respect to what additional data may be available to the DoH needed to achieve the desired feature set.
server compared to DNS over UDP, TCP or TLS is complex and requires a
detailed analysis for each use case. In particular the choice of
HTTPS functionality vs privacy is specifically made an implementation
choice in DoH and users may well have differing privacy expectations
depending on the DoH use case and implementation.
At the extremes, there may be implementations that attempt to achieve [RFC8484] specifically makes selection of HTTPS functionality vs
parity with DoT from a privacy perspective at the cost of using no privacy an implementation choice. At the extremes, there may be
identifiable headers, there might be others that provide feature rich implementations that attempt to achieve parity with DoT from a
data flows where the low-level origin of the DNS query is easily privacy perspective at the cost of using no identifiable HTTP
identifiable. headers, there might be others that provide feature rich data flows
where the low-level origin of the DNS query is easily identifiable.
Some implementations have, in fact, chosen restrict the use of the
'User-Agent' header so that resolver operators cannot identify the
specific application that is originating the DNS queries.
Privacy focused users should be aware of the potential for additional Privacy focused users should be aware of the potential for additional
client identifiers in DoH compared to DoT and may want to only use client identifiers in DoH compared to DoT and may want to only use
DoH client implementations that provide clear guidance on what DoH client implementations that provide clear guidance on what
identifiers they add. identifiers they add.
3.5.2. In the Authoritative Name Servers 3.5.2. In the Authoritative Name Servers
Unlike what happens for recursive resolvers, observation capabilities Unlike what happens for recursive resolvers, observation capabilities
of authoritative name servers are limited by caching; they see only of authoritative name servers are limited by caching; they see only
skipping to change at page 16, line 40 skipping to change at page 16, line 37
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 [11], one DNS provider hosts today 10% of among the Alexa Top 100K [8], one DNS provider hosts today 10% of the
the domains. The ten most important DNS providers host together one 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 15
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 [12] project to check their availability. Also the QUANTUMTHEORY [9] project
which includes detecting lookups for certain addresses and injecting which includes detecting lookups for certain addresses and injecting
bogus replies is another good example showing that the lack of bogus replies is another good example showing that the lack of
privacy 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 [13] applicable in the European [data-protection-directive] or GDPR [10] 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
skipping to change at page 19, line 21 skipping to change at page 19, line 11
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.
9. Changelog 9. Changelog
draft-ietf-dprive-rfc7626-bis-04
o Tsvart review: Add reference to DNS-over-QUIC, fix typo.
o Secdir review: Add text in Section 3 on devices using many
networks. Update bullet in 3.4.1 on cellular encryption.
o Section 3.5.1.1 - re-work the section to try to address multiple
comments.
o Section 3.5.1.4 - remove this section as now covered by 3.5.1.1.
o Section 3.5.1.5.2 - Remove several paragraphs and more directly
reference RFC8484 by including bullet points quoting text from
Section 8.2 of RFC8484. Retain the last 2 paragraphs as they are
information for users, not implementors.
o Section 3.4.2 - some minor updates made based on specific
comments.
draft-ietf-dprive-rfc7626-bis-03 draft-ietf-dprive-rfc7626-bis-03
o Address 2 minor nits (typo in section 3.4.1 and adding an IANA o Address 2 minor nits (typo in section 3.4.1 and adding an IANA
section) section)
o Minor updates from AD review 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
skipping to change at page 21, line 31 skipping to change at page 21, line 40
[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>.
[chrome] Baheux, , "Experimenting with same-provider DNS-over-HTTPS [centralisation-and-data-sovereignty]
upgrade", September 2019, De Filippi, P. and S. McCarthy, "Cloud Computing:
<https://blog.chromium.org/2019/09/experimenting-with- Centralization and Data Sovereignty", October 2012,
same-provider-dns.html>. <https://papers.ssrn.com/sol3/
papers.cfm?abstract_id=2167372>.
[dagon-malware] [dagon-malware]
Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a Dagon, D., "Corrupted DNS Resolution Paths: The Rise of a
Malicious Resolution Authority", ISC/OARC Workshop, 2007, Malicious Resolution Authority", ISC/OARC Workshop, 2007,
<https://www.dns-oarc.net/files/workshop-2007/Dagon- <https://www.dns-oarc.net/files/workshop-2007/Dagon-
Resolution-corruption.pdf>. Resolution-corruption.pdf>.
[darkreading-dns] [darkreading-dns]
Lemos, R., "Got Malware? Three Signs Revealed In DNS Lemos, R., "Got Malware? Three Signs Revealed In DNS
Traffic", InformationWeek Dark Reading, May 2013, Traffic", InformationWeek Dark Reading, May 2013,
<http://www.darkreading.com/analytics/security-monitoring/ <http://www.darkreading.com/analytics/security-monitoring/
got-malware-three-signs-revealed-in-dns-traffic/d/ got-malware-three-signs-revealed-in-dns-traffic/d/
d-id/1139680>. d-id/1139680>.
[data-protection-directive] [data-protection-directive]
European Parliament, "Directive 95/46/EC of the European European Parliament, "Directive 95/46/EC of the European
Pariament and of the council on the protection of Parliament and of the council on the protection of
individuals with regard to the processing of personal data individuals with regard to the processing of personal data
and on the free movement of such data", Official Journal L and on the free movement of such data", Official Journal L
281, pp. 0031 - 0050, November 1995, <http://eur- 281, pp. 0031 - 0050, November 1995, <http://eur-
lex.europa.eu/LexUriServ/ lex.europa.eu/LexUriServ/
LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>. LexUriServ.do?uri=CELEX:31995L0046:EN:HTML>.
[day-at-root] [day-at-root]
Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A Castro, S., Wessels, D., Fomenkov, M., and K. Claffy, "A
Day at the Root of the Internet", ACM SIGCOMM Computer Day at the Root of the Internet", ACM SIGCOMM Computer
Communication Review, Vol. 38, Number 5, Communication Review, Vol. 38, Number 5,
skipping to change at page 22, line 35 skipping to change at page 22, line 42
client-subnet/>. client-subnet/>.
[ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002, [ditl] CAIDA, "A Day in the Life of the Internet (DITL)", 2002,
<http://www.caida.org/projects/ditl/>. <http://www.caida.org/projects/ditl/>.
[dns-footprint] [dns-footprint]
Stoner, E., "DNS Footprint of Malware", OARC Workshop, Stoner, E., "DNS Footprint of Malware", OARC Workshop,
October 2010, <https://www.dns-oarc.net/files/workshop- October 2010, <https://www.dns-oarc.net/files/workshop-
201010/OARC-ers-20101012.pdf>. 201010/OARC-ers-20101012.pdf>.
[dnschanger]
Wikipedia, "DNSChanger", October 2013,
<https://en.wikipedia.org/w/
index.php?title=DNSChanger&oldid=578749672>.
[dnsmezzo] [dnsmezzo]
Bortzmeyer, S., "DNSmezzo", 2009, Bortzmeyer, S., "DNSmezzo", 2009,
<http://www.dnsmezzo.net/>. <http://www.dnsmezzo.net/>.
[EDDI] EDDI, "Encrypted DNS Deployment Initiative", 2020,
<https://www.encrypted-dns.org>.
[fangming-hori-sakurai] [fangming-hori-sakurai]
Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of Fangming, Z., Hori, Y., and K. Sakurai, "Analysis of
Privacy Disclosure in DNS Query", 2007 International Privacy Disclosure in DNS Query", 2007 International
Conference on Multimedia and Ubiquitous Engineering (MUE Conference on Multimedia and Ubiquitous Engineering (MUE
2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957, 2007), Seoul, Korea, ISBN: 0-7695-2777-9, pp. 952-957,
DOI 10.1109/MUE.2007.84, April 2007, DOI 10.1109/MUE.2007.84, April 2007,
<http://dl.acm.org/citation.cfm?id=1262690.1262986>. <http://dl.acm.org/citation.cfm?id=1262690.1262986>.
[federrath-fuchs-herrmann-piosecny] [federrath-fuchs-herrmann-piosecny]
Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny, Federrath, H., Fuchs, K., Herrmann, D., and C. Piosecny,
"Privacy-Preserving DNS: Analysis of Broadcast, Range "Privacy-Preserving DNS: Analysis of Broadcast, Range
Queries and Mix-based Protection Methods", Computer Queries and Mix-based Protection Methods", Computer
Security ESORICS 2011, Springer, page(s) 665-683, Security ESORICS 2011, Springer, page(s) 665-683,
ISBN 978-3-642-23821-5, 2011, <https://svs.informatik.uni- ISBN 978-3-642-23821-5, 2011, <https://svs.informatik.uni-
hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreser hamburg.de/publications/2011/2011-09-14_FFHP_PrivacyPreser
vingDNS_ESORICS2011.pdf>. vingDNS_ESORICS2011.pdf>.
[firefox] Deckelmann, , "What's next in making Encrypted DNS-over- [getdns] getdns, "getdns - A modern asynchronous DNS API", January
HTTPS the Default", September 2019, 2020, <https://getdnsapi.net>.
<https://blog.mozilla.org/futurereleases/2019/09/06/whats-
next-in-making-dns-over-https-the-default/>.
[grangeia.snooping] [grangeia.snooping]
Grangeia, L., "DNS Cache Snooping or Snooping the Cache Grangeia, L., "DNS Cache Snooping or Snooping the Cache
for Fun and Profit", 2005, for Fun and Profit", 2005,
<https://www.semanticscholar.org/paper/Cache-Snooping-or- <https://www.semanticscholar.org/paper/Cache-Snooping-or-
Snooping-the-Cache-for-Fun-and- Snooping-the-Cache-for-Fun-and-
1-Grangeia/9b22f606e10b3609eafbdcbfc9090b63be8778c3>. 1-Grangeia/9b22f606e10b3609eafbdcbfc9090b63be8778c3>.
[herrmann-reidentification] [herrmann-reidentification]
Herrmann, D., Gerber, C., Banse, C., and H. Federrath, Herrmann, D., Gerber, C., Banse, C., and H. Federrath,
"Analyzing Characteristic Host Access Patterns for Re- "Analyzing Characteristic Host Access Patterns for Re-
Identification of Web User Sessions", Identification of Web User Sessions",
DOI 10.1007/978-3-642-27937-9_10, 2012, <http://epub.uni- DOI 10.1007/978-3-642-27937-9_10, 2012, <http://epub.uni-
regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>. regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf>.
[I-D.huitema-quic-dnsoquic]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-07 (work in
progress), September 2019.
[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-05 (work in Operators", draft-ietf-dprive-bcp-op-07 (work in
progress), October 2019. progress), December 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-24 (work
in progress), September 2019. in progress), November 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-09 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]
Livingood, J., Antonakakis, M., Sleigh, B., and A.
Winfield, "Centralized DNS over HTTPS (DoH) Implementation
Issues and Risks", draft-livingood-doh-implementation-
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,
"NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January "NSA's MORECOWBELL: Knell for DNS", GNUnet e.V., January
2015, <https://pdfs.semanticscholar.org/2610/2b99bdd6a258a 2015, <https://pdfs.semanticscholar.org/2610/2b99bdd6a258a
98740af8217ba8da8a1e4fa.pdf>. 98740af8217ba8da8a1e4fa.pdf>.
[packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries [packetq] DNS-OARC, "PacketQ, a simple tool to make SQL-queries
against PCAP-files", 2011, <https://github.com/DNS-OARC/ against PCAP-files", 2011, <https://github.com/DNS-OARC/
PacketQ>. PacketQ>.
[passive-dns] [passive-dns]
Weimer, F., "Passive DNS Replication", April 2005, Weimer, F., "Passive DNS Replication", April 2005,
<https://www.first.org/conference/2005/papers/florian- <https://www.first.org/conference/2005/papers/florian-
weimer-slides-1.pdf>. weimer-slides-1.pdf>.
[pitfalls-of-dns-encrption] [pitfalls-of-dns-encryption]
Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS Shulman, H., "Pretty Bad Privacy:Pitfalls of DNS
Encryption", <https://dl.acm.org/citation.cfm?id=2665959>. Encryption", <https://dl.acm.org/citation.cfm?id=2665959>.
[prism] Wikipedia, "PRISM (surveillance program)", July 2015, [prism] Wikipedia, "PRISM (surveillance program)", July 2015,
<https://en.wikipedia.org/w/index.php?title=PRISM_(surveil <https://en.wikipedia.org/w/index.php?title=PRISM_(surveil
lance_program)&oldid=673789455>. lance_program)&oldid=673789455>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
editor.org/info/rfc3552>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
skipping to change at page 25, line 27 skipping to change at page 25, line 41
"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 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
Nordmark, "Technical Considerations for Internet Service
Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
March 2016, <https://www.rfc-editor.org/info/rfc7754>.
[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 5 skipping to change at page 26, line 24
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
(DANE) Bindings for OpenPGP", RFC 7929, (DANE) Bindings for OpenPGP", RFC 7929,
DOI 10.17487/RFC7929, August 2016, <https://www.rfc- DOI 10.17487/RFC7929, August 2016, <https://www.rfc-
editor.org/info/rfc7929>. editor.org/info/rfc7929>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
editor.org/info/rfc8310>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[ripe-atlas-turkey]
Aben, E., "A RIPE Atlas View of Internet Meddling in
Turkey", March 2014,
<https://labs.ripe.net/Members/emileaben/a-ripe-atlas-
view-of-internet-meddling-in-turkey>.
[ripe-qname-measurements] [ripe-qname-measurements]
University of Twente, "Making the DNS More Private with University of Twente, "Making the DNS More Private with
QNAME Minimisation", April 2019, QNAME Minimisation", April 2019,
<https://labs.ripe.net/Members/wouter_de_vries/make-dns-a- <https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-
bit-more-private-with-qname-minimisation>. bit-more-private-with-qname-minimisation>.
[sidn-entrada] [sidn-entrada]
Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M. Hesselman, C., Jansen, J., Wullink, M., Vink, K., and M.
Simon, "A privacy framework for 'DNS big data' Simon, "A privacy framework for 'DNS big data'
applications", November 2014, applications", November 2014,
skipping to change at page 27, line 15 skipping to change at page 27, line 27
[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>.
10.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] http://netres.ec/?b=11B99BD
[3] http://netres.ec/?b=11B99BD
[4] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS- [3] https://www.researchgate.net/publication/320322146_DNS-DNS_DNS-
based_De-NAT_Scheme based_De-NAT_Scheme
[5] https://developers.google.com/speed/public-dns [4] https://developers.google.com/speed/public-dns
[6] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/
[7] https://www.quad9.net
[8] https://developers.google.com/speed/public-dns/privacy [5] https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/
[9] https://mailarchive.ietf.org/arch/browse/static/add [6] https://www.quad9.net
[10] https://www.encrypted-dns.org [7] https://developers.google.com/speed/public-dns/privacy
[11] https://www.alexa.com/topsites [8] https://www.alexa.com/topsites
[12] https://theintercept.com/document/2014/03/12/nsa-gchqs- [9] https://theintercept.com/document/2014/03/12/nsa-gchqs-
quantumtheory-hacking-tactics/ quantumtheory-hacking-tactics/
[13] https://www.eugdpr.org/the-regulation.html [10] 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
Sara Dickinson Sara Dickinson
Sinodun IT Sinodun IT
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
 End of changes. 70 change blocks. 
226 lines changed or deleted 228 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/