On Mar 1, 2012, at 7:59 AM, John R Levine wrote: >> It is the caching of non-asked-for data, be it Auth, Additional, CNAME >> chains, etc, which enables race-until-win attacks like the Kaminski attack. >> >> Thus a resolver MUST NEVER cache data that wasn't specifically asked for if >> it can't DNSSEC validate this information. It can use the additional data >> received to indicate that it SHOULD ask for the information, but it >> shouldn't ever cache it in a general context. >> >> Or, if it does cache it, it should validate that the entry would be valid by >> performing an independent lookup, a'la Unbound and replace the information >> with the new version. > > This makes no sense. Assuming you ignore records for which the server isn't > authoritative (which we all do since Kashpureff), why wouldn't you use the > records in the additional section? > > Or to put it another way, if you're worried that the authoritative additional > records are fake, why aren't the authoritative answer records equally fake? > Same server, same authority.
Because caching un-asked-for records is what allows "race until win": the ability of an attacker implementing blind cache poisoning to keep retrying the attack until successful. If only the requested information is cached, an attacker targeting "www.victim.com" can only try to poison once per TTL, because after that, the resolver doesn't generate queries. But if ANY sort of authoritatitive or additional information is cached unasked-for and unverified with a second request (INCLUDING the NS RRSET from the authoritative field), the attacker can start with "1.victim.com", with the additional information containing the poisoned record for "www.victim.com". If success? Great. If failure? Retry with "2.victim.com" and so-on. Even with halfway-decent port randomization, Race Until Win can be a problem: Poison the NS entry for .com on a major resolver using your botnet and, ohh, boy, can an attacker have some fun. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
