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."
Slow down there (Score:2, Interesting)
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:I have deep respect for DJB (Score:1, Interesting)
Re:Slow down there (Score:5, Interesting)
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 (Score:1, Interesting)
Basically, if you want to implement elliptic curve cryptography, you have to pay up. Then you may still have to pay up again and again due to further patent holders. As for doing it in open source software? Forget it.
Some bad ideas won't go away... (Score:3, Interesting)
And there have been more than a few objections [icann.org] 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.
That is the point of DNSCurve (Score:5, Interesting)
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. (Score:3, Interesting)
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.
Re:Slow down there (Score:3, Interesting)
A lot of the reason that Betamax died was because the tapes couldn't hold full length films [mediacollege.com] 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?
Will either DNSSEC or Curve solve this prob? (Score:3, Interesting)
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.
How is DNSCURVE news? (Score:4, Interesting)
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.
Debian packet (Score:2, Interesting)
Wake me when there's a Debian packet available.
Seriously. I've outgrown the age where I compile my software, unless it's stuff that I've written myself.