Il 16 agosto 2019 13:49 Tim Wicinski <[email protected]> ha scritto:
This starts a Working Group Last Call for draft-ietf-dprive-rfc7626-bis
Current versions of the draft is available here:
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.
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 protected]
Office @ Via Treviso 12, 10144 Torino, Italy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
