On 15-Feb-2009, at 2:26 AM, Aaron Hopkins wrote: > > Cache snooping lets anyone see who you've been talking to, when you > looked > it up, and when the cache will expire. This can aid many different > attacks; > for a cliched example, would you knowingly publish a list of which > financial > institutions your users are logged into at any given time? Can you > see how > doing so might aid social engineering, phishing, or cross-site- > scripting > attacks? I'm not convinced making some tiny form of this information available from the local DNS cache is of any more value to an attacker than the myriad of other ways they can learn the same information. Perhaps if attackers have time machines and they can go back to the moment just before the user triggered a connection to some site of interest then I might be more worried? Most importantly I will claim for the moment that these kinds of attacks cannot be eliminated by simply preventing cache snooping. They are indicative of flaws in other areas and while they may be mitigated slightly in the near term by preventing cache snooping, they can only be prevented by correcting other flaws. > It also complicates the end-user experience. If someone hardcodes > my DNS > servers into their machine and moves off of my network, lookups of > popular, > cached RRs will mostly work and other lookups will mysteriously fail, > perhaps a week in the future after they've forgotten what they've > done. It > seems much more clear to just have nothing work until they fix their > config. I'm not really concerned at all about such issues. Perhaps it is sad for me to say so, but they are inevitably someone else's problem, not mine. > The fact that it is in a cache or not and when it was retrieved is the > sensitive data, not the public data that was retrieved. That information is not really any more sensitive than anything else done on a _public_ network. If anyone can show me any real (i.e. no hand waving or ranting!) attacks where cache snooping is a very important contributor that cannot be replaced by other mechanisms then I'll certainly pay attention. -- Greg A. Woods; Planix, Inc. <woods at planix.ca> -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20090215/6dabdef7/attachment.pgp>