Very well said. +Lots. On Oct 22, 2014, at 4:19 PM, Ted Hardie <[email protected]<mailto:[email protected]>> wrote:
On Mon, Oct 20, 2014 at 6:10 PM, Paul Vixie <[email protected]<mailto:[email protected]>> wrote: query minimization i see no benefit or need for secrecy since dns is a publication system -- if you don't want people to see your information, don't put it into the dns. cache miss transactions (#2 above) expose only server IP addresses, not end-user IP addresses, and no re-use events. as such it has always been my position that there is no PII and no privacy impact from having these recorded and analyzed. i would not like to see the IETF work in that area.ld be classified into: At the STRINT workshop, we discussed the extent to which combining queries at a proxy provides protection against analysis by a monitor. It is certainly the case that it provides some benefit, but we there are limits, especially when the resolver serves a relatively small number of users. To take an example: Joe belongs a club, example.org<http://example.org/>, and is using their network to look up a sensitiveblog.journal.example. example.org<http://example.org/> hosts it own DNS resolver, but few users connect to journal.example (having mostly moved to face-example.org<http://face-example.org/>), so when Joe makes his look up, it's a cache miss. A surveillance entity will therefore see sensitiveblog.journal.example as a target of the DNS query if it has a tap on path between example.org<http://example.org/> and journal.example, and it now knows that the traffic between example.org<http://example.org/> and journal.example is for the senstiveblog. Note that it would not necessarily have known that otherwise. Because journal.example uses the HOST header to disambiguate traffic to different hosted journals, thus consuming a very small number of IP addresses, the connection itself would not have identified which blog was at issue. [There are other potential sources of leaks, here, such as the unencrypted SNI in TLS, but that has to be worked elsewhere. I do not personally accept the idea that we can't fix information leakage piece by piece, just because other leaks are possible]. Clearly, had Joe used OpenDNS, Google's DNS, or a large ISP DNS service which aggregates many more users, the chance of a cache miss would be lower and the correlation would be much, much harder even in the case of a cache miss. But the DNS protocol cannot presume that sort of deployment, and they have other consequences in terms of trust between users and large services. As long as the DNS continues to support deployment of recursive resolvers in topologies that cannot effectively provide aggregation as a mitigation, I believe that the recursive to authoritative problem should stay on the table. It is a lower priority, but it is a valuable piece of work. I personally also think that it is a substantially different problem from the stub to recursive resolver problem, so we should treat them independently. My two cents, in any case. Ted Hardie _______________________________________________ dns-privacy mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
