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

What a Coincidence!

[Anonymous Coward]

DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve

That was the subject of the last spam e-mail to pass my filter!

djb has an alternative?

[bsdphx]

go figure...

Perhaps he should start his own separate Internet and be done with it. ;-)

Slow down there

[girlintraining]

Okay, a few things;

1. 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? It seems imprudent to use a new and largely untested algorithm to patch critical infrastructure. His reputation should not be a deciding or even motivating factor in the adoption of a new algorithm; Isn't the standard process to submit it to the IETF or similar organization to have it ratified first?

2. Industry coalitions are great, but this seems to be an attempt to create a new de facto standard controlled by a few large corporate interests, most of which are based in the United States. Isn't this kind of organization exactly what ICANN was created to avoid (I'm side-stepping the controversy surrounding them here)?

It seems to me they're rushing headlong toward a solution to solve a problem that hasn't yet made a major impact (though the potential for exploitation is substantial), and there is great potential to create an even larger problem here. This is exactly the kind of thinking that needs to be avoided when making infrastructure-level decisions about large, global networks. The Domain Name System is a global resource and an asset to every country on the planet. It is highly circumspect that those countries are presently without a voice in this transition.

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

[glop]

Bernstein says that RSA-1024 bit is not secure as big botnets (or big companies) can break such keys.
That would defeat the purpose of DNSSEC.
I wonder what this means for SSL certificates...
RSA has a wrapup here:
http://www.rsa.com/rsalabs/node.asp?id=2007
Apparently they disagree...

Re:Slow down there

[Just Some Guy]

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

[Anonymous Coward]

Note that ECC isn't a new Crypto Algorithm. Although it is newer than RSA, it's still over 20 years old. ECC is an IEEE standard, and has been standardized by NIST as well. It's also discussed in RFC 4492, and other RFC's as well. The only part that's novel in this treatment is the choice of a particular Elliptic Curve (similar to choosing an Exponent in RSA).

Re:Slow down there

[lgw]

Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?

He's pushing a new piece of software, not at all a new algorithm. In particular, Old-RSA-style product-of-primes encryption has been deprecated by the NSA for several years now, and shouldn't be used in any new software. Elliptical curve technology is one of the alternatives recommended by the NSA.

Bernstein may *be* an ass, but he's not *talking out of* his ass.

Industry coalitions are great, but this seems to be an attempt to create a new de facto standard controlled by a few large corporate interests

You've just described almost every successful engineering standard. As someone who has served on an international standards committee, let me say: the standard *is* what the vendors who control the market *do*, otherwise it's just a piece of paper. A useful and productive standards committee is formed when the few large corporate interests (who collectively have most of the market share in some space) get together and say "let's all agree to do things the same way".

Otherwise you end up with a meaningless standarded ignored by products that represents 90% of a market, like the early days of the HTML "standard". Wow, that's useful.

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.

Re:Slow down there

[Twylite]

ECC is not a new crypto algorithm. It has been around since 1985, it is will studied, and it is recommended for use in the US (NIST, NSA Suite B), in the EU (NESSIE project falling under the European Commission), and in Japan (CRYPTREC government project).

Bernstein has created a new curve for use with ECC; one that is better suited to the requirements of this particular application than other existing curves. He claims to have followed the appropriate practices in generating this curve -- that obviously needs to be verified by suitably knowledgeable experts.

The "existing algorithm" is RSA, specifically RSASSA-PKCS1-v1_5. There are more secure signature schemes available for RSA, e.g. RSA-PSS. In addition DNSSEC will use 1024-bit RSA keys as a compromise (to reduce transfer size and computational overhead) -- NIST recommendations are that 1024 bits are too short for any purpose.

DNS forgeries are already having a significant impact - keep your eyes on the security reports.

Re:Slow down there

[harlows_monkeys]

This Bernstein guy is pushing a new crypto algorithm

No, he is not. He's using an old, well-tested, well-studied algorithm, generally believed among cryptographers to be more secure than RSA.

Re:Slow down there

[Anonymous Coward]

