On Wed, Jul 09, 2008 at 05:36:02PM +0100, Ben Laurie wrote: > Paul Hoffman wrote: >> First off, big props to Dan for getting this problem fixed in a >> responsible manner. If there were widespread real attacks first, it would >> take forever to get fixes out into the field. >> However, we in the security circles don't need to spread the "Kaminsky >> finds" meme. Take a look at >> <http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/>. >> The first draft of this openly-published document was in January 2007. It >> is now in WG last call. >> The take-away here is not that "Dan didn't discover the problem", but "Dan >> got it fixed". An alternate take-away is that IETF BCPs don't make nearly >> as much difference as a diligent security expert with a good name. > > Guess you need to tell Dan that - he seems to think he did discover it.
Taking a brief look at what changed in bind, it seems primarily to involve randomizing the query port, matching both the port and transaction id instead of just the id, and using RC4 to generate the transactions ids instead of a pair of very sketchy-looking (cryptographically speaking) RNGs based on an LCRNG design via Knuth. Perhaps there is something subtle here that is more dangerous than the well known problems, and all these source port randomization and transaction id randomization fixes are just a smokescreen of sorts for a fix for something Dan found. Securosis claims [1] "The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches", and Dan claims something similar, offering to share the stage at Defcon with anyone who finds the bug [2] A statement from the MaraDNS author [3]: """ MaraDNS is immune to the new cache poisoning attack. MaraDNS has always been immune to this attack. Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago. The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun). """ (But CERT has no reply in their advisory from MaraDNS, so I'm not sure if this statement was made on the basis of just what is publically known, or if he was in fact in on the vendor notify list). -Jack [1] http://securosis.com/2008/07/08/dan-kaminsky-discovers-fundamental-issue-in-dns-massive-multivendor-patch-released/ [2] http://www.doxpara.com/?p=1162 [3] http://marc.info/?l=maradns-list&m=121560639013865&w=2 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
