Paul Vixie Responds To DNS Hole Skeptics 147
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.'"
Re:I'm not worried (Score:5, Interesting)
stability (Score:1, Interesting)
Re:The back-biting is shameful (Score:5, Interesting)
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.
Re:Unfortunately, what else is new? (Score:2, Interesting)
Not exactly.
This flaw was well known in 1990. Paul Vixie has been dragging his feet for almost twenty years with crack-potted shit like "additional credibility rules" and extra complexity.
How to fix this bug trivially was well known over ten years ago [cr.yp.to] and still the ISC has been refusing to secure its users because they want to push DNS-SEC- a security system based on a trust hierarchy that doesn't exist, whose implementation has never worked, and will never work because Paul is a fucking idiot who cares more about his own ego than just admitting he was wrong and learning to live with it.
Look even now:
He can't help himself. He's a douchebag, and I hope he just leaves the Internet business forever. We'd all be much better for it.
Re:Small business setups NOT protected by the patc (Score:3, Interesting)
Not so simple. (Score:2, Interesting)
Only if you have a method for authenticating the other side of the phone conversation.
Re:The back-biting is shameful (Score:4, Interesting)
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.
Re:The back-biting is shameful (Score:4, Interesting)
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.
Re:Unfortunately, what else is new? (Score:4, Interesting)
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.
Re:What is Secure DNS (Score:4, Interesting)
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 [cr.yp.to]; 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.)
Re:The back-biting is shameful (Score:3, Interesting)
OK... How bad? "Real bad" doesn't really help me at all. To make an informed decision I need to know four things:
#1 is making my firewall basically wide open to UDP. #2 is cache poisoning. Without knowing more about Kaminsky's attack, I can't really make any useful guesses about #3 and #4.
For now I've allocated a sub-range of non-privileged UDP ports that I can guarantee won't be used by other processes, and relaxed the firewall to allow BIND to use those ports. According to the dig test posted in TFA's comment section my server's security is still "POOR", so apparently 8000 ports (~13 bits of entropy) isn't enough. According to Kaminsky and Vixie 64000 ports (~16 bits) would be enough. WTF? Enough for what? I need a better explanation of what's really going on here before I can feel like I'm making an improvement by opening up the UDP firewall completely.
Still not knowing anything I get the feeling (and I'd rather not have to rely on vague feelings or opaque assurances) that there must be a way to detect and mitigate cache poisoning attacks, rather than just increasing the cost of a brute-force attack by factor of some small power of two through a slight increase in unpredictability.