qmail is the first thing many people think of when they hear djb, and the license to qmail kept it in 1995 for 12 years. I'm glad he re-licensed qmail eventually, but the damage to his reputation is done, and many people simply don't want to ride that train again - they see the name djb and think "thanks, but no thanks".

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

Re:Slow down there

[Sancho]

Excellent point. I was focusing on transactions, not the keys. Thanks for pointing out my error.

Re:Slow down there

[PitaBred]

A lot of the reason that Betamax died was because the tapes couldn't hold full length films initially. Standard Beta tapes were 60 minutes, vs 3 hours for VHS. For the "technical superiority" of Beta, VHS was much superior in general usability for the vast majority of consumers. I mean, if you had the choice of recording only 60 minutes of HD, or 180 minutes of SD, which one would be more useful to you, as a person who watches movies, not as a technologist?

Re:Slow down there

[Just Some Guy]

You are mistaken. Go to tinydns.org and read

I did. That isn't the official version of djbdns; it's a fork. Furthermore, note that even the "enhanced" fork fails to support such fundamental necessities as IXFR. You can hobble together some hackish workalike with rsync - assuming you have control over both servers. Good luck getting a registrar or any other free/cheap DNS hosting service to go along with that arrangement.

As always, djbdns is probably OK as long as you don't need any of the (common) features it doesn't support. If you do, it stops looking so clever.

Re:Slow down there

[Korin43]

Your ISP probably is your DNS provider, so encrypting the communication to your DNS won't stop them from knowing where you're going.

Re:Slow down there

[Onymous Coward]

Jolly good show in owning up to the mistake, and with grace. Extraordinary forthrightness for Internet behavior.

Re:Slow down there

[Just Some Guy]

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

[mrsbrisby]

I did

You need to work on your reading comprehension then.

DJBDNS supports all RR types, by way of generic RR support. See near the bottom of this page for details.

There is a series of patches that produce friendly syntax for tinydns-data, a single component of DJBDNS. This isn't valuable to large sites who don't source with tinydns-data's built-in format.

Re:Slow down there

[darkpixel2k]

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

Re:Slow down there

[Anonymous Coward]

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Implementations

I have deep respect for DJB

[Anonymous Coward]

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

DNSCURVE doesn't work...

[nweaver]

The argument against DNSSEC is that its not needed for securing DNS: that the in-path adversary can F@#)* the final app anyway, unless the final app never trusted the DNS name.

However, there is one key adversary which is in-path on the naming but NOT in path on the data: the DNS recursive resolver. We have seen resolver settings changed by malcode, ISPs wildcarding NXDomain errors, and even DNS service providers (like OpenDNS) man-in-the-middle'ing google!

DNSSEC addresses this adversary, because it is a data integrity protocol. DNSCurve does not: it explicitly trusts the recursive resolver and offers NO security guarentees against this very serious adversary.

Fortunatly, nobody in the DNS world cares about DNScurve, so it will probably just go away.

In fact, DNScurve really shuold be restructured to be a competitor for DTLS, a lightweight datagram communication confidentiality & integrity protocol with a much lower key-setup latency.

Re:DNSCURVE doesn't work...

[foom]

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

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.

Some bad ideas won't go away...

[damn_registrars]

We've discussed before just how terrible of an idea it is to start selling gTLDs and let the spammers and con artists start running the entire show.

And there have been more than a few objections on the list about selling gTLDs, as well.

Yet apparently ICANN is set to go ahead with it, anyways.

Funny, most organizations would be opposed to taking action that reduces their own authority (which is one obvious effect of selling gTLDs) - but of course with the prospect of seeing a small, immediate infusion of cash from the process, ICANN is all over it.

Funny, in the name of profit, we are moving towards less regulation, less control, less accountability, and more resemblance to lawlessness.

Unfortunately once they make this mistake there is no going back. We'll have unscrupulous registrars selling to criminals all over the world and we'll have zero control over the domains that turn profit on (counterfeit) drugs, (pirated) software, (counterfeit) fashion goods, (stolen) personal identification and the like.

