Subject: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

From: Tim Wicinski <[email-masked]>
Date: Fri, 16 Aug 2019 07:49:24 -0400

This starts a Working Group Last Call for draft-ietf-dprive-rfc7626-bis

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

The Current Intended Status of this document is: Informational

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  30
August 2019

thanks
tim

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 19 Aug 2019 14:58:16 +0200

Hello,

I now read through the whole document, and I see one thing that might be
a little bit confusing - the beginning of page three reads like QNAME
minimization is not possible or at least never done, and contrary to
rfc7626 itself it isn't even mentioned in the whole document.  I would
suggest to at least reduce the strength of the wording ("always"),
and/or mention rfc7816.  I don't have much data at hand, but I believe
that some reduction of QNAMEs isn't as exotic as it used to be.

Then there's a problem with many dead links, which would be nice to
improve somehow:
[sidn-entrada] [grangeia.snooping] [pitfalls-of-dns-encrption]
[packetq-list] [morecowbell].
[packetq] redirects OK to the new location, but perhaps it would be
better to link it (more) directly.

--Vladimir

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 21 Aug 2019 18:21:56 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Vladimír
> Cunát
> Sent: Monday, August 19, 2019 8:58 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-
> dprive-rfc7626-bis
>
> Hello,
>
> I now read through the whole document, and I see one thing that might be a
> little bit confusing - the beginning of page three reads like QNAME
> suggest to at least reduce the strength of the wording ("always"), and/or
> mention rfc7816.  I don't have much data at hand, but I believe that some
> reduction of QNAMEs isn't as exotic as it used to be.

Agreed, and I'll suggest a sentence (enclosed by **) for the end of the third paragraph of the Introduction:

"It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question.  The question sent to the root name servers is "What are the AAAA records for www.example.com?", not "What are the name servers of .com?".  By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server. **In this simplified description, recursive resolvers do not implement QNAME minimization as described in RFC 7816 [RFC7816], which will only send the relevant part of the question to the upstream name server.**"

It may be more desirable to reference 7816bis, but that would add an Internet-Draft reference dependency that folks might not want to add.

Scott

---

From: Geoff Huston <[email-masked]>
Date: Wed, 21 Aug 2019 19:46:13 +0000

> On 19 Aug 2019, at 10:58 pm, Vladimír Čunát <[email-masked]> wrote:
> 
> Hello,
> 

A recent measurement of the use of Qname minimisation can be found at:

   http://www.potaroo.net/ispcol/2019-08/qmin.html

tl;dr: A 3% of users were observed to use recursive resolvers that perform
qname minimisation in the Internet. Far higher levels of use of qname
minimisation are found in some national communities.

I have no idea if a use level of 3% of users is “exotic” or not.

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 23 Aug 2019 17:56:02 +0100

> On 19 Aug 2019, at 13:58, Vladimír Čunát <[email-masked]> wrote:
> 
> Hello,
> 

Thanks for catching that oversight, the document should be updated to reference RFC7816, which didn’t exist when the first version was published!

> better to link it (more) directly.

Agreed - these all need careful review.

Regards

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 23 Aug 2019 17:56:37 +0100

> On 21 Aug 2019, at 19:21, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 
> "It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question.  The question sent to the root name servers is "What are the AAAA records for www.example.com?", not "What are the name servers of .com?".  By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server. **In this simplified description, recursive resolvers do not implement QNAME minimization as described in RFC 7816 [RFC7816], which will only send the relevant part of the question to the upstream name server.**”

Thanks very much for this text. I’m wondering about also referencing this study:
https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation <https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation>
which attempts to asses the deployment of QNAME minimisation to show it is actually being deployed in the wild? 

> It may be more desirable to reference 7816bis, but that would add an Internet-Draft reference dependency that folks might not want to add.

Good point. I’d prefer to just reference RFC7816 unless anyone objects…

Sara.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 23 Aug 2019 17:45:27 +0000

From: Sara Dickinson <[email-masked]>
Sent: Friday, August 23, 2019 12:57 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

   On 21 Aug 2019, at 19:21, Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>> wrote:

      -----Original Message-----
      From: dns-privacy <[email-masked]<mailto:[email-masked]>> On Behalf Of Vladimír
      Cunát
      Sent: Monday, August 19, 2019 8:58 AM
      To: [email-masked]<mailto:[email-masked]>
      Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-
      dprive-rfc7626-bis

      Hello,

   "It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question.  The question sent to the root name servers is "What are the AAAA records for www.example.com<http://www.example.com>?", not "What are the name servers of .com?".  By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server. **In this simplified description, recursive resolvers do not implement QNAME minimization as described in RFC 7816 [RFC7816], which will only send the relevant part of the question to the upstream name server.**”

   https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation

   [SAH] That seems reasonable.

   [SAH] A reference to 7816 is reasonable assuming that there’s little risk of significant specification deviation between it and 7816bis. That’s probably a reasonable assumption.

   Scott

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 26 Aug 2019 15:38:44 +0200 (CEST)

Il 16 agosto 2019 13:49 Tim Wicinski <[email-masked]> ha scritto:

If someone feels the document is *not* ready for publication, please speak out with your reasons.

Here are my comments after going through the document. I think it still needs further work, reflecting how the discussion on DNS privacy has advanced since the original draft was written. I am not providing text yet but I am happy to work on it if useful.

- On section 2.1: I think the DNS today holds a considerable amount of "data" (not necessarily personal information, but the section seems to deal with data in general) that are not meant to be "public"; this is only hinted at with a short, non-exhaustive incidental ("access control lists and private namespaces notwithstanding"), and only for authoritatives.

