Subject: [dns-privacy] Last Call: <draft-ietf-dprive-rfc7626-bis-04.txt> (DNS Privacy Considerations) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 20 Jan 2020 15:00:20 -0800

The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS Privacy Considerations'
  <draft-ietf-dprive-rfc7626-bis-04.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-02-03. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   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
   present situation and does not prescribe solutions.  This document
   obsoletes RFC 7626.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Bob Harold <[email-masked]>
Date: Tue, 21 Jan 2020 10:50:56 -0500

> No IPR declarations have been submitted directly on this I-D.
Looks good to me.  One grammar nit:

3.5.1.4.2.  DoH Specific Considerations
next to last paragraph
"Some implementations have, in fact, chosen restrict the use of"
change to:
"Some implementations have, in fact, chosen to restrict the use of"

-- 
Bob Harold

---

From: Rob Sayre <[email-masked]>
Date: Wed, 22 Jan 2020 01:39:46 -0800

Hi,

Here are my last-call comments on draft-ietf-dprive-rfc7626-bis.

#
# 1.  Introduction
#

> It is one of the most important infrastructure components of the Internet
> and often ignored or misunderstood by Internet users (and even by many
> professionals).

This text is carried over from RFC 7626, but it doesn't seem grounded in
fact.

> Because DNS relies on caching heavily...

Suggest rewriting this paragraph to avoid starting two sentences with
"Because".

"DNS relies on caching heavily, so the algorithm described above is
actually a
bit more complicated"

> Because there is typically no caching in the stub resolver,

I think it's a stretch to call this "typical".

The text then draws a parenthetical distinction between stub resolvers and
"Applications" that is not grounded in fact:

> (Applications, like web browsers, may have some form of caching that does
> not follow DNS rules...

This text doesn't seem helpful:

> At the time of writing, almost all this DNS traffic is currently sent
> in clear (i.e., unencrypted)...

Suggest striking, and combining with the following paragraph.

I also question the value of describing the concerns around TCP, QUIC etc.
It seems like anything published will be out of date by the time an RFC
appears. Even the citation currently in the draft:

"Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]"

is from 2014. I would suggest a purely factual formulation. Something like:

"The original DNS RFCs describe an unencrypted protocol over UDP... newer
RFCs provide for DNS traffic over reliable transports and encryption
[various citations]"

> 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
> triggered by different reasons. Let's assume...

Suggest:

"Multiple DNS requests can be triggered by a single user-initiated action.
Let's assume..."

Next in the text:

> Primary request: this is the domain name in the URL that the user
> typed, selected from a bookmark, or chose by clicking on an
> hyperlink.  Presumably, this is what is of interest for the eavesdropper.

The second sentence is not supported by fact and should be struck.

The Introduction ends with this paragraph:

> It can be noted also that, in the case of a typical web browser, more
> DNS requests than strictly necessary are sent, for instance, to
> prefetch resources that the user may query later or when
> autocompleting the URL in the address bar.  Both are a big privacy
> concern since they may leak information even about non-explicit
> actions.  For instance, just reading a local HTML page, even without
> selecting the hyperlinks, may trigger DNS requests.

This text is redundant with the bullet points above. Suggest striking this
paragraph and adding "prefetch resources" to the list in the second bullet
point that has "JavaScript code, embedded images, etc"...

It also suggests there's "a big privacy concern" when it's not clear that
the
threat is any worse than all of the other things going on in a browser.

#
# 2.  Scope
#

> This document does not attempt a comparison of specific privacy
> protections provided by individual networks or organizations, it
> makes only general observations about typical current practices.

Suggest striking this paragraph, as the part about "typical current
practices" can't be supported by fact.

#
# 3.1.  The Alleged Public Nature of DNS Data
#

> It has long been claimed that "the data in the DNS is public".

This quote needs a citation if included. It is even contradicted by text in
Section 2: "leakage of private namespaces...".

The later paragraphs of this section seem redundant once the next section is
considered.

#
# 3.2.  Data in the DNS Request
#

This text seems purely speculative:

> Another important thing about the privacy of the QNAME is the future
> usages.  Today, the lack of privacy is an obstacle to putting
> potentially sensitive or personally identifiable data in the DNS.  At
> the moment, your DNS traffic might reveal that you are doing email
> but not with whom.  If your Mail User Agent (MUA) starts looking up
> Pretty Good Privacy (PGP) keys in the DNS [RFC7929], then privacy
> becomes a lot more important.  And email is just an example; there
> would be other really interesting uses for a more privacy-friendly
> DNS.

Next:

> For the communication between the stub resolver and the recursive
> resolver, the source IP address is the address of the user's machine.
> Therefore, all the issues and warnings about collection of IP addresses
> apply here.

This text doesn't seem to be quite correct.

> In both cases, the IP address is as sensitive as it is for HTTP
> [sidn-entrada].

Is this true? I am not sure--the statement seems so vague it's hard to
evaluate.

#
# 3.2.1.  Data in the DNS payload
#

> There are anecdotal accounts of MAC addresses [1] and even user names
> being inserted in non-standard EDNS(0) options

This is missing citations (say for RFC 6891), but it's also just anecdotal
and
should be struck.

#
# 3.3.  Cache Snooping
#

> Since this also is a reconnaissance technique for subsequent cache
poisoning
> attacks, some counter measures have already been developed and deployed.

There should be citations here, otherwise strike this text.

#
# 3.4.  On the Wire
#
# 3.4.1.  Unencrypted Transports
#

> For unencrypted transports, DNS traffic can be seen by an
> eavesdropper like any other traffic.

This text seems like it should be largely deleted. It's redundant given the
text "almost all DNS queries are sent over UDP..." in the Introduction. Or,
move the text from the Introduction to this section.

> An important specificity of the DNS traffic is that it may take a
> different path than the communication between the initiator and the
> recipient.

I think this text in describing anything specific to DNS--it's just one
client
and two servers.

> The best place to tap, from an eavesdropper's point of view, is
> clearly between the stub resolvers and the recursive resolvers,
> because traffic is not limited by DNS caching.

Not sure this is true--clearly just monitoring a busy fiber optic cable has
been an attractive tactic.

#
# 3.4.2.  Encrypted Transports
#

> These issues are not specific to DNS, but DNS traffic is susceptible to
> these attacks when using specific transports.

Yes. Just put HTTPS in this section.

> More specifically, (since the deployment of encrypted transports is
> not widespread at the time of writing) users wishing to use encrypted
> transports for DNS may in practice be limited in the resolver
> services available.  Given this, the choice of a user to configure a
> single resolver (or a fixed set of resolvers) and an encrypted
> transport to use in all network environments can actually serve to
> identify the user as one that desires privacy and can provide an
> added mechanism to track them as they move across network environments.

This paragraph doesn't seem true, and will certainly become less so over
time.
Is there a citation?

> Default configuration options for encrypted transports could in principle
> fingerprint a specific client application.

Is this text describing anything outside fingerprinting in general? Suggest
striking.

> If libraries or applications offer user configuration of such options
> (e.g.  [getdns])

Again, this text describes fingerprinting in general. The [getdns] reference
doesn't seem necessary, either. (It's a link to software by one of the
authors... not sure that should be ok in a consensus document).

