Slashdot Mirror
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."
DNSSEC Advances in gTLDs; Bernstein Intros DNSCurve
That was the subject of the last spam e-mail to pass my filter!
go figure...
Perhaps he should start his own separate Internet and be done with it. ;-)
... if you can't hack an existing domain to redirect traffic, why don't you easily buy a misspelling and play off people who can't spell the domain properly? And then sell it back to the initial company for a huge profit.
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.
#fuckbeta #iamslashdot #dicemustdie
...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.
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.
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.
Test your net with Netalyzr
You might want to google him before calling him any name.
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.
A personal opinion, that. YMMV.
Run BIND with DNSSEC and point your resolver to localhost. That's actually the way God, or whoever, intended it to be run.
In practice, most organizations will run a local recursive "trusted" BIND server with DNSSEC behind a firewall just like they do now. Eventually substantial numbers of ISPs will do so too. No one does not because something like 0.01% of .com domains are DNSSEC-ified.
It should be no more difficult that setting up HTTPS was, of course it only took 10 years or so to get that out of the hands of the security high priests.
I am sure DJB's proposal holds merit. But engineering is also about what can be done. If you are paranoid about the NSA redirecting your domain to a porn site, you probably should be worrying about far worse things instead.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
I might recommend looking further into this "new crypto" business.
Here are a couple links in case they're hard to find:
Just in case it's also hard to follow links, here's some selected text:
Okay, let me restate the problem - should we implement a mechanism which is already available and well understood, as well as generally accepted as secure (Mr. Berstein's assertion that RSA1024 is broken to the contrary), or should we implement it with a technology which can't be nearly as mature (not so much for its newness, but rather for its lack of broad acceptance/use)?
You're right - let's pick the shiniest technology on the shelf, we all know that elliptic curve encryption is faster, smaller and uncrackable, right? Uh, it is uncrackable, right? 'Cuz, you see, RSA1024 is uncrackable, or so I was once told. Now Dr. Berstein says it ain't, but elliptical curve encryption is. Funny thing - if RSA1024 is more than enough to secure my bank transactions, why wouldn't I trust it with my DNS queries?
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
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 . . .
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.
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.
Why not just default to TCP for DNS resolving over UDP?
It solves the problem.
Change is certain; progress is not obligatory.
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.
Help save the critically endangered Blue Iguana
At just a moment when the internet at large needs to standardize on secure mechanisms, he has to gratuitously add another potential standard to the mix, increasing the difficulty of getting anything done.
that's because he's an egomaniac who'll not be happy until the internet becomes DJBnet, all based on DJB/IP, with DJBDNS, DJBML and the like
What ? Me, worry ?
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.
We've known since the beginning that the security of RSA depends on the key length that computers can factor using the latest algorithms. 10-bit keys were always too short; 512-bit keys were cracked in 1999, and Shamir ("S" in "RSA") published work in 2003 suggesting that 1024-bit keys might be endangerable soon - they're probably fine for one-shot use on any individual message less important than planning the overthrow of a large government, and they're certainly fine for bank transactions, because the cost of breaking them far exceeds the amount of money in your bank account. But for a single long-term hard-to-change widely-used target, like the DNS root or .com, RSA1024 is pretty dubious. It's probably fine for signing www.yourdomain.com unless your domain is a large bank, but the protocol needs to support keys that are long enough for everybody, which means it needs to be 2048 or longer.
Unfortunately, DNS has fairly tight constraints on how many bits you can cram into a transaction, and 2048 bits isn't very practical. ECC uses much shorter keys, and while 160 bits isn't quite long enough, 255 appears to be really good, unless some improvement in the theory changes that.
But yeah, elliptic curve theory is a lot newer than factoring theory, and the risk of a theoretical breakthrough is a lot higher, though Moore's Law isn't much of a threat for a while. On the other hand, DNScurve uses ECC for transactions, not for long-term signatures, so there isn't the same One Big Target effect, since every DNS server is using its own different key.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Custom electronics and digital signage for your business: www.evcircuits.com
Pushing a new crypto algorithm that has not been extensively vetted is a usually a bad idea ... but if there's one person you can trust to pull it off, that's djb.
Here, DNSsec's RSA-1024 is the bad idea. We already know it's breakable to a determined enough attacker, now. And the prize is huge. What happened to the principle of having a significant margin of security? That's idiotic. I'm guesstimating wildly, but today a million-strong botnet could break it in months; in five year's time a 10-million strong botnet of low-end 16 core destops could do it in in days.
Or what's you definition of "tabular data"? Numerical spreadsheets?
Generic records have an awkward syntax, but they allow you to store any kind of record. If you don't like it, you can just write a single line perl script to preprocess it. I have 100 domains managed with tinydns, the "data" file was getting a bit big. So I broke it up in a few files, and then have a makefile to
* svn commit
* Cat it all together and
* preprocess it into "data"
* Run tinydns-data
* scp data.cdb to a number of secondary servers
* Delete data (so that someone doesn't mistakenly edit it)
Trust me, it beats the kludgy master/slave BS of bind.
The only limitation have encountered is when you want to let a user have access to only part of the data. It would require some programming to make sure they don't add data for domains they don't own.
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.
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.
Me I'd just use display: -moz-box; --moz-box-align: horizontal; and -moz-box-flex: 1;, but that's very much non-standard.
Thing is, even if it's not strictly speaking tabular data, it's not a case of tablesoup either.
I don't need svn to do that, I just use it to keep an history of the changes I made, and it's free to use since it's just included in the make process. Instead of signalling bind to reload, I type "make" instead, and it does much more, more predictively. /snark
And yes, I use scp, and make, and also bash and vi. Looook at meee! I use Haute Technology! My zone "transfers" are compressed, encrypted and authentified; I'm so spoiled!
You can't specify service dependencies in /service; but it's extremely awesome when you need to roll out a quick service. Last week I had to make sure an ssh tunnel stayed open, here's what it takes: /service
cat > run
#!/bin/sh
exec ssh -i key -L 4000:127.0.0.1:4000 user@host vmstat 30
^D
chmod a+x run
ln -s $PWD
Bang. It's done. Beat that.
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.
Assorted stuff I do sometimes: Lemuria.org
OK. Now that I have your attention, instead of "children" think of other small, computationally weak things ... like handhelds. ECC excels in lower computational cost over RSA. That is yet another reason, as everyone's day planner has a web browser which requires DNS. Want your iPhone's battery to drain less fast? Use ECC instead of RSA for your public key crypto of choice.
For that matter, DNSSEC should consider allowing ECC public keys. Then we would at least be debating the merits of the application of crypto in the protocols, not the crypto algorithms themselves (slashdot really isn't the place to debate that anyway).
libertarian: (n) socially liberal, financially conservative; neither left, nor right.
I'm trying to understand the "confidentiality" advantage of DNSCurve. I'm willing to cut Bernstein a little slack, based on his good security track record so far, so I want to try to understand what he's arguing for here, but I'm just not getting it. Why is it bad if the bad guys can find out what DNS records a certain domain server provides? Isn't the whole point of DNS to *publish* such information, i.e., make it widely available? Why would we want to keep it confidential? I thought we wanted to protect against forgery, not discovery. What am I missing?
Cut that out, or I will ship you to Norilsk in a box.
My daemontools script starts and maintains a port 4000 forwarding from localhost to 'host'. Yours starts the ssh daemon. Duh.