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.'"
So, you figure eighty vendors coordinated a simultaneous patch for some issue that is not really a big deal, probably just some guys vying for attention?
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
I don't want "irresponsible disclosure". I don't want to be vulnerable, while major corporations get to do marketing damage control. They had a hole. Ok, everyone makes mistakes. They found the hole. Great, then we can do something about it. Or not, because they kept quiet about it while secretly writing the fixes. They kept quiet about it for long enough that even Microsoft had fixes ready.
you have to trust the experts when they say "it's new and it's bad"
OK... How bad? "Real bad" doesn't really help me at all. To make an informed decision I need to know four things:
Cost of patching
Cost of failure due to not patching
Probability of failure due to not patching
Probability of failure in spite of patching
#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.
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.
That same information... puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk.
Extremist talk and dire predictions are great, but where have they gotten us in the past? 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.
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.
Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)
Sure you would; and the blame for any damage would be blamed on who made the disclosure.
There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.
Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)
Sure you would; and the blame for any damage would be blamed on who made the disclosure.
There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.
Except Microsoft doesn't handle things this way. If this had been only a Windows issue we would have never heard about it. The fact that Open Source is vulnerable as well means that we will eventually know what the problems were and be able to look to see that it was fixed in the Open Source versions.
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.
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.
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.
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.
You're looking for Diffusion of Responsibility [wikipedia.org], 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!"
Q: "This is the same attack as described way back in."
A: No, it's not.
When Dan Kaminsky states in his blog. [doxpara.com]
"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?
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?
You are looking at two separate issues. The flaw Kaminsky found is apparently a newly discovered design flaw that makes DNS forging easy even with todays, unpatched DNS servers. In the advisory, they discussed previous problems with generating the transactionID to explain the problem and point out that what Dan found is not something already known (alot of people missed that very obvious point).
The second seperate, issue is UDP source port randomization. That is what Kaminsky was referring to DJB's solution. Kaminsky's assertion is that UDP source port is a good development practice which DJB incorporated into his DNS server.
Bear in mind that UDP source port generation doesn't solve the underlying problem, it simply makes blind DNS forging more difficult because now an attacker has to guess both a pseudo random transaction ID and a pseudo random UDP source port number. Alot of DNS servers and OS, simply picked source port numbers incrementally or in the case of a DNS server, re-used the some one over and over.
I don't know hom much more difficult DNS forging will be by randomizing the UDP source port numbers. The additional keyspace is (2^16-1023) and you can probably divide that in half again. But it's better then nothing and probably provides enough time (the time it would take an attacker to blindly guess the transactionID and UDP source port number) for the actual response to hit the DNS server. In DNS, the first response wins.
DJB's source port randomization makes it much much harder to exploit the main bug, which is apparently a fundamental flaw in the DNS. We'll know on the 7th what that flaw is, but until DNSSEC or something similar is implemented, source port randomization will mitigate the risk until such time that the root cause is fixed.
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:
dig porttest.dns-oarc.net in txt
FAIR or GOOD means you're ok, but POOR (which is the result I got) means you should be worried.
Many older named.conf configs have "query-source port 53;". While this is nice for firewalls to open up DNS traffic (assuming replies from source udp/53 to destination udp/53 (your query port) are always safe), it makes it easy to exploit.
This must be removed and those nameserver restarted. I had to do this with all of my servers, otherwise all queries come from the same port (53). Complain to your ISP if you find this to be the case with their DNS servers and in the meantime use some other DNS servers.
My two local Comcast resolves show "Poor" as the ports they use only have a standard deviation of 130-150, which I guess is assumed to be far too obvious and easy to keep bombarding.
Second, your NAT router may be de-randomizing your DNS queries if you run a resolver at home, and taking your random ports and putting them in order starting at 1024 (or something similar).
My own local/internal DNS servers shows as a std dev of 9 since my PAT router is de-randomizing the external ports. I'll be replacing my PAT router.
Third, your NAT router may be your DNS resolver and may not be using random source ports.
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 mor
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.
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.
by Anonymous Coward
on Tuesday July 15 2008, @07:51AM (#24194371)
"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."
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.)
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 securit
It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).
If you visit Dan Kaminsky's blog [doxpara.com], there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.
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).
I'm not worried (Score:5, Funny)
Re:I'm not worried (Score:5, Interesting)
Parent
Re:I'm not worried (Score:5, Funny)
Why is that hard? Still works with IP-addresses. The only thing you need to do is to supply the Host-field as per HTTP/1.1.
Parent
Re:I'm not worried (Score:5, Funny)
That's why 'smart' people use /etc/hosts. That solves the problem of remembering and of the HTTP-host-header.
Parent
Re: (Score:2)
Re: (Score:3, Informative)
216.34.181.48
Re:I'm not worried (Score:4, Insightful)
Parent
Re:I'm not worried (Score:5, Funny)
Hey!
I am an unpatched DNS server, you insensitive clod!
Parent
Re: (Score:3, Funny)
Only if you have a method for authenticating the other side of the phone conversation.
Visit the website and get the phone number, of course!
Re: (Score:2)
Gentlemen, We are reading a post from Chuck Norris [ebay.com]. Of course he is a "niceone", anyone willing to disagree?
Re:I'm not worried (Score:5, Funny)
I just remember the IP addresses and type them in myself. How hard is that?
That's all well and dandy until banner ads start flashing subliminal messages of unauthorized zone updates to you.
Parent
Re:I'm not worried (Score:4, Funny)
Parent
Re: (Score:2, Funny)
The back-biting is shameful (Score:5, Insightful)
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
Re:The back-biting is shameful (Score:5, Insightful)
So, you figure eighty vendors coordinated a simultaneous patch for some issue that is not really a big deal, probably just some guys vying for attention?
Parent
It's all a liberal plot (Score:5, Funny)
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.
Parent
Re:ATTENTION MODERATORS: MOD PARENT DOWN (Score:4, Funny)
Uh oh, somebody call the whaaaaambulance, we're going to need to perform a humor transplant here!
Parent
Re:ATTENTION MODERATORS: MOD PARENT DOWN (Score:4, Funny)
User ID 1352 trollin' it old skool!
Parent
Re: (Score:3, Insightful)
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
I don't want "irresponsible disclosure". I don't want to be vulnerable, while major corporations get to do marketing damage control. They had a hole. Ok, everyone makes mistakes. They found the hole. Great, then we can do something about it. Or not, because they kept quiet about it while secretly writing the fixes. They kept quiet about it for long enough that even Microsoft had fixes ready.
Meanwhile
Re: (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 all
Re:The back-biting is shameful (Score:5, Funny)
If there's one thing that everyone should have learned by now, if someone says "trust me", you should be skeptical.
No, you're off message. They need to click continue, because the screen has gone all dark and they can't get back to their web browser.
Parent
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.
Parent
Re: (Score:2, Insightful)
That same information ... puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk.
Extremist talk and dire predictions are great, but where have they gotten us in the past? 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.
I'm not sa
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.
Parent
Re:The back-biting is shameful (Score:4, Informative)
It was because of forethought of one man, DJB (Bernstein).
Parent
Re:The back-biting is shameful (Score:5, Insightful)
Sure you would; and the blame for any damage would be blamed on who made the disclosure.
There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.
Parent
Re: (Score:3, Insightful)
Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)
Sure you would; and the blame for any damage would be blamed on who made the disclosure.
There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.
Except Microsoft doesn't handle things this way. If this had been only a Windows issue we would have never heard about it. The fact that Open Source is vulnerable as well means that we will eventually know what the problems were and be able to look to see that it was fixed in the Open Source versions.
Re: (Score:3, Insightful)
This has nothing to do with any specific vendor or open source.
This issue is about how and when independent researchers disclose a vulnerability they find.
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.
Parent
Doctors make the worst patients (Score:5, Insightful)
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.
So, are we all compiling from source all the time? (Score:4, Insightful)
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.
Re:So, are we all compiling from source all the ti (Score:3, Insightful)
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.
Diffusion of Responsibility (Score:4, Informative)
You're looking for Diffusion of Responsibility [wikipedia.org], 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!"
Parent
So its not the same flaw? (Score:4, Informative)
Q: "This is the same attack as described way back in
A: No, it's not.
When Dan Kaminsky states in his blog. [doxpara.com]
"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?
Re:So its not the same flaw? (Score:5, Informative)
You are looking at two separate issues. The flaw Kaminsky found is apparently a newly discovered design flaw that makes DNS forging easy even with todays, unpatched DNS servers. In the advisory, they discussed previous problems with generating the transactionID to explain the problem and point out that what Dan found is not something already known (alot of people missed that very obvious point).
The second seperate, issue is UDP source port randomization. That is what Kaminsky was referring to DJB's solution. Kaminsky's assertion is that UDP source port is a good development practice which DJB incorporated into his DNS server.
Bear in mind that UDP source port generation doesn't solve the underlying problem, it simply makes blind DNS forging more difficult because now an attacker has to guess both a pseudo random transaction ID and a pseudo random UDP source port number. Alot of DNS servers and OS, simply picked source port numbers incrementally or in the case of a DNS server, re-used the some one over and over.
I don't know hom much more difficult DNS forging will be by randomizing the UDP source port numbers. The additional keyspace is (2^16-1023) and you can probably divide that in half again. But it's better then nothing and probably provides enough time (the time it would take an attacker to blindly guess the transactionID and UDP source port number) for the actual response to hit the DNS server. In DNS, the first response wins.
Parent
Re:So its not the same flaw? (Score:4, Informative)
Parent
A simple test to run (Score:5, Informative)
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.
Re:A simple test to run (Score:4, Informative)
Many older named.conf configs have "query-source port 53;". While this is nice for firewalls to open up DNS traffic (assuming replies from source udp/53 to destination udp/53 (your query port) are always safe), it makes it easy to exploit.
This must be removed and those nameserver restarted. I had to do this with all of my servers, otherwise all queries come from the same port (53). Complain to your ISP if you find this to be the case with their DNS servers and in the meantime use some other DNS servers.
My two local Comcast resolves show "Poor" as the ports they use only have a standard deviation of 130-150, which I guess is assumed to be far too obvious and easy to keep bombarding.
Second, your NAT router may be de-randomizing your DNS queries if you run a resolver at home, and taking your random ports and putting them in order starting at 1024 (or something similar).
My own local/internal DNS servers shows as a std dev of 9 since my PAT router is de-randomizing the external ports. I'll be replacing my PAT router.
Third, your NAT router may be your DNS resolver and may not be using random source ports.
Parent
Don't worry, Mr. Vixie (Score:3, Funny)
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.
Re: (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 mor
Re:Unfortunately, what else is new? (Score:5, Funny)
Your mad ad hominem attack skills have convinced everyone that Paul Vixie is the know nothing douchebag in this conversation. Kudos!
Parent
Re:Unfortunately, what else is new? (Score:4, Funny)
Parent
Re:Unfortunately, what else is new? (Score:4, Informative)
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.
Parent
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.
Parent
Re:What is Secure DNS (Score:5, Informative)
"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
Parent
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.)
Parent
Re: (Score:3, Insightful)
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 securit
Re: (Score:2, Funny)
I heard that this "security fix" is the addition of support for the Evil Bit [faqs.org].
Re: (Score:2)
It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).
If you visit Dan Kaminsky's blog [doxpara.com], there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.
Re: (Score:3, Interesting)