> Whilst there are known attacks on older versions of TLS the most
> recent recommendations [RFC7525] and the development of TLS 1.3
> [RFC8446] largely mitigate those.

This text doesn't seem specific enough to be helpful--readers should just
read
up on TLS.

> Traffic analysis of unpadded encrypted traffic is also possible
> [pitfalls-of-dns-encryption]

This seems like another general TLS/fingerprinting issue not specific to
DNS,
and it also seems to be from 2014.

#
# 3.5.1.  In the Recursive Resolvers
#

> Recursive Resolvers see all the traffic since there is typically no
> caching before them.

This isn't true.

#
# 3.5.1.1.  Resolver Selection
#

> In general, as with many other protocols, issues around
> centralization also arise with DNS.  The picture is fluid with
> several competing factors contributing which can also vary by
> geographic region.

This is not a privacy concern, but rather a more vague one about
centralization.

> An increased proportion of the global DNS resolution traffic being
> served by only a few entities means that the privacy considerations
> for end users are highly dependent on the privacy policies and
> practices of those entities

This is misleading. Centralized DNS only cuts off current entities /if/ it's
encrypted. Otherwise, everyone on the wire can collect the data, making the
"privacy considerations for end users" dependent on several more parties.

> Many of the issues around centralization are discussed in
> [centralisation-and-data-sovereignty].

I am not sure this 2012 paper is relevant here.

#
# 3.5.1.1.1.  Dynamic Discovery of DoH and Strict DoT
#

> At the time of writing, efforts to provide standardized signaling
mechanisms
> to discover the services

It's not clear that this is possible in a meaningful way. Suggest striking,
as
the text is speculative.

> 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].

The EDDI list seems ok, but I'm not sure it warrants a reference here.
Certainly they do not focus on "publishing DNS privacy polices", though.

#
# 3.5.1.1.2.  Application-specific Resolver Selection
#

