Slashdot Mirror
Secure DNS a Hard Sell
ebresie writes "Computer Business Review Online has an interesting article about the lack of acceptance for Secure DNS." From the article: "Speaking during a workshop on the technology, Keith Schwalm of Good Harbor Consulting, a former US Secret Service agent, said that even the financial sector, traditional security early-adopters, are not rushing DNSsec."
Enough of my customers don't understand REGULAR DNS, nevermind secure DNS. The only way that this is likely to be adopted is to have the top level name servers eventually require the secure extensions. I doubt, however, that that will happen.
As it is now, I have my users going to their registrars and "deleting the 'A' records because: "There is no A on my website."
Try to hack my 31337 firewall!
One could have said the same thing about music CD DRM (e.g. the Sony XCP RootKit) -- or the 9/11 terrorist attacks for that matter.
There's not a problem with it -- until there's a big problem with it. Then everyone asks why wasn't something done to protect us against it?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
We already have authentication systems. Why should DNS, which every website uses, be doing something which only a tiny fraction of websites need?
Besides -- technology can't stop phishing. A combination of education, authentication and client software that can with 100% reliability inform the user whether authentication has happened is the answer. Authentication is by far the easiest problem of the three. Education is more or less impossible, and reliably informing users is next to impossible. (In a web browser, anyway. If you let websites display images and run active content, how do you stop them fooling a user, even a well educated one? How do you guarantee it's impossible to do so?)
What it might take to bring about adoption would be a .sec TLD that only operates with DNSsec, and any other major security improvements. Banks and others might prefer to be associated with a domain that is secure from the beginning, spurring its adoption. This way the market place would decide since it would have a real choice.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
So in the end, economics will drive SecDNS more than anything else. It seems like a good idea though for some institutions to go to a more secure DNS format. Let's face it: Fred's House of Flowers probably doesn't need as secure a domain as Citicorp or the CIA. The Internet ends up becoming a two-level affair, with the majority of sites being regular DNS sites and corporations and such using the more secure DNS setup.
GetOuttaMySpace - The Anti-Social Network
The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.
The article says:
It's possible that a web surfer could think they are visiting their bank or an auction site and hand over their sensitive data, and it would be impossible to tell they were at a malicious site.
I disagree: there is a good way to tell if that is your bank you are talking to; check that they have the proper SSL certificate for their domain. Or better yet, just look at the color of the address bar in Firefox. If your bank isn't using SSL already, there are reasons far beyond DNS that they should be!
Also, even with SecDNS in place, physical man-in-the-middle or route poisoning attacks could intercept the communication at the IP level, making SecDNS marginally useful at best. In my opinion, the proper solution would be to encourage more widespread adoption of the existing SSL cert solution for services other than HTTPS. (e.g. SMTP, POP, FTP) Also, it would be good for the industry to have some additional certificate authorities with lower certification prices added to the major browsers' default trust list.
I disagree. Qmail is a prime example of getting things very wrong.
The main problem with "secure DNS" is that you can't get it. This is because some of the problems remain unsolved - the problem of key rollover is currently generating a huge debate on the namedroppers mailing list, not the least because one of the proposals being advanced is patented.
.com) isn't in a signed zone.
On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g.,
On top of that, many TLD providers seem to want signed zones to be a value-added option rather than basic functionality. So as with RSA, lo those many years ago, adoption will be slow because people want to monetize it, rather than seeing it as basic functionality that has to be there.
So it's no surprise that the end user isn't interested in it yet - they can't get it even if they are interested.
Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed. It is really odd that so few people seem to care. It is kind of like putting a hundred dollar deadbolt on a screen door.
The only solution is either get secure DNS, or find a way to securly exchange keys out of band (rendering the point of x509 kind of moot)
Finkployd
This is a valid point, especially when you look at the number of small fish in the pond. You have small registrars, you have small CAs (do you really trust Unizeto? I don't even know what it is, and yet by default Mozilla gives it the same trust as it gives Verisign.) Even so, I posit that it really doesn't matter how much trust I can place in the CAs and the registrars, because the (unfortunate) end result is that most users, when presented with a certificate error, simply click OK. We train users to do this. Many corporate and educational entities set up their own CAs, and then when users see a message in their browser about an untrusted CA, the tech staff just tells them to 'click ok'. As such, the user is now conditioned to click 'OK'. What have we done? Totally diminished the usefulness of the trust aspect of SSL.
"Most people can't tell if they are connected using SSL or not"
Those are beyond salvation and I don't think that secure DNS was developed with them in mind.
I mean, someone which will accept following an hyperlink coming on a html e-mail from somebody unknown to him that says "your.bank.of.confidence" while obviously opening a browser pointing to "your.hacker.of.the.day" won't benefit any more from using secure DNS.
If you have a malware that poisoned your DNS cache, it might as well install a new trusted key in your browser. The malware site can then have another key that is signed with the key that the malware have already installed and you will have a secured connection.
But starting with a corrupted computer to begin with is a bad example anyway. The malware could simply substitute the ie.exe program for a new one that show what he want.
[]'s Victor Bogado da Silva Lins
^[:wq
SSL does not solve DNS issues. Nothing prevents determined hackers from installing an SSL certificate on their phishing website to look like the real thing - most users don't know the difference anyway.
I don't make predictions, and I never will.
Why on earth would you expect them to embrace it?? There is NO cost incentive to go to this. Apparently something catastrophic has not yet happened to emtpy the coffers and there-by motivate them...
All content in this message is copyright (c) 2008. All rights reserved. RIAA is prohibited here.
SSL does nothing to prove you're connecting to the right site if the attacker gets a cert from a CA. Most of the CAs now have "instant" SSL certs which have zero identity checking and a lower price. Very few users pay attention to the SSL icon, but even fewer open up the certificate properties and verify that the organization name on the cert is from who they think it is.