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

[Rob Sayre <[e-mail]>]

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 <[e-mail]> wrote:

>
> 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
> [e-mail] mailing lists by 2020-02-03. Exceptionally, comments
> may
> be sent to [e-mail] 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.
>
>
>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>