DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

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."

Comments

Re:Slow down there

[Anonymous Coward]

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

[Sancho]

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

[EdwinFreed]

I'll say this for Dan - he is often quite good at analysis and finding problems. But after watching a huge fight between him and the authors of the delivery status notification format for email, with the result that positions became completely polarized and nobody succeeded in convincing anyone else of the merits of their respective ideas, I decided the best way to deal with him is to listen to his criticisms, evaluate them carefully, and if it makes sense to address them, do so. But attempting to engage in a meaningful discussion with him is a waste of time - he gets angry way too easily and starts throwing all sorts of nasty invective around, and the result is almost always that the interaction spirals straight down the crapper.

Re:Slow down there

[foom]

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...

What's DNSSec going to cost us?

[ErikTheRed]

DNSSec uses hierarchical signature chains (similar to SSL). So, um, they're going to sign our keys out of the goodness of their hearts, right? Oh, they're not? So the real reason that these registrars are running around with giant erections over DNSSec is because it's a whole new revenue stream for them? Makes sense now.

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.

There's a reason we haven't implemented DNSSEC

[guruevi]

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

[eggnet]

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.