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

[Sara Dickinson <[e-mail]>]

Hi Vittorio,

Many thanks for the detailed review - I’ve published an updated -01 version with several changes to hopefully address your comments and the others made during WGLC. 

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

I agree that the scope does need some clarification - the original RFC stated that ‘This document focuses mostly on the study of privacy risks for the end user (the one performing DNS requests).” and after some discussion with the chairs the feeling is that the -bis should retain that level of scope. 

I’ve moved and updated the text from section 2.1 to a new section called Scope to make this much clearer and also separates it from the discussion of specific risks.

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

Actually this section is under the ‘On the wire’ topic and is therefore specifically discussing just the risks posed by a passive observer of the encrypted traffic - I’ve added text to clarify this.

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

I’ve changed the titles here so that the first section more clearly identifies the problems common to both protocols and then the second is for the DoH specific considerations (which on re-reading seems reasonable….) If you know of any risks that exist with DoT that do not exist with DoH then please provide text for that specific section.

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

I’ve added a new section on resolver selection -  section 3.5.1.1. Please review.

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

I take your point on the use of the word rogue here. I’ve changed the title and context of this section to be more specifically just about active attacks from the network - it is now Section 3.5.1.2. Active attacks on resolver configuration.

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

Similarly I’ve re-worked this section to be  Section 3.5.1.3. Blocking of user selected services and for it just to deal with blocking of user selected services from networks that don’t protect user 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? 

I’ve added text to generalise the meaning of observer here because I do think it is a general enough issue to have a standalone section. 

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

I hope the changes address most of your concerns - please review and let me know.

Best regards

Sara.