draft-ietf-dprive-rfc7626-bis-07.txt   draft-ietf-dprive-rfc7626-bis-08.txt 
dprive T. Wicinski, Ed. dprive T. Wicinski, Ed.
Internet-Draft October 7, 2020 Internet-Draft October 15, 2020
Obsoletes: 7626 (if approved) Obsoletes: 7626 (if approved)
Intended status: Informational Intended status: Informational
Expires: April 10, 2021 Expires: April 18, 2021
DNS Privacy Considerations DNS Privacy Considerations
draft-ietf-dprive-rfc7626-bis-07 draft-ietf-dprive-rfc7626-bis-08
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 10, 2021. This Internet-Draft will expire on April 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 7 skipping to change at page 3, line 7
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
often ignored or misunderstood by Internet users (and even by many often ignored or misunderstood by Internet users (and even by many
professionals). Almost every activity on the Internet starts with a professionals). Almost every activity on the Internet starts with a
DNS query (and often several). Its use has many privacy implications DNS query (and often several). Its use has many privacy implications
and this document is an attempt at a comprehensive and accurate list. and this document is an attempt at a comprehensive and accurate list.
Lets begin with a simplified reminder of how the DNS works (See also Let us begin with a simplified reminder of how the DNS works (See
[RFC8499]). A client, the stub resolver, issues a DNS query to a also [RFC8499]). A client, the stub resolver, issues a DNS query to
server, called the recursive resolver (also called caching resolver a server, called the recursive resolver (also called caching resolver
or full resolver or recursive name server). Let's use the query or full resolver or recursive name server). Let's use the query
"What are the AAAA records for www.example.com?" as an example. AAAA "What are the AAAA records for www.example.com?" as an example. AAAA
is the QTYPE (Query Type), and www.example.com is the QNAME (Query is the QTYPE (Query Type), and www.example.com is the QNAME (Query
Name). (The description that follows assumes a cold cache, for Name). (The description that follows assumes a cold cache, for
instance, because the server just started.) The recursive resolver instance, because the server just started.) The recursive resolver
will first query the root name servers. In most cases, the root name will first query the root name servers. In most cases, the root name
servers will send a referral. In this example, the referral will be servers will send a referral. In this example, the referral will be
to the .com name servers. The resolver repeats the query to one of to the .com name servers. The resolver repeats the query to one of
the .com name servers. The .com name servers, in turn, will refer to the .com name servers. The .com name servers, in turn, will refer to
the example.com name servers. The example.com name server will then the example.com name servers. The example.com name server will then
skipping to change at page 4, line 18 skipping to change at page 4, line 18
unencrypted. However, there is increasing deployment of DNS-over-TLS unencrypted. However, there is increasing deployment of DNS-over-TLS
(DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], particularly in
mobile devices, browsers, and by providers of anycast recursive DNS mobile devices, browsers, and by providers of anycast recursive DNS
resolution services. There are a few cases where there is some resolution services. There are a few cases where there is some
alternative channel encryption, for instance, in an IPsec VPN tunnel, alternative channel encryption, for instance, in an IPsec VPN tunnel,
at least between the stub resolver and the resolver. 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, although new solutions are still
emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-dnsoquic]. emerging [I-D.ietf-quic-transport] [I-D.ietf-dprive-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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
user would need to take into account the set of devices used and the user would need to take into account the set of devices used and the
multiple dynamic contexts of each device. This document does not multiple dynamic contexts of each device. This document does not
attempt such a complex analysis, but instead it presents an overview attempt such a complex analysis, but instead it presents an overview
of the various considerations that could form the basis of such an of the various considerations that could form the basis of such an
analysis. analysis.
4. Risks in the DNS Data 4. Risks in the DNS Data
4.1. The Public Nature of DNS Data 4.1. The Public Nature of DNS Data
It is often stated that "the data in the DNS is public". This It has been stated that "the data in the DNS is public". This
sentence makes sense for an Internet-wide lookup system, and there sentence makes sense for an Internet-wide lookup system, and 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
lack of search capabilities, only a given QNAME will reveal the lack of search capabilities, only a given QNAME will reveal the
resource records associated with that name (or that name's non- resource records associated with that name (or that name's non-
existence). In other words: one needs to know what to ask for, in existence). In other words: one needs to know what to ask for, in
order to receive a response. There are many ways in which supposed order to receive a response. There are many ways in which supposedly
"private" resources currently leak. A few examples are DNSSEC NSEC "private" resources currently leak. A few examples are DNSSEC NSEC
zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The zone walking[RFC4470]; passive-DNS services[passive-dns]; etc. The
zone transfer QTYPE [RFC5936] is often blocked or restricted to zone transfer QTYPE [RFC5936] is often blocked or restricted to
authenticated/authorized access to enforce this difference (and maybe authenticated/authorized access to enforce this difference (and maybe
for other reasons). for other reasons).
Another differentiation to be considered is between the DNS data Another differencce between the DNS data and a particular DNS
itself and a particular transaction (i.e., a DNS name lookup). DNS transaction (i.e., a DNS name lookup). DNS data and the results of a
data and the results of a DNS query are public, within the boundaries DNS query are public, within the boundaries described above, and may
described above, and may not have any confidentiality requirements. not have any confidentiality requirements. However, the same is not
However, the same is not true of a single transaction or a sequence true of a single transaction or a sequence of transactions; those
of transactions; those transactions are not / should not be public. transactions are not / should not be public. A single transactions
A single transactions reveals both the originator of the query and reveals both the originator of the query and the query contents which
the query contents which potentially leaks sensitive information potentially leaks sensitive information about a specific user. A
about a specific user. A typical example from outside the DNS world typical example from outside the DNS world is: the web site of
is: the web site of Alcoholics Anonymous is public; the fact that you Alcoholics Anonymous is public; the fact that you visit it should not
visit it should not be. Furthermore, the ability to link queries be. Furthermore, the ability to link queries reveals information
reveals information about individual use patterns. about individual use patterns.
4.2. Data in the DNS Request 4.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), for instance [RFC6269]). NAT (CGN), for instance [RFC6269]).
skipping to change at page 7, line 33 skipping to change at page 7, line 33
becomes a lot more important. And email is just an example; there becomes a lot more important. And email is just an example; there
would be other really interesting uses for a more privacy-friendly would be other really interesting uses for a more privacy-friendly
DNS. DNS.
For the communication between the stub resolver and the recursive For the communication between the stub resolver and the recursive
resolver, the source IP address is the address of the user's machine. resolver, the source IP address is the address of the user's machine.
Therefore, all the issues and warnings about collection of IP Therefore, all the issues and warnings about collection of IP
addresses apply here. For the communication between the recursive addresses apply here. For the communication between the recursive
resolver and the authoritative name servers, the source IP address resolver and the authoritative name servers, the source IP address
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 can be typically the IP
of the recursive resolver that, in a way, "hides" the real user. address of the recursive resolver that, in a way, "hides" the real
However, hiding does not always work. Sometimes EDNS(0) Client user. However, hiding does not always work. Sometimes EDNS(0)
subnet [RFC7871] is used (see its privacy analysis in Client subnet [RFC7871] is used (see one 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 recursive resolver on her machine. In both cases, the IP address
originating queries to the authoritative server is as sensitive as it originating queries to the authoritative server is as sensitive as it
is for HTTP [sidn-entrada]. 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
general, although [RFC7721] does discuss privacy considerations for general, although [RFC7721] does discuss privacy considerations for
IPv6 address generation mechanisms. In the meantime, the discussion IPv6 address generation mechanisms. In the meantime, the discussion
here is intended to include both IPv4 and IPv6 source addresses. For here is intended to include both IPv4 and IPv6 source addresses. For
a number of reasons, their assignment and utilization characteristics a number of reasons, their assignment and utilization characteristics
are different, which may have implications for details of information are different, which may have implications for details of information
leakage associated with the collection of source addresses. (For leakage associated with the collection of source addresses. (For
example, a specific IPv6 source address seen on the public Internet example, a specific IPv6 source address seen on the public Internet
is less likely than an IPv4 address to originate behind an address is less likely than an IPv4 address to originate behind an address
sharing scheme.) However, for both IPv4 and IPv6 addresses, it is sharing scheme.) However, for both IPv4 and IPv6 addresses, it is
important to note that source addresses are propagated with queries important to note that source addresses are propagated with queries
and comprise metadata about the host, user, or application that via EDNS(0) Client subnet and comprise metadata about the host, user,
originated them. or application that originated them.
4.2.1. Data in the DNS Payload 4.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 5 skipping to change at page 9, line 5
For unencrypted transports, DNS traffic can be seen by an For unencrypted transports, DNS traffic can be seen by an
eavesdropper like any other traffic. (DNSSEC, specified in eavesdropper like any other traffic. (DNSSEC, specified in
[RFC4033], explicitly excludes confidentiality from its goals.) So, [RFC4033], explicitly excludes confidentiality from its goals.) So,
if an initiator starts an HTTPS communication with a recipient, while if an initiator starts an HTTPS communication with a recipient, while
the HTTP traffic will be encrypted, the DNS exchange prior to it will the HTTP traffic will be encrypted, the DNS exchange prior to it will
not be. When other protocols will become more and more privacy-aware not be. When other protocols will become more and more privacy-aware
and secured against surveillance (e.g., [RFC8446], and secured against surveillance (e.g., [RFC8446],
[I-D.ietf-quic-transport]), the use of unencrypted transports for DNS [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS
may become "the weakest link" in privacy. It is noted that at the may become "the weakest link" in privacy. It is noted that at the
time of writing there is on-going work attempting to encrypt the SNI time of writing there is on-going work attempting to encrypt the SNI
in the TLS handshake [RFC8744]. in the TLS handshake [RFC8744], which is one of the last remaining
non-DNS cleartext identifiers of a connection target.
An important specificity of the DNS traffic is that it may take a An important specificity of the DNS traffic is that it may take a
different path than the communication between the initiator and the different path than the communication between the initiator and the
recipient. For instance, an eavesdropper may be unable to tap the recipient. For instance, an eavesdropper may be unable to tap the
wire between the initiator and the recipient but may have access to wire between the initiator and the recipient but may have access to
the wire going to the recursive resolver, or to the authoritative the wire going to the recursive resolver, or to the authoritative
name servers. name servers.
The best place to tap, from an eavesdropper's point of view, is The best place to tap, from an eavesdropper's point of view, is
clearly between the stub resolvers and the recursive resolvers, clearly between the stub resolvers and the recursive resolvers,
skipping to change at page 14, line 5 skipping to change at page 14, line 5
An increasing number of applications are offering application- An increasing number of applications are offering application-
specific encrypted DNS resolution settings, rather than defaulting to specific encrypted DNS resolution settings, rather than defaulting to
using only the system resolver. A variety of heuristics and using only the system resolver. A variety of heuristics and
resolvers are available in different applications including hard- resolvers are available in different applications including hard-
coded lists of recognized DoH/DoT servers. coded lists of recognized DoH/DoT servers.
Users will only be aware of and have the ability to control such Users will only be aware of and have the ability to control such
settings if applications provide the following functions: settings if applications provide the following functions:
o communicate clearly the change in default to users o communicate clearly to users the change when the default
application resolver changes away from the system resolver
o provide configuration options to change the default o provide configuration options to change the default
o provide configuration options to always use the system resolver o provide configuration options to always use the system resolver
Application-specific changes to default destinations for users' DNS Application-specific changes to default destinations for users' DNS
queries might increase or decrease user privacy - it is highly queries might increase or decrease user privacy - it is highly
dependent on the network context and the application-specific dependent on the network context and the application-specific
default. This is an area of active debate and the IETF is working on default. This is an area of active debate and the IETF is working on
a number of issues related to application-specific DNS settings. a number of issues related to application-specific DNS settings.
skipping to change at page 14, line 40 skipping to change at page 14, line 41
configured in a secure way with the server identity, an active configured in a secure way with the server identity, an active
attacker can impersonate the server. This implies that opportunistic attacker can impersonate the server. This implies that opportunistic
modes of DoH/DoT as well as modes where the client learns of the DoH/ 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 DoT server via in-network mechanisms such as DHCP are vulnerable to
attack. In addition, if the client is compromised, the attacker can attack. In addition, if the client is compromised, the attacker can
replace the DNS configuration with one of its own choosing. replace the DNS configuration with one of its own choosing.
6.1.3. Blocking of User Selected DNS Resolution Services 6.1.3. Blocking of User Selected DNS Resolution Services
User privacy can also be at risk if there is blocking of access to User privacy can also be at risk if there is blocking of access to
remote recursive servers that offer encrypted transports when the remote recursive servers that offer encrypted transports e.g., when
local resolver does not offer encryption and/or has very poor privacy the local resolver does not offer encryption and/or has very poor
policies. For example, active blocking of port 853 for DoT or of privacy policies. For example, active blocking of port 853 for DoT
specific IP addresses could restrict the resolvers available to the or of specific IP addresses could restrict the resolvers available to
user. The extent of the risk to end user privacy is highly dependent the user. The extent of the risk to end user privacy is highly
on the specific network and user context; a user on a network that is dependent on the specific network and user context; a user on a
known to perform surveillance would be compromised if they could not network that is known to perform surveillance would be compromised if
access such services, whereas a user on a trusted network might have they could not access such services, whereas a user on a trusted
no privacy motivation to do so. network might have no privacy motivation to do so.
As a matter of policy, some recursive resolvers use their position in As a matter of policy, some recursive resolvers use their position in
the query path to selectively block access to certain DNS records. the query path to selectively block access to certain DNS records.
This is a form of Rendezvous-Based Blocking as described in This is a form of Rendezvous-Based Blocking as described in
Section 4.3 of [RFC7754]. Such blocklists often include servers Section 4.3 of [RFC7754]. Such blocklists often include servers
known to be used for malware, bots or other security risks. In order known to be used for malware, bots or other security risks. In order
to prevent circumvention of their blocking policies, some networks to prevent circumvention of their blocking policies, some networks
also block access to resolvers with incompatible policies. also block access to resolvers with incompatible policies.
It is also noted that attacks on remote resolver services, e.g., 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 DDoS, could force users to switch to other services that do not offer
encrypted transports for DNS. encrypted transports for DNS.
skipping to change at page 17, line 4 skipping to change at page 17, line 6
authoritative name server sees the original IP address (or prefix, authoritative name server sees the original IP address (or prefix,
depending on the setup). depending on the setup).
As of today, all the instances of one root name server, L-root, As of today, all the instances of one root name server, L-root,
receive together around 50,000 queries per second. While most of it receive together around 50,000 queries per second. While most of it
is "junk" (errors on the Top-Level Domain (TLD) name), it gives an is "junk" (errors on the Top-Level Domain (TLD) name), it gives an
idea of the amount of big data that pours into name servers. (And idea of the amount of big data that pours into name servers. (And
even "junk" can leak information; for instance, if there is a typing even "junk" can leak information; for instance, if there is a typing
error in the TLD, the user will send data to a TLD that is not the error in the TLD, the user will send data to a TLD that is not the
usual one.) usual one.)
Many domains, including TLDs, are partially hosted by third-party Many domains, including TLDs, are partially hosted by third-party
servers, sometimes in a different country. The contracts between the servers, sometimes in a different country. The contracts between the
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. For
requests to a given ccTLD may go to servers managed by organizations example, requests to a given ccTLD may go to servers managed by
outside of the ccTLD's country. End users may not anticipate that, organizations outside of the ccTLD's country. End users may not
when doing a security analysis. anticipate that, 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 [7], one DNS provider hosts today 10% of the among the Alexa Top 100K [7], one DNS provider hosts today 10% of 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.
7. Other risks 7. Other risks
skipping to change at page 18, line 5 skipping to change at page 18, line 7
browsing behavior, equally characteristic patterns may be produced browsing behavior, equally characteristic patterns may be produced
even in machine-to-machine communications or without a user taking even in machine-to-machine communications or without a user taking
specific actions, e.g., at reboot time if a characteristic set of specific actions, e.g., at reboot time if a characteristic set of
services are accessed by the device. services are accessed by the device.
For instance, one could imagine that an intelligence agency For instance, one could imagine that an intelligence agency
identifies people going to a site by putting in a very long DNS name identifies people going to a site by putting in a very long DNS name
and looking for queries of a specific length. Such traffic analysis and looking for queries of a specific length. Such traffic analysis
could weaken some privacy solutions. could weaken some privacy solutions.
The IAB privacy and security program also have a work in progress The IAB privacy and security program also have a document [RFC7624]
[RFC7624] that considers such inference-based attacks in a more that considers such inference-based attacks in a more general
general framework. framework.
7.2. More Information 7.2. More Information
Useful background information can also be found in [tor-leak] (about Useful background information can also be found in [tor-leak] (about
the risk of privacy leak through DNS) and in a few academic papers: the risk of privacy leak through DNS) and in a few academic papers:
[yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and [yanbin-tsudik], [castillo-garcia], [fangming-hori-sakurai], and
[federrath-fuchs-herrmann-piosecny]. [federrath-fuchs-herrmann-piosecny].
8. Actual "Attacks" 8. Actual "Attacks"
skipping to change at page 27, line 17 skipping to change at page 27, line 17
Update many references; Add discussions of encrypted transports Update many references; Add discussions of encrypted transports
including DoT and DoH; Added section on DNS payload; Add section on including DoT and DoH; Added section on DNS payload; Add section on
authentication of servers; Add section on blocking of services. With authentication of servers; Add section on blocking of services. With
the publishing of RFC7816 on QNAME minimisation, text, references, the publishing of RFC7816 on QNAME minimisation, text, references,
and initial attempts to measure deployment were added to reflect and initial attempts to measure deployment were added to reflect
this. The text and references on the Snowden revelations were this. The text and references on the Snowden revelations were
updated. updated.
The "Risks overview" section was changed to "Scope" to help clarify The "Risks overview" section was changed to "Scope" to help clarify
the risks being considered. Text was adding on cellular network DNS, the risks being considered. Text was adding on cellular network DNS,
blocking and security blocking and security. Considerations for recursive resolvers were
collected and placed together. Addded a discussion on resolver
selection.
o Collect considerations for recursive resolvers together Appendix B. Changelog
o Re-work several sections here to clarify their context (e.g., draft-ietf-dprive-rfc7626-bis-05
'Rogue servers' becomes 'Active attacks on resolver
configuration')
o Add discussion of resolver selection o Second batch of Editorial updates from IESG last call
Appendix B. Changelog draft-ietf-dprive-rfc7626-bis-07
o First batch of Editorial updates from IESG last call
draft-ietf-dprive-rfc7626-bis-06 draft-ietf-dprive-rfc7626-bis-06
o Removed Sara and Stephane as editors, made chairs as Editor. o Removed Sara and Stephane as editors, made chairs as Editor.
o Replaced the text in 6.1.1.2 with the text from the -04 version. o Replaced the text in 6.1.1.2 with the text from the -04 version.
o Clarified text about resolver selection in 6.1.1. o Clarified text about resolver selection in 6.1.1.
draft-ietf-dprive-rfc7626-bis-05 draft-ietf-dprive-rfc7626-bis-05
 End of changes. 23 change blocks. 
53 lines changed or deleted 59 lines changed or added

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