VeriSign Will Support DNSSEC In .com By 2011 39
alphadogg writes "VeriSign has promised to deploy DNS Security Extensions, known as DNSSEC, across all of its top-level domains within two years. DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered last year. (Yesterday we discussed the workarounds coming into place until the US government signs the Internet's root zone.) DNSSEC has been deployed on top-level domains operated by Sweden, Puerto Rico, Bulgaria, Brazil, and the Czech Republic. Two larger domains — .org operated by the Public Interest Registry and .gov operated by the US government — are deploying DNSSEC this year."
erm... (Score:5, Insightful)
What takes so long? Why not now?
Re: (Score:2)
Because the wheels of a bureaucracy grind slow, and exceedingly dumb.
Re:erm... (Score:5, Insightful)
They need time to figure out how to profit from the deployment.
Re: (Score:2)
They need time to figure out how to profit from the deployment.
Very funny. If that was the hold-up, they wouldn't be promising or planning anything.
Re: (Score:2)
Saying they are planning something != they actually are. If DNSSEC isn't something that will generate revenue, expect "unforeseen delays" to cause the roll-out to be postponed indefinitely - or scrapped entirely. Press releases cost very little, and by the time 2011 rolls around, nobody will remember them anyway.
Re: (Score:2)
Re: (Score:2)
Oh that's easy. A 'secure' entry will cost $$$, require a verisign certificate and they'll pressure browser makers to produce ominous warnings if your domain isn't signed by them.
I suspect the delay is because NSEC3 only just got put into bind 9.6, and DNSSEC is (ironically) just too insecure to deploy without that.
Re: (Score:1)
Well, you're half right.
DNSSEC's original form allowed for unrestricted zone walking via querying for non-existent domains and receiving an answer containing the RRs appearing just before and after the non-existent domain. This was a major stopping point for widespread implementation. RFC 5155 and NSEC3 addresses this by using hashes of domains instead of domains themselves.
As for the certificates, you do not need to buy a certificate from VeriSign to sign your DNS data. You generate your own keys and pr
Re: (Score:2)
And who do you suppose is delegating my .com domain to me? Even if I don't have to "buy a certificate" from them, do you really think that they will do anything useful with that key fingerprint without trying to extract more money from me?
I somehow doubt that telling people with .com domains that they ca
Re:erm... (Score:5, Informative)
Because when released it will reduce the profit from their certificate signing business, as people can get end-to-end public key encryption just by updating their DNS entry.
Re: (Score:3, Interesting)
Because when released it will reduce the profit from their certificate signing business, as people can get end-to-end public key encryption just by updating their DNS entry.
Maybe this is the real reason behind the "Extended Validation" certificates they're pushing? Those include some verification of your real-world identity (like I thought regular certs were always supposed to have...), so they can't be replaced by dnssec.
Huh? (Score:2)
The DNSSEC and https/SSL certificate systems are completely different.
I mean, you *could* use https/SSL to get secure DNS via port 443 right now, all it would take would be a few lines in Apache. Now convince the rest of the world to follow your lead....
DNSSEC (and DNSCurve) are only as good as the clients that adopt it.
Re:Huh? (Score:4, Informative)
The DNSSEC and https/SSL certificate systems are completely different.
I mean, you *could* use https/SSL to get secure DNS via port 443 right now, all it would take would be a few lines in Apache. Now convince the rest of the world to follow your lead....
DNSSEC (and DNSCurve) are only as good as the clients that adopt it.
Huh?
The idea is that instead of paying a CA to give you a SSL certificate, you generate your own and put the hash in a DNS record. With DNSSEC, this means that your SSL certificate is effectively signed by your DNSSEC key, with a chain going back to the keys for the root zone. This eliminates the need for CAs (unless you use the EV certs, that map to a real-world identity that browsers will usually show people), and even gets rid of the problem of bad signers that give out certs they shouldn't.
Re:erm... (Score:5, Insightful)
Many reasons....
The root is just the root...
70 million domains to sign. Think you can just do that on your desktop in a couple of hours? It's going to take an infrastructure of machines to do this. That infrastructure itself is going to need to be secure. And reliable. And backed up. Securely. And with a geographical disaster recovery plan in place. ( A secure one ). And they need to ensure that their root servers ( A and J ) can handle DNSSEC too. Just to be clear, neither A nor J are a single server - you just don't handle more than 50 BILLION queries EVERY SINGLE DAY from a couple of boxes on a T1. VeriSign has a large number of distributed boxes that comprise each root server.
That's just the technology - the easy part. The harder part comes with the business processes needed to support this. New domains will need to be signed. Employees are going to need to be able to do that somehow, but every employee that has access to the root key is a risk to that key Consider that if that key gets compromised the whole stack of cards will come tumbling down, thus requiring those 70M domains to be resigned with a new key. And that new key's cert will need to be published downstream etc. So somehow VeriSign has to come up with business processes that allow new domains to be signed without the root key being compromised. Processes that allow the infrastructure to be administrated and monitored without the root key being compromised etc.
If you're not getting the picture yet, this is really not a trivial exercise.
The good news is that VeriSign has experience with these kinds of problems - running the CAs that sign >90% of the World's PKI certificates has given them that.
Before the usual VeriSign hating slashdot crowd get in here... it's my opinion that VeriSign do a great job with DNS. I can't think of any other service that I pay for that has given me 100% uptime this year alone, let alone for a number of years.
Most corporations strive for five 9s uptime. That allows 5 minutes and 15.35 seconds of downtime in a (non-leap) year. My electricity, water, gas, oil and ISP have all had outages longer than that in the past year, and most of them have outages every year, and yet I pay them a damn sight more than the $7 a year that VeriSign gets for serving my DNS records.
Disclaimer... I'm an ex-employee and small-time stock-holder of VRSN.
Re: (Score:2)
My electricity, water, gas, oil and ISP have all had outages longer than that in the past year, and most of them have outages every year, and yet I pay them a damn sight more than the $7 a year that VeriSign gets for serving my DNS records.
I've a few niggling points to make here...
Your utilities companies have to acquire, distribute, and track usage of a good in meatspace. VeriSign has to store and serve some hundreds of bytes of data per domain, per request in cyberspace. What's the cost of shipping some hundreds of bytes, again? (Hell, what's the cost of shipping a trillion bytes?)
Most utilities companies also serve a comparatively insignificant area when compared to VS's market. VS can really work the "economies of scale" thing in connecti
Re: (Score:2)
Re: (Score:2)
What takes so long? Why not now?
TFA says the delay is related to the size of the zones, so I'd guess it's related to increased hardware and bandwidth requirements. I can double my computing power with a trip to walmart, and double my bandwidth with a call to Comcast and probably a reset of the cable modem... Verisign might have a bit more difficulty.
But How Long... (Score:1)
While I'm at it, will Verisign be sure to support at least one dangerously obsolete algorithm, just to ensure the opportunity for clever hacks?
are you sure this is such a good idea? (Score:2)
DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered last year.
[citation needed] Or maybe this is "weasel words". In any case, "Says who?"
I'd like to see some discussion around the relative merits of DNSSEC v. DNSCurve. DJB knows his shit, and I want to see his ideas getting proper exposure here.
Re: (Score:3, Informative)
I'd like to see some discussion around the relative merits of DNSSEC v. DNSCurve.
With DNSSEC, it's the data that's authenticated. With DNSCurve, it appears to be the server. Does DNSCurve protect against a meddling cache, or does it require all queries to be processed by the authoritative server or a trustable cache?
DNSCurve encrypts connections. This has per-byte overhead, plus per-connection overhead which can (mostly?) be made into per-peer overhead with caching. DNSSEC doesn't, so someone could potentially see what records you look up (and save themselves the trouble of having to lo
Re: (Score:2)
With DNSSEC, it's the data that's authenticated. With DNSCurve, it appears to be the server.
The server? As I see it, it's the connection from the client (i.e. your ISP's caching proxy resolver) to the server; that is, the communication.
What's the difference? If you run your own trusted resolver and you trust the root, let's see:
Sec: you get the IP of .com and a signature which you trust
Curve: you get the IP via a channel which you trust.
In both cases, you know the .com address that root wants you to know, and you trust the result. By induction,
2. ???
3. profit.com
One difference, though: in Sec,
Re: (Score:2)
DNSCurve encrypts connections. This has per-byte overhead, plus per-connection overhead which can (mostly?) be made into per-peer overhead with caching. DNSSEC doesn't
Per-byte cost of what? Traffic or time?
With Sec, you have to validate signature(hash(data)). That's a per-byte time overhead for the hash function. Symmetric encryption is similar. Assymetric encryption is always (well, almost always) applied to a symmetric key which is used to encrypt the data; symmetric encryption has performance characteristics much like hash functions: per-byte processing, 1-to-1 size ratio between input and output.
Extra per-byte CPU cost on the server (and client/caches) to do the encryption. Validating signature(hash(data)) is likely more expensive as a public-key operation (similar to the per-connection/peer part of the DNSCurve overhead), but is client-side where it doesn't matter... except it also probably happens on caches, so I guess DNSSEC would put a (slightly?) higher (CPU) load on caches (and clients) and a lower load on servers.
DJB causes his own problem here (Score:4, Insightful)
[citation needed] Or maybe this is "weasel words". In any case, "Says who?"
Everybody *but* DJB. And since DJB has apparently pissed off just about the entire rest of the population of the planet at this point, his pet-project ideas have just about zero chance of being adopted widespread. So, in a very real sense, DNSCurve is by definition the least-good way to secure DNS, because it will never see real adoption.
Whether or not DNSCurve has any good ideas or not doesn't matter, because DJB has burned every bridge to his own little island. And it turns out that a network that doesn't connect to anything isn't very interesting.
Re: (Score:2)
Bernstein doesn't need to convince people with his diplomacy, just his software and its minimalist documentation. qmail and djbdns achieved widespread deployment *despite* their unhelpful licenses and lack of official maintenance. If he can put out a new tinydns release to prove DNSCurve, rather than just a vague specification, he stands a high chance of spreading the idea from the ground up.
Re: (Score:2)
qmail and djbdns achieved widespread deployment *despite* their unhelpful licenses and lack of official maintenance.
There are many pieces of software that are not the best tool for the job (or even in the top three in their category) of which similar things can be said.
For example, Internet Explorer has been behind the curve in browser quality for years, yet is the most used. Photoshop probably isn't the best tool for the job for 90% of people, yet it is the "must have" graphics editing tool.
Whether qmail is internally secure or not isn't important if it's default configuration leads to blowback spam. One of the touted
Re: (Score:2)
What!
Where have you been for the last decade? Pay attention!
http://www.kb.cert.org/vuls/byid?searchview&query=isc%20bind [cert.org]
http://www.kb.cert.org/vuls/byid?searchview&query=djbdns [cert.org]
18 v. 0? And you're looking for what kind of "authority" to make this judgement for you?
(For full disclosure, there is now a single candidate (by-design) vulnerability listed with the CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 [mitre.org])
2011? (Score:2)