This section seems to contain no non-speculative information. Suggest
striking. Maybe the most direct criticism is that the entire section also
applies to Operating Systems.

#
# 3.5.1.2.  Active Attacks on Resolver Configuration
#

This section describes why the section on "Dynamic Discovery" is misguided.
However, I believe it describes general security and privacy concerns that
are
not specific to DNS, and should be struck. For example:

> 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 DNS Resolution Services
#

This section doesn't have a clear point.

> The extent of the risk to end user privacy is highly dependent on the
> specific network and user context...

The section covers blocking of the user, by the user, of the network, by the
network, and DDoS? What does this have to do with privacy? For example, what
does the text about RFC7754 have to do with privacy?

#
# 3.5.1.4.  Encrypted Transports and Recursive Resolvers
#
# 3.5.1.4.1.  DoT and DoH
#

> Use of encrypted transports does not reduce the data available in the
> recursive resolver and ironically can actually expose more
> information about users to operators.  As described in Section 3.4.2
> use of session based encrypted transports (TCP/TLS) can expose
> correlation data about users.

I don't think this is correct in a general enough way to be written like
this.

#
# 3.5.1.4.2.  DoH Specific Considerations
#

> DoH inherits the full privacy properties of the HTTPS stack and as a
> consequence introduces new privacy considerations when compared with
> DNS over UDP, TCP or TLS [RFC7858].

Suggest:

"DoH inherits the full privacy properties of the HTTPS stack. There are
additional metadata locations to consider in comparison to DNS over UDP,
TCP
or TLS [RFC7858]".

Reasoning: any data in an HTTP header can also be placed in a TLS extension.

> HTTPS presents new considerations for correlation...

No, these are all present in TLS as well, but it's true that HTTP headers
are
a new metadata location (as I suggest above).

> The User-Agent and Accept-Language request header fields

Not clear this is going to be an issue. Of course, an application could
include some extremely damaging metadata in an HTTP header, but this is also
possible in a TLS extension.

> Utilizing the full set of HTTP features enables DoH to be more than an
> HTTP tunnel

Not clear what this means.

> Implementations are advised to expose the minimal set of data needed to
> achieve the desired feature set

This seems like general advice not specific to HTTPS or DoH.

> At the extremes, there may be implementations that attempt to achieve
parity
> with DoT

Not a justified use of "parity".

> 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

That wouldn't actually do the trick. TLS ClientHello messages are also
easily
fingerprinted.

> Privacy focused users ...

Not specific to DoH.

#
# 3.5.2.  In the Authoritative Name Servers
#

> Also, the end user typically has some legal/contractual link with the
> recursive resolver

Not sure this is true.

In general, I'm not sure this section provides much useful analysis, but
this:

> With the control (or the ability to sniff the traffic) of a few name
> servers, you can gather a lot of information.

seems to conflict with other parts of the document that claim encryption
leads
to more identifying data. Both can be true, but the document does not state
the problem in one place and balance the concerns well.

The rest of the document seems related to general surveillance concerns. I
do
not object to it, but also don't think it's specific to DNS.

thanks,
Rob

On Mon, Jan 20, 2020 at 3:03 PM The IESG <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 24 Jan 2020 14:43:12 +0000

> On 22 Jan 2020, at 09:39, Rob Sayre <[email-masked]> wrote:
> 
> Hi,
> 

Thank you for your detailed 45 point review of this document during the second IETF last call.

18 of these points relate to text that is unchanged since the original RFC7626, I’ll mark these as [RFC7626].  To avoid repetition I’ll outline that since this text has already received two forms of consensus (IETF consensus on publishing RFC7626 and DPRIVE WGLC for this document) I am taking a conservative approach during the second IETF Last Call of not removing or making substantial changes to that text unless there is a good reason to do so. 

> This text is carried over from RFC 7626, but it doesn't seem grounded in fact.

[RFC7626] I don’t recall any other review of this document contesting this statement. 

> "DNS relies on caching heavily, so the algorithm described above is actually a
> bit more complicated”

[RFC7626] I’m fine with this grammatical change.

> I think it's a stretch to call this "typical”.

[RFC7626] Suggest “s/typically/often/“

alternatively “s/no/no or only limited/"