The reality is that recursors also have "DNS data" which is not meant to be known to the public and goes beyond private namespaces; for example, different replies for public names, to be given to specific clients (e.g. identified by network of origin or by some kind of client detection mechanism). This data might be sensitive, both in terms of security (it might help attackers from the outside if disclosed) and in terms of privacy (e.g. if I configured my resolver to block certain categories of websites, both the list of blocked websites and the fact that I block them can be confidential).

I am not completely sure of the intended meaning of this section and why it fits here, given that all the other 2.x sections are a catalogue of risks, but an expanded mention of the fact above would make sense.

- On section 2.4.2: this is an abstract discussion of privacy risks in encrypted transports, but then I would have expected to find here all the well known considerations on the additional privacy risks that are created by the use of specific transports and especially HTTPS: the potential (although denied in the standard) use of HTTP cookies, the fact that even without cookies well known and readily available techniques for fingerprinting and tracking exist, the risk of easy correlation between HTTPS requests that bear DNS payload and other HTTPS requests, etc.

I did not find anything, but then I found 2.5.1.2, so I thought that perhaps the intention was to use 2.4 to deal only with cases in which third parties break the encrypted protocol, and defer the rest to 2.5.1; still, 2.5.1 is about the risks deriving by resolver behaviour, but some of the issues are tied to potential cooperation between the client and the resolver to track the user, or attack opportunities that are facilitated by inappropriate client implementations (e.g. a DoH client that added too many headers and made fingerprinting very easy), so these look to me more like issues connected to the protocol, than to the resolver side only.

Also I don't particularly like framing this as "DoT vs DoH" - it would make more sense to me to have (in 2.4.2?) two separate sub-sections, one per each encrypted protocol, describing the risks of each of the two. I would rather leave 2.5.1 for a discussion of risks specific to the choice of recursive resolver and to its behaviour - this leads me into the next point.

- On section 2.5.1 but also in general: I think the discussion in the few last months has identified the centralization of DNS queries onto a few resolvers as a big risk for DNS privacy, perhaps the biggest one in the near future - yet I cannot find this discussion anywhere in the document. This risk should be mentioned in the introductory parts already, and then it should be discussed in detail, possibly here, examining the potential for centralization that each protocol has, and the privacy risks of the various deployment models.

- On section 2.5.3: I find the section as currently written quite problematic. In practice, it seems mostly focused on bashing DHCP as a way of configuring networks, but it also seems to suggest that the various techniques mentioned in the paragraph ("divert traffic by providing lies for some domain names", "transparent DNS proxies in the network that will divert the traffic intended for a legitimate DNS server"), which are common network administration and service provision techniques for entirely legitimate reasons, are necessarily associated with "rogue servers". On the other hand, there is only a small hint at the end (and only associated with "malware") that not just the network, but applications on your device might monitor or redirect your DNS traffic.

So I would rewrite the section completely, and I would make it about the basic privacy risk, which is having the user's DNS data go (or be copied) to a server that is not the one that the user has entrusted with their personal information. This server is "rogue" from the user's viewpoint, but it could be a perfectly reputable and legitimate resolver, just not the one the user wanted; this is why I also do not like the term "rogue", which seems to suggest a hidden server run by black hats.

Any way of changing the user's resolver preference - be it done by the network or by applications - creates a privacy breach, unless it has been authorized by the user or is allowed by applicable legislation (e.g. for network security reasons). This should be the main point of the section.

- On section 2.5.5: this is also problematic. First of all, it's not an attack on servers but on the transport, and it applies potentially to any transport and not just encrypted ones, so it should go in 2.4, unless you want to treat it like a particular case of 2.5.3 which leads you to adopt a different resolver not by intercepting packets but by depriving you of alternatives.

Then, there should be a recognition that there might be plenty of valid reasons for blocking access to remote resolvers (e.g. network security needs) that could outweigh the risk to privacy, which is anyway optional (it only exists if the user actually does not trust any of the "allowed" resolvers and specifically wants one of the blocked ones).

Moreover, there should also be a discussion of the symmetric risk, i.e. your device, application or operating system blocking access to resolvers you might want to use, for example by disallowing you from choosing them in their configuration, leading you to adopt other resolvers which you do not trust in terms of privacy.

- On section 2.6: it is interesting and useful but feels a bit out of context. As it is connected to the risk of correlating DNS queries with data from other sources, could it perhaps fit in the discussion on DNS centralization?

Apologies for the long message, and I'm happy to work with the authors to address my comments.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Rob Sayre <[email-masked]>
Date: Tue, 27 Aug 2019 20:24:16 -0700

On Wed, Aug 21, 2019 at 11:22 AM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> > I now read through the whole document,
>

 I read the whole thing too, and I am confused about three issues.

1) What is the scale of the entire system? As the document states, the
system makes heavy use of caching. But, the queries are simple, so even a
cache miss should be cheap. The traffic to the root servers would seem to
be quite a bit smaller than just Twitter's RPC traffic, going by <
https://www.akamai.com/us/en/why-akamai/dns-trends-and-traffic.jsp>. To me,
this scale calls into question the extent to which queries need to be
cacheable across requests. I can understand why decisions around these
trade-offs might have been made 20-30 years ago, but it's not clear that
those decisions will remain valid forever.

2) The document states "Some encryption solutions are only designed for
TCP, not UDP." This statement seems a bit imprecise. For example, how does <
https://datatracker.ietf.org/doc/draft-ietf-quic-tls/> fit into this
description?

3) While it's clear the document is focused on the privacy (or,
confidentiality) properties of encrypted transports, and the privacy
implications of the data included in the queries themselves, there seems to
be missing text about the message integrity that encrypted transports
provide.

thanks,
Rob