Okay, you take your time with that.

[mmell]

Let me know when widespread adoption seems likely.

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

That is the point of DNSCurve

[CustomDesigned]

DNSSec pre-signs all DNS records. In order to "sign" "no such record" responses, it is necessary to sign a list of records that don't exist in a zone. This effective publishes your entire zone as a side effect.

DNSCurve encrypts and authenticates the transaction, like SSL. This has the side effect of not needing to publish the entire zone. Instead of getting the public key from special DNSKEY records, DNSCurve stores it in existing NS records, encoded in the server name.

I would like to use DNSKEY records if available, otherwise use the specially encoded servername. That scheme could also gradually transition to widespread DNSKEY support, since both the encoding and DNSKEY could be used. DNSSEC could even use the encoded servername idea - but the names would be *really* long thanks to the longer RSA keys.

Re:What an idiot.

[CustomDesigned]

If RSA were not considered computationally secure, I might applaud his intent to provide "a better mousetrap".

Since 1024 bit RSA used by DNSSEC is *not* considered computationally secure, I'm sure he'll appreciate your applause.

Also, his "hack" of encoding the key in NS records actually simplifies deployment and could also be used by DNSSEC (at the expense of long DNS server names - *really* long in the case of DNSSEC).

DNSSEC is pre-signed, and can be checked by a client even if a DNS cache is compromised. (If you already have non-forged keys from the root.) But this also means you effectively publish your entire zone.

DNSCurve protects transactions, and depends on secure caches. Clients have to run their own caching nameserver if they don't trust the ISP DNS. (Pretty much the case now.) But you can also continue to use secret names in your zones.

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.

Re:What's DNSSec going to cost us?

[TheLink]

I personally find djbdns easier to use and less error prone than BIND for most stuff ( http://cr.yp.to/djbdns/blurb/easeofuse.html ).

If you want to manipulate DNS records with perl, the djbdns format is much simpler than BIND's.

Yes it is different from BIND, but different can also be better.

Postfix's main.cf is different from sendmail.cf but much simpler(yes I know about m4, but honestly is it really simpler than Postfix? ).

The ISC have a long track record for producing hard to manage stuff with security problems.

It's no surprise that DNSSEC is a bad design (it's a good way for corporations like Network Solutions/Verisign to extract more money from people tho).

http://www.dnscurve.org/dnssec.html

Will either DNSSEC or Curve solve this prob?

[JSBiff]

I've thought before that it would be useful, if I'm using my laptop on a public WiFi network, to be able to use a pre-designated, trusted DNS Server (so that the public network's DNS Server can't send me to bogus servers).

It would be a nice feature if I could have my computer cache the public key of my ISP's DNS Server (or maybe OpenDNS; the point is, some DNS Server *I* trust, instead of a random DNS server), then, no matter what network I connect to, always use that DNS Server, with the DNS packets being signed by the trusted server, so I know they are really from that server. (I realize I can use OpenDNS pretty much anywhere, but I don't know if there is anything preventing the local network from doing a MITM attack?)

It might also be useful, for this type of system, if my computer can authenticate to the ISP DNS Server (because they might not normally allow DNS requests from outside their own network, but if there were a specified authentication mechanism as part of the standard, they might allow me to roam if I authenticate)?

Maybe the best answer is to just use the VPN capability on my home router to always VPN to that router, which will then use my ISP's DNS. Until DNSSec is implemented widely, that's the best solution for now, anyhow, I think.

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.

How is DNSCURVE news?

[RichiH]

DNSCURVE has been around for some time, now. DJB just does a shitty job of pointing out why it's superior. As I don't have time to sum it up, just harvest the +5 I comments for details.

Also, I would have thought that qmail has a larger impact & coverage than djbdns & daemontools, but oh well ;)

DJB is hard to deal with when, not if, you disagree with him. But he _does_ churn out good stuff.

Re:Debian packet

[hardaker]

There are multiple implementations of DNSSEC for debian in the core repository. The latest bind tools support it and dnssec-tools is available packaged for debian.