DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve 179
coondoggie writes "Seven leading domain name vendors — representing more than 112 million domain names, or 65% of all registered names — have formed an industry coalition to work together to adopt DNSSEC. Members of the DNSSEC Industry Coalition include: VeriSign, which operates the .com and .net registries; NeuStar, which operates the .biz and .us registries; .info operator Afilias Limited; .edu operator EDUCAUSE; and The Public Interest Registry, which operates .org." The gTLD operators are falling in line behind government initiatives, which we discussed last month. In light of these developments, Dan Bernstein's push for DNSCurve might face an uphill slog. Reader data2 writes: "Dan Bernstein, the creator of djbdns and daemontools, has created his own proposal to improve upon the current DNS protocol. He has been opposed to DNSSEC for quite some time, and now he has proposed a concrete alternative, DNSCurve. He has posted a comparison between the two systems. His proposal makes use of elliptic curves, while DNSSEC favors RSA. He uses a curve named Curve25519, which he also developed."
I have deep respect for DJB (Score:2, Insightful)
...but he is not seriously attempting to establish a different protocol all by himself, is he? The root server administrators would never switch, and without root support, there is no place to anchor the hierarchy. He might have had a chance earlier in the standardization phase, but now that there are live DNSSEC domains, his chances are practically zero.
Re:What an idiot. (Score:1, Insightful)
Yeah, who cares about improving both time and space efficiency of cryptography before any sweeping overhauls of a core internet service are performed? It's best to think about that afterwards.
You know, kind of an after... thought.
Re:Slow down there (Score:5, Insightful)
ad 1) DNS is one of the few protocols where conciseness really REALLY matters. DNS attempts to answer requests in one UDP packet to avoid the overhead of establishing a connection. Elliptic curve keys are smaller than RSA keys of the same strength. The choice of 1024bit RSA keys for DNSSEC is a compromise (pardon the pun), which isn't necessary with elliptic curve cryptography.
Re:Slow down there (Score:3, Insightful)
This Bernstein guy is pushing a new crypto algorithm. Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?
Because Dan is Dan and won't be happy unless he writes libdancurve and makes you install it in /crypto/strong/etc/librarees for the next decade because it's under a non-FOSS license. Who know why he does anything he does?
Re:Slow down there (Score:5, Insightful)
Keep in mind that what matters is how the encryption is used. I don't think anyone cares to keep DNS requests private. What matters is keeping them authentic. Signing (and having a way to verify the signature) is of utmost important.
In other words, it doesn't matter that RSA can be broken by large botnets. If it can't be broken as I'm making the request, or before I receive the answer, then it's too late.
Now if somewhere along the way, someone decided that the goal was to keep DNS transactions a complete secret, then that's another issue. I don't see a general need for this level of secrecy.
Don't throw the baby out with the bathwater (Score:4, Insightful)
Re:Slow down there (Score:2, Insightful)
Re:Slow down there (Score:5, Insightful)
But DNSSEC uses all pre-computed signatures for the zone data. So if you can break the RSA key, you can create fake signatures ahead of time and serve bogus DNS data. Your botnet has got all the time in the world to try to break that key...
Re:Slow down there (Score:3, Insightful)
Excellent point. I was focusing on transactions, not the keys. Thanks for pointing out my error.
Okay, you take your time with that. (Score:2, Insightful)
Let me know when widespread support is available.
This is one of those cases where theory and practice differ. In theory, I'd love to wait until some absolutely uncrackable/fast/compact/available technology makes securing DNS possible. In the interim, this isn't the time to go back to square one and start over.
Of course, since DNScurve will never need a successor, of course it'll be worth the wait. Obviously, DNSSEC will have a successor and so we should just not bother and stick with good ol' DNS until DNScurve has wide enough adoption to make migrating work.
Uh, given that DNSSEC has taken nearly a decade to get here, how long will it be for DNScurve?
In theory, there's no difference between theory and practice. In practice . . .
What's DNSSec going to cost us? (Score:5, Insightful)
Not that I'm against anyone making a buck, but if there's a decent way to accomplish the same goal without having another set of keys to sign (and having to update ZSKs every freaking month) then I'd be happy to give it a fair shake. It's not like most admins have all sorts of free time to deal with additional overhead.
Another point in favor of DJB - Yes, he's abrasive, but when was the last time tinydns needed to be updated because of a security vulnerability? Now compare with BIND and Windows Server. We can argue his quirks all day long, but dude does have hands down the best record (pun semi-intended) when it comes to DNS security.
Re:Slow down there (Score:3, Insightful)
Re:Slow down there (Score:3, Insightful)
IXFR, not AXFR. IXFR is sort of like a journal playback. Suppose you have 100,000 records in a zone. With AXFR, if you change one record, you have to retransmit all 100,000 records. With IXFR, you transmit the change alone. The suggested workaround is to use rsync or some other synching mechanism, but with djbdns that'd mean that rsync has to sync a directory with 100,000 files. Again, with IXFR you'd just replay the journal.
Re:Slow down there (Score:3, Insightful)
I care about keeping DNS requests private. I personal would prefer that my ISP can't tell where I'm browsing just by grabbing clear-text domain names out of DNS queries.
Never worked for an ISP, huh?
I worked for a (small?) one about 8 years ago. 8 years ago we had on average 1,000 users connected, and also hosted several thousand domains, and had 30,000 mailboxes on our server.
In an average day, we handled around 70 DNS requests per second on our primary server and about 10 requests per second on our secondary. (Using Microsoft's crappy DNS server no less)
So tell me why I should bother sorting through roughly seven million DNS requests per day to see where you've been surfing?
It's in the same vein as "Do you read my email?". On a server with 30,000 mailboxes, and who knows how many messages coming in per-second, the answer is "f*ck no". The volume of mail is too great.
Of course what your average BOFH might admin over a few beers is that the only time we ever monitor something like mailboxes or DNS requests is when something brings them to our attention...like a user asking if we're monitoring their activities. "No, should we be?"
There's a reason we haven't implemented DNSSEC (Score:5, Insightful)
I recently researched DNSSEC and I was going to implement it in my environment until I read the downfalls:
1) Traffic for the signing of records would increase exponentially because to establish the authenticity you'd have to contact the originating server and do a PKI-like transaction (that's expensive). In it's current form, forcing DNSSEC throughout the world would effectively bring down the root DNS servers as well as many others
2) Because of 1) caching DNS servers would be less useful since you'd have to contact the original for the keys anyway. This also introduces the problem that if all the original DNS are unreachable for whatever reason the whole zone would become unusable whereas now they have been cached.
3) There is an attack vector where by using the no-record responses somebody can obtain the whole zone even if you didn't intend to publish it
The problems with DNS are the same as the problems with SMTP and IPv4:
- The problems were there from the start and the protocol wasn't designed with current threats in mind. Fixing it would effectively break it.
- The only solution is to build up a new system parallel to it and introduce it without anyone noticing
- The usable solutions are only temporary patches that make it more difficult to use become quickly reduced to the above 2 problems
- There are multiple solutions from separate entities with their own agendas. Choosing one over the other has it's own flaws and is sometimes not even feasible.
DNSCurve is better (Score:5, Insightful)
DNSSEC focuses on signing dns zones. DNSCurve protects the transport only.
This difference makes DNSSEC maintenance a pain in the ass, and DNSCurve easy.
There are plenty of links in the summary to back this up, just wanted to point it out.