On Sat, Oct 25, 2014 at 8:54 PM, Christian Huitema <[email protected]> wrote: >> Decentralising caches could actually be worse for dns privacy, as your > query no longer stops in the big ISP pool to gain some anonymity, but > instead links straight to you with specific TTLs on your personal cache > expiry/re-fetch timers. > > I have heard this "pooling" argument quite a few time. The idea is that if I > send my requests through a big enough recursive resolver, I gain anonymity > because the reply may be cached, or the request may come from the pool > instead of coming from me. > The problem with the argument is that it expects > privacy to result as a side effect from something else, in that case > caching. But this is a week argument. For example, if the target resource is > rarely accessed, the output to fetch "kinky.example.org" can be easily > correlated with the arrival of an encrypted request to the resolver, and > thus to the original IP address.
A fair bit of this has already been discussed (including an onion style solution) - see http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00054.html as an example. In order to develop a deployable solution we will have to make some compromises -- if the recursive server is busy, is not part of a pool, and "kinky.example.org" is not in the cache, you still get some protection - a busy recursive has some set of outstanding queries, and is handling a number of clients - correlating your incoming packet with a request for "kinky.example.org" is believed to be somewhat non-trivial. > This is even more true if the target DNS > name is set with a short TTL. > > Compare that to onion routers like Tor that are specifically engineered for > privacy, and which do not rely on side effects. If I wanted to hide my > footprints, I would have much more trust in something engineered for privacy > than on an hypothetical side effect. So, if really care about hiding > requests, then maybe we should consider an onion network of DNS resolvers, > of course connected by ecrypted links. Yes, if you really care about hiding your queries then this is an option.... There is even a draft: http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00 > Or maybe use DNS over HTTPS over Tor. ...as is this. Or DNS over HTTPS over Tor over a VPN and a proxy. It all depends on what *your* threat model is, and what tradeoffs you are willing to make. One of the things that we are focusing on is a deployable solution, preferably one that resolver operators can roll out on their own. If the solution is overly complex, takes too long to develop, or add significant latency then it is not as likely to be deployed, or will take a really long time to be deployed - during which time we are leaving lots of users with their queries in the clear. We need to be careful to avoid falling into the perfect being the enemy of the good trap... I'd rather see a deployed solution that protects 99.99% of queries that gets deployed than a 100% solution that never gets implemented. “Give them the third best to go on with; the second best comes too late, the best never comes.” - Sir Robert Alexander Watson-Watt's "cult of the imperfect". This refers to the radar solution that he helped develop for England, and the fact that it could have gotten higher resolution / performance with a higher frequency... but would have taken much longer to get developed... W > > > -- Christian Huitema > > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
