Slashdot Mirror
Paul Vixie Responds To DNS Hole Skeptics
syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"
That's really hard on web servers that host multiple domains on a single IP. Virtual hosting isn't exactly a new idea.
This issue may be huge. But without all the necessary information, you can't make an informed decision as to whether or not you believe it is.
That same information that allows you to make an "informed decision", as you so blithely put it, puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk. Dammit, that's the whole point of the OP's observation and why people argue about disclosure in the first place.
Vixie claims that "Everything we thought we knew was wrong", but at the same time, we know that there are DNS systems and services that did not have this vulnerability, so obviously some people had already given this type of issue some thought.
No. Not all dns systems/services may be vulnerable, but this might not be because of forethought but rather a different design paradigm (buzzword alert, I know). They might just have been designed differently for other reasons, and non-vulnerability to this exact flaw may be a side-effect.
Not in this case, in this case seeing the source changes doesn't really help, it's more like a protocol-design-flaw. And the bugfix is just a workaround.
New things are always on the horizon
Secure DNS makes this kind of impersonation impossible
Mmm, no. It makes this kind of impersonation possible by anyone who can coerce/corrupt/control some part of the chain of trust.
outside the standards committees which have served the Internet well for 30 years.
Actually, on the topic of security and cryptography, I'd say the standards committees have failed the internet pretty badly. The apparent fixation with providing Verisign with revenue streams has gotten in the way of designing acceptable trust systems.
The only result that the fixation with certificates and authorities has gotten us is a situation wherein everyone is becoming their own authority and nobody cares about certificate warnings anymore.
If one wanted to repair the systematic damage by now, the best way would be to simply scrap the CA's out of browsers and anywhere else and just add a way to easily add specific CA's for each new domain/service provider one comes in contact with.
Unfortunately, as Vixie admits, DNSSEC has intractable problems and is... well, let's be generous and say "pushed too quickly through the standards process". (See http://cr.yp.to./djbdns/forgery.html; in particular, Vixie's observation 'We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ...' [this was _after_ several DNSSEC RFCs were approved and intended to be implemented were shown to be utter crap.])
Encouraging people to use DNSSEC is just about as useful as encouraging people to use HOSTS.TXT. OK, I exaggerate a bit, but it's simply not going to solve the problem, is going to expose zones to arbitrary enumeration (remember, The Internet community discouraged answering AXFR requests from the Internet at large presumably for a reason), and is going to introduce much larger computational demands of DNS servers that implement it.
(Here's a thought: most of this forgery comes from my ability to guess your DNS cache / resolver's query port and request ID. Come IPv6, we could surely add 48+ bits of entropy to the process by having DNS servers listen on a prefix of addresses. Much simpler, if gross.)
Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1