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.'"
I just remember the IP addresses and type them in myself. How hard is that?
ccalam - acoustic versions of new songs.
this article at information week said it best the day after the announcement.
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
Knowing how to run a system is not purely technical knowledge, it's also a measure of professional ability. That means knowing when to take advice, and knowing who to take it from.
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 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.
"The Domain Name System Security Extensions (DNSSEC) are a suite of IETF specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers):
* Origin authentication of DNS data.
* Data integrity.
* Authenticated denial of existence."
http://en.wikipedia.org/wiki/DNSSEC
All paranoid theories about this issue sort of ignore the fact that unless you plan to install hundreds (or even thousands) of systems from your own compiled source for years and years to come, all of this discussion is at best academic.
The new distros are going to have the patch.
And really, considering the number of prehistoric vulnerabilities that should have been patched, that this one is finally getting patched is fine.
Yeah, there's a bit of "trust me" factor here with this patch, but a lot of good people are putting their credibility on the line for this patch.
All of this whole FOSS thing entails a lot of trust. I mean, you're really telling me that everyone on here whining about the need to see the source code has read every line of code in every OS they're using? There is a level at which we're all sort of hoping that the guys interested in each of the particular parts of the OS have done a thorough job in their separate efforts.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
I heard that this "security fix" is the addition of support for the Evil Bit.
Caesar si viveret, ad remum dareris.
Your mad ad hominem attack skills have convinced everyone that Paul Vixie is the know nothing douchebag in this conversation. Kudos!
Just another reason to make your local DNS forwarder use OpenDNS, or if you don't have one on your LAN, direct your router/workstations to OpenDNS. If your small-business LAN is relying on your provider's DNS, hopefully they patched it. Most worth their salt have, but OpenDNS also provides many features that are useful to small-business (in addition to not having been vulnerable to the flaw).
Randomizing UDP source ports does not solve the problem, it only makes it more difficult to impersonate the responding DNS server. Secure DNS makes this kind of impersonation impossible, or at least allows us to bask in the warm glow of impossible.
The DJB vs BIND thing is an illusion. Whatever everyone agrees is the best implementation should win and I doubt that Paul Vixie or anyone else at ISC thinks differently.
But it has become abundantly clear to me that DJB and his minions (of which I assume you are one) have failed to matter in most ways, not because of your ideas, but because of the brusque, immature manner in which those ideas are submitted for consideration, outside the standards committees which have served the Internet well for 30 years.
You broke my sarcasm meter.
"It doesn't cost enough, and it makes too much sense."
I'm having trouble with Paul Vixies' line:
."
Q: "This is the same attack as described way back in
A: No, it's not.
When Dan Kaminsky states in his blog.
"DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."
and
" 1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?
Only if you have a method for authenticating the other side of the phone conversation.
All of this whole FOSS thing entails a lot of trust. I mean, you're really telling me that everyone on here whining about the need to see the source code has read every line of code in every OS they're using?
There's a specific phrase to describe it, but it escapes me at the moment.
Bascially, when you have a crowd of people standing around watching someone get beat up, nobody steps in to help, because everyone assumes someone else will help.
Verifying source code is somewhat like that: someone else will do it. The great thing about the internet is the crowd is so large that the few people, who would jump in no matter what, are always present.
[Fuck Beta]
o0t!
DNS cache poisoning is a myth cooked up by the liberal media and DNS scientists to implement their anti capitalist agenda.
And if it isn't a myth, then it certainly isn't man made, it's a natural phenomenon and there's nothing we can do about it.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Uh oh, somebody call the whaaaaambulance, we're going to need to perform a humor transplant here!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
In a comment to a question I posted for the CircleID article, Paul Vixie posted a nice and simple test that people can run to see how vulnerable they are:
FAIR or GOOD means you're ok, but POOR (which is the result I got) means you should be worried.
User ID 1352 trollin' it old skool!
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.
You're looking for Diffusion of Responsibility, made famous by the incident in which Kitty Genovese was murdered within earshot of a whole bunch of people, all of whom thought "damnit, someone should do something about this!"
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.
The patch is now in my crontab and set to run on the 6th.
#DeleteChrome
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
If I have to guess, it's because Vixie is associated with ISC, who makes BIND, and is hoping that ISC makes more money with the "ZOMG, run DNSSEC or you're all doomed!". Of course, Vixie has never shown any kind of restraint over DNSSEC, and has previously urged adoption of (prior) broken editions of the protocol that somehow passed muster at the IETF despite not living up to their claims.
DJB may be a meanie, but he seems much more technically competent than Vixie. (I offer as evidence, again, the security records of vixie-cron and bind against djb's utilities, djbdjs, and qmail.) Also DJB seems much more intellectually honest and aware of what's going on. Of course, that's just MHO.
(For more lulz invoving DNS, and proof that it isn't, even with DNSSEC, a trustworthy protocol, see Kaminsky's "suckets" work. Using an adversary-controlled DNS server, it's possible to use the "same origin policy" (which is based on DNS being trustworthy) to achieve arbitrary connections. The correct conclusion is that your naming scheme and authority (DNS) ought not try to say anything about the security properties of the entities it names.)
Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
However, we're past the point of flag days in Secure DNS. A valid configuration today will remain valid in the future. And this time we're finally seeing investment by CCTLDs, and some interest from banks. But we're not going to convince ICANN and/or USG to take the risks and reach for these rewards unless there's a significant installed base. This makes Secure DNS a bit like IPv6 in that there's a significant last-mover advantage. That's why I'm singing this song on slashdot rather than businessweek. New stuff with rough edges and not a lot of immediate benefit has to come to the technical community to get born.
you can't be serious. i resigned as chairman of nominum's board back in 2002 or so. i have no position there. they stopped working on BIND9 at about that same time. let the record show that i am grateful to nominum's then-shareholders for their significant donation of code and effort to BIND9 9.0.0, which went well beyond what ISC paid them for.
it's an educated bet. the restarts to the Secure DNS protocol development effort over the last 13 years have been because we could not find a backward compatible way out of some mess we'd painted ourselves into. in that time EDNS has matured, providing a negotiation framework. in that time, NSEC3 was added, without invalidating any existing endpoint or implementation or data pattern. i really think we're going to be ok.
show me what you're investing your time and effort in that solves the same set of problems better, or solves the truer more underlying problems better, and we'll talk.