> > (Applications, like web browsers, may have some form of caching that does

[RFC7626] Can you clarify - are you disputing that they cache or that they don’t follow DNS rules?

> Suggest striking, and combining with the following paragraph.

The document's focus is privacy concerns of the DNS for Internet users. Providing guidance on the deployed balance between clear text and encryption of DNS on the Internet seems useful. 

> appears. 

The DPRIVE working group spent a significant amount of time evaluating DTLS vs TLS vs STARTTLS on port 53 due to the concerns around backwards compatibility and scalability of encrypting the DNS. Switching a protocol from using UDP to a session based protocol for an infrastructure as large as the DNS is non-trivial. 

> Even the citation currently in the draft:
> 
> is from 2014. 

Fair point. It is, however, for DITL data and since there is no standard for encryption to authoritative servers this is highly unlikely to have changed. The data is collected every year though, so I will contact the authors since they may have a more recent study. Also, I suggest adding a reference to:

An End-to-End, Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come? https://faculty.sites.uci.edu/zhouli/files/2019/09/imc19.pdf

> I would suggest a purely factual formulation. Something like:
> 
> [various citations]”

As mentioned above, this document describes deployment and use of DNS in addition to mentioning protocol specifications. 

> Let's assume…"

[RFC7626] DNS requests can be triggered for many reasons other than user-initiated action. For example, many OSs and application use periodic DNS probing for connectively and do periodic DNS lookups to discover if software updates are available. 

> The second sentence is not supported by fact and should be struck.

[RFC7626]  

> point that has "JavaScript code, embedded images, etc"…
> 
> It also suggests there's "a big privacy concern" when it's not clear that the

[RFC7626] The bullet points refer to DNS requests that are necessary to provide the web page content. This paragraph discusses additional queries that are not strictly necessary to provide that core functionality. The distinction seems useful from a privacy perspective.

> practices" can't be supported by fact.

Suggest retaining this text, since the DPRIVE working group reached consensus on it.

> Section 2: "leakage of private namespaces…”.

> The later paragraphs of this section seem redundant once the next section is

[RFC7626] and to quote Stephane from his email of 9 Jan:

“It is indeed an important tenet of the draft (as it was for RFC 7626).”

> > would be other really interesting uses for a more privacy-friendly

[RFC7626]  

> This text doesn't seem to be quite correct. 

[RFC7626] In what way? Recursive resolvers see both the queries and IP addresses. 

> Is this true? I am not sure--the statement seems so vague it's hard to

[RFC7626] It means that for the last two case described in this paragraph the IP address exposed to the authoritative resolver is the originating clients IP, not a recursive resolvers' address and so it leaks information in the same was as the source address in an HTTP connection.

Suggest “s/the IP address/the IP address originating queries to the authoritative server/"

> This is missing citations (say for RFC 6891), but it's also just anecdotal and
> should be struck.

The discovery of this practice was an important finding within the DNS community to realise that client identifies were being used in this way, I don’t see a problem with this in an Informational RFC. I do note that the reference is incorrect - will replace with the correct one:
https://lists.dns-oarc.net/pipermail/dns-operations/2016-January/014143.html <https://lists.dns-oarc.net/pipermail/dns-operations/2016-January/014143.html>

Will add the missing reference for RFC6891.

> 
> #
> # 3.3.  Cache Snooping
> #
> 
> > Since this also is a reconnaissance technique for subsequent cache poisoning

[RFC7626] Will add a reference to https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-07#ref-ISC-Knowledge-database-on-cache-snooping

> move the text from the Introduction to this section.

[RFC7626] It is one sentence to provide context, I don’t believe the repetition is detrimental to the readability of the document. 

> I think this text in describing anything specific to DNS--it's just one client
> and two servers.

I assume you mean ‘don’t think’?

[RFC7626] I’m not sure you have understood the point. The initiator and recipient here are those involved in an HTTP communication. It is correct that the DNS traffic may take a different path via one or more resolvers, forwarders, proxies, validators and authoritative servers. Indeed it is often true to say that there are more than one client and two servers in the full resolution path. Also, a DNS “client" (stubs, resolvers, forwarders, proxies or validators) may send multiple queries for the same or similar (A and AAAA) information at the same time to multiple upstreams over different paths.

> been an attractive tactic.

[RFC7626] But if your goal is to eavesdrop on DNS traffic from end users specifically, then this is true. 

> Yes. Just put HTTPS in this section.

The section covers both DoT and DoH. I don’t understand your suggestion. 

> This paragraph doesn't seem true, and will certainly become less so over time.
> Is there a citation?

As mentioned in another thread I have worked directly with several early adopters who configured their systems to use their own DoT resolver. 

In terms of users configuring specific resolvers there are good privacy reasons to use as few resolvers as possible for resolution (whilst not be subject to a single point of failure) so this seems a genuine issue with DNS.

> authors... not sure that should be ok in a consensus document).

