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."
Re:Slow down there (Score:5, Informative)
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...
DNSCURVE doesn't work... (Score:2, Informative)
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:Slow down there (Score:2, Informative)
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 (Score:1, Informative)
Well, a well chosen elliptic curve can be cracked (as in recover the private key) in exponential time.
On the other hand with public available algorithms a big number (like those p*q used in RSA) can be factored in sub-exponential time (basically polynomial time). While this complexity is enough for small enough computers is not enough for big clusters or supercomputers.
Re:Slow down there (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:1, Informative)
Too bad it does support AAAA records and SRV records. Oh, and it has a set of config files. And works just fine.
It seems pretty logical to me, BIND is the one that seems backward. Maybe it's because I've been using it since 1995.
Re:DNSCURVE doesn't work... (Score:3, Informative)
You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html [dns-oarc.net]
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.
Re:Slow down there (Score:5, Informative)
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 (Score:2, Informative)
Yes, it does. It supports arbitrary record types, something that even your precious BIND does not (even though the RFC says it should). Grep for "generic record" in the tinydns-data documentation.
It doesn't support IPv6 queries without a patch (not that software last updated in 2001 reasonably could), but it most definitely supports AAAA and SRV records -- I'm currently using it to serve both.
/ Feel free to not like DJBDNS, just pick technically valid reasons
Re:Slow down there (Score:2, Informative)
Jolly good show in owning up to the mistake, and with grace. Extraordinary forthrightness for Internet behavior.
Re:Slow down there (Score:3, Informative)
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 [cr.yp.to] 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 (Score:2, Informative)
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Implementations
Re:What's DNSSec going to cost us? (Score:4, Informative)
I personally find djbdns easier to use and less error prone than BIND for most stuff ( http://cr.yp.to/djbdns/blurb/easeofuse.html [cr.yp.to] ).
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 [dnscurve.org]
Re:Debian packet (Score:3, Informative)