I dont like to be negative, but the padding solution seems to me to either cause potentially undue harm and or wasted effort, and/or do very little to address confidentiality ...
Assume that stub to iterative resolver communications are confidential and that iterative to authoritative communications remain unchanged (clear text). Each cache miss, in which the interative resolver needs to query authoritative resolvers to answer the query, exposes the fact that some member of the community is interested in the cache miss domain. If the iterative resolver generates additional 'cache miss' queries in which it attempts to obscure the 'real' ones this would seem to hide real ones amongst the 'fake' ones. Unfortunately, this does not really help. Yes, it obscures for cases where the watcher is trying to analyse patterns in all queries, but does nothing when all they are interested in is finding specific queries. You can add all the padding you like, but the query to intersting.tld will still show up. As the iterative resolver needs some way to decide how to choose what its 'fake' cache miss queries will be, it could choose domains that some watcher is interested in (interesting.tld) when that query has not been requested by any client. Thus, the watcher may become interested in the client community when that 'interest' is misled. Indeed, one might end up being charged with 'misleading law enforcement' or some equivalent. What 'interesting.tld' is for one watcher agency may be benign for the next, and vice versa. Thus, the iterative resolver needs to understand politics in order to not induce undue surveillance upon its clients. To solve this, the iterative resolver must only use 'fake' queries which correspond to real queries which have an expired TTL. Thus, the iterative resolver's ability to generate fake queries is regulated by the TTLs of the domains which it has queried (race to the bottom?), and all it is doing is obscuring the *frequency* of the cache miss queries. Or one could have a known set of benign domains which are used for padding. In which case the watchers just filter this out and you are back to where you started. Essentially, all of the above calls for a Threat Model in these discussions. Regards, -- Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk GPG: https://keys.env.dtu.dk/hugo-connery/email/valid-to-2015-04-15/Hugo-Connery.public-key.txt ________________________________________ From: dns-privacy [[email protected]] on behalf of Stephen Farrell [[email protected]] Sent: Thursday, 23 October 2014 14:08 To: [email protected] Subject: [dns-privacy] Padding (Was: Re: Confidentiality from Iterative to Authoritative resolvers.) I think the answer to this question may be a simple "no, don't" but it if were not, it might be something that'd improve privacy for both stub<->recursive and recursive<->authoritative without changes to the DNS, but probably requiring some new protocol to run alongside. Anyway... On 23/10/14 12:36, Hugo Maxwell Connery wrote: > DNS information is clearly public information. But that > does not mean that one needs to publish *who* is accessing > that public data. Another way in which one could conceivably do that is by issuing bogus requests, (i.e. padding) which attempts to mask not who is asking but which answers are of interest. That wouldn't have to be a case of sending queries for randomly generated names, but could be based on some form of gossip between a bunch of e.g. recursives or something. So the bogus request that one sends out might actually be for a domain that was a real request from another gossipy recursive a while ago. I suspect that there's not much to be gained by doing that in the end, and it'd clearly have costs, (though with gossiping one might limit those by getting a lot of cache hits) but I wonder if anyone has looked at this kind of thing in detail already? A v. quick search didn't turn up that much, though [1] seems to be proposing something along these lines. Cheers, S. [1] Federrath, Hannes, et al. "Privacy-preserving DNS: analysis of broadcast, range queries and mix-based protection methods." Computer Security–ESORICS 2011. Springer Berlin Heidelberg, 2011. 665-683. http://202.154.59.182/mfile/files/Information%20System/Computer%20Security%20-%2016th%20ESORICS%202011/Chapter%2036%20Privacy-Preserving%20DNS%3B%20Analysis%20of%20Broadcast,%20Range%20Queries%20and%20Mix-Based%20Protection%20Methods.pdf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