For both these points the relevance is that new implementations of encrypted DNS are emerging and therefore add concerns about fingerprinting to DNS that didn’t exist when only UDP was used. As for the reference, this is an Informational RFC - as long as this reference is relevant there is no reason not to include it. A previous comment asked if there were examples of DNS implementations that allow configuration of these options so this reference was added. 

> This text doesn't seem specific enough to be helpful--readers should just read
> up on TLS.

RFC7858 specifies DNS-over-TLS should use ’TLS 1.2 or later’ so giving context seems useful. 

> This seems like another general TLS/fingerprinting issue not specific to DNS,

The paper cited is a well-known analysis titled “Pretty Bad Privacy: Pitfalls of DNS Encryption”. One of the things it shows is that even if traffic _to_ a recursive resolver is encrypted, if the traffic is not padded it can be combined with capture of unencrypted upstream traffic to infer the content of the encrypted query. It was a motivating factor in developing both RFC7830 and RFC8467.

> > Recursive Resolvers see all the traffic since there is typically no

[RFC7626] This is is true but I agree it could be better worded. Suggest: "In the common case of end users sending DNS queries (encrypted or not) to a recursive resolver, then that resolver is highly likely to see all the traffic from the users because there is typically little or no caching between stubs and recursive resolvers."

> This is not a privacy concern, but rather a more vague one about

As many other comments have noted, privacy and centralisation are linked concerns. 

> "privacy considerations for end users" dependent on several more parties.

suggest: “s/for end users are highly dependent /for end users are additionally highly dependent/"

> I am not sure this 2012 paper is relevant here.

If you feel strongly please suggest an alternative reference. 

> > At the time of writing, efforts to provide standardized signaling mechanisms
> > to discover the services
> 
> It's not clear that this is possible in a meaningful way. Suggest striking, as
> the text is speculative.

The document outlines a fundamental limitation of the current use of encrypted transports. Highlighting active work (i.e. work that has been adopted by an IETF working group) seems useful.

> > publishing DNS privacy polices, for example see the Encrypted DNS Deployment
> > Initiative [EDDI].
> 

Suggest: “Note that an increasing numbers of ISPs are deploying encrypted DNS, for example, see the Encrypted DNS Deployment Initiative [EDDI]."

> applies to Operating Systems.

This overlaps with the similar discussion with Ekr on OS vs Application. Note that TentaDNS, Yandex and Firefox and others all support application-specific DNS resolver selection today. The document previously had reference to some of these but they were removed during the most recent round of reviews. 

> However, I believe it describes general security and privacy concerns that are
> > In addition, if the client is compromised, the attacker can replace the DNS

An equivalent section existed in RFC7626. A reference to dnswasher (a DNS specific case of compromising a client) was previously in this section but was removed in the previous rounds of review. 

> does the text about RFC7754 have to do with privacy?

This section states: “User privacy can also be at risk if there is blocking (by local
   network operators or more general mechanisms) of access to remote
   recursive servers that offer encrypted transports when the local
   resolver does not offer encryption and/or has very poor privacy
   policies."

> I don't think this is correct in a general enough way to be written like this.

This is correct when comparing the data exposed to a resolver via UDP and TCP.

> additional metadata locations to consider in comparison to DNS over UDP, TCP 
> or TLS [RFC7858]”.

> Reasoning: any data in an HTTP header can also be placed in a TLS extension.

The more general point here is that the HTTP standard introduces new metadata (not just locations) that does not exist in the standards for the other transports.

> No, these are all present in TLS as well, but it's true that HTTP headers are

All the above text is lifted directly from RFC8484.  

> 
> > At the extremes, there may be implementations that attempt to achieve parity
> > with DoT
> 
> Not a justified use of "parity”.

Why not? DoH is effectively a delta on top of DoT.

> That wouldn't actually do the trick. TLS ClientHello messages are also easily
> fingerprinted.

I can reference the Mozilla bug ticket where this is discussed if you like.
Also just because other risks might exist doesn’t mean we shouldn't document and try to mitigate all the risks.  

> > Privacy focused users ...

The rest of this sentence makes a specific comparison between DoT and DoH.

> > Also, the end user typically has some legal/contractual link with the

[RFC7626] s/typically/often/ and the text goes on to give specific examples.

> 
> In general, I'm not sure this section provides much useful analysis, but this:
> 
> seems to conflict with other parts of the document that claim encryption leads

Suggest: “ you can gather a lot of information including the content of DNS queries."

Regards

Sara.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Jan 2020 22:33:11 -0800

> Thank you for your detailed 45 point review of this document during the

Thank you. Although I am not satisfied with most of the responses, and I
believe the document is technically misleading, I believe it meets IETF
standards.

thanks,
Rob