On Thu, Oct 23, 2014 at 8:08 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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 isn't what I would call padding. Increasing the length of genuine request packets to resist traffic analysis has a lot less cost than generating spurious traffic. Yes, I might do that sort of thing in an application designed for people who are surveillance targets but the cost/benefit really does not justify generating traffic noise as a general rule. In Private-DNS I support padding to obfuscate traffic analysis based on the length of a request because this can actually leak rather too much information. So for example, consider the case in which someone is going to www.cnn.com, or www.bbc.com or the like. Short domain names are valuable and so most are used by sites that generate a lot of traffic. Folk who are visiting such sites are probably not doing anything unusual. The longer the domain name, the more likely someone is doing something unusual. Padding request packets to a multiple of 64 bytes greatly reduces the value of collecting this data and imposes negligible additional cost. > 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 don't like the idea of makework traffic but one potential benefit of DNSSEC is that such traffic could well become rather useful. > 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? > Back in the early days of the Web there was a project called Harvest that made use of such approaches. That project led to the technology behind Tucows. It also spawned the squid reverse proxy. This was HTTP layer rather than DNS, but the architecture worked fine. This isn't something I would necessarily endorse for general use. But if I have a resolver that gets a request packet from Iran and a cache miss, I might well want to disguise the contact to an authoritative by routing through a sister resolver. But preventing that being spotted would probably require me to be doing enough chatter with the sister for other purposes to hide the traffic. This is one of the reasons I designed Private-DNS the way I did which is as a general purpose layer supporting fast Web Service transactions.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
