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."
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?
by Anonymous Coward
on Tuesday December 09 2008, @05:18PM (#26052411)
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.
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.
I'm neither agreeing nor disagreeing with the technical merits; I'm pointing out a flaw in the political actions of this coalition. Commercial coalitions form when there's money at stake and very often the technical issues are rapidly effaced in favor of how much has been invested in a particular solution. Witness VHS v. Betamax. I'm saying that we (as internet users and administrators) should support an open and transparent process that involves all interested parties, and that all viable options are given
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?
Somewhere at the beginning of 2002, RSA labs. was already suggesting that 1024 bits keys was not big enough for root corporations and that they should already start using 2048 bits. Which makes it even worst...
If I remember right, a new computer in the ballpark of 300M would allegedgly be able to break a 1024bits key in a reasonable time by now. How much can a botnet represent ? Is it scaleable for this kind of work ?
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...
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.
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...
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.
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 b
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?
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?
That is very funny:) I installed djbdns when I was thinking of moving from Bind, and sheesh, it was just odd, and didn't work "right", and didn't support anything like AAAA records, or SRV records, or stuff. It's for people that are very conservative, and are running a Debian version from 1995.
Plus, the guy seems like a right cock, which in itself isn't a reason to not use his stuff. I'd just rather run a "logical" DNS server like BIND, with a daemon, and a set of config files, which supports recent devel
Too bad it does support AAAA records and SRV records.
No it doesn't. The official release, version 1.05 on his site [cr.yp.to], doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.
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.
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.
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.
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".
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).
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.
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.
...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.
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.
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
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 da
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.
Okay, so where can I find a patch to make glibc's stub resolver verify DNSSEC signatures, so that I can be pretected from my recursive resolvers? DNSSEC has been around for nearly a decade: surely someone's implemented this by now?
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.
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 hand
But if I'm running BIND on my local machine, it would be just as secure under the DNSCurve proposal as with DNSSEC.
If my organization has a central, recursive, trusted DNS server, then I'm just as secure under DNSCurve as with DNSSEC.
The only place DNSCurve loses if if I have a stub resolver pointing to an *untrusted* recursive resolver on another host, instead of running my own recursive caching resolver. So maybe I just shouldn't do that...
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.
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.
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.
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 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.
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.
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 shoul
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.
What a Coincidence! (Score:3, Funny)
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? (Score:4, Funny)
go figure...
Perhaps he should start his own separate Internet and be done with it. ;-)
Re: (Score:2)
So a government backed initiative supported by domain name vendors accounting for 65% of domain names and it says:
Dan Bernstein's push for DNSCurve might face an uphill slog.
I think that might be understating it a bit. If it's not, I'm joining Dan's fan club.
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,
Re:Slow down there (Score:5, Insightful)
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.
Parent
Re: (Score:2)
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.
I'm neither agreeing nor disagreeing with the technical merits; I'm pointing out a flaw in the political actions of this coalition. Commercial coalitions form when there's money at stake and very often the technical issues are rapidly effaced in favor of how much has been invested in a particular solution. Witness VHS v. Betamax. I'm saying that we (as internet users and administrators) should support an open and transparent process that involves all interested parties, and that all viable options are given
Re: (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?
Re: (Score:2)
Somewhere at the beginning of 2002, RSA labs. was already suggesting that 1024 bits keys was not big enough for root corporations and that they should already start using 2048 bits. Which makes it even worst...
If I remember right, a new computer in the ballpark of 300M would allegedgly be able to break a 1024bits key in a reasonable time by now. How much can a botnet represent ? Is it scaleable for this kind of work ?
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...
Parent
Re:Slow down there (Score:5, Insightful)
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.
Parent
Re:Slow down there (Score:5, Insightful)
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...
Parent
Re: (Score:3, Insightful)
Excellent point. I was focusing on transactions, not the keys. Thanks for pointing out my error.
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.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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 b
Re: (Score:3, Insightful)
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: (Score:2)
Re: (Score:2)
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?
That is very funny :) I installed djbdns when I was thinking of moving from Bind, and sheesh, it was just odd, and didn't work "right", and didn't support anything like AAAA records, or SRV records, or stuff. It's for people that are very conservative, and are running a Debian version from 1995.
Plus, the guy seems like a right cock, which in itself isn't a reason to not use his stuff. I'd just rather run a "logical" DNS server like BIND, with a daemon, and a set of config files, which supports recent devel
Re: (Score:2)
Too bad it does support AAAA records and SRV records.
No it doesn't. The official release, version 1.05 on his site [cr.yp.to], doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.
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.
Parent
Re: (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: (Score:3, Insightful)
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: (Score:2)
That would be the "after a decade" I was alluding to.
Re: (Score:2, Insightful)
Re: (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: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.
Parent
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.
Parent
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.
Parent
I have deep respect for DJB (Score:2, Insightful)
...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.
Re: (Score:2)
After the smashing success of Internet Mail 2000 [cr.yp.to] he would be a fool not to!
Re: (Score:2)
I don't think anyone's found a overflow in notepad either djb!
I wouldn't doubt it - try typing in "this app can break" (without quotes) or another string in that format. Save the file and reopen.
Don't throw the baby out with the bathwater (Score:4, Insightful)
Parent
Re: (Score:2)
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
George Bernard Shaw
Re: (Score:2)
I think he's released most of his stuff into the public domain, has he not?
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 da
Re: (Score:2)
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.
Okay, so where can I find a patch to make glibc's stub resolver verify DNSSEC signatures, so that I can be pretected from my recursive resolvers? DNSSEC has been around for nearly a decade: surely someone's implemented this by now?
Re: (Score:2)
I think you can use Unbound as a stub resolver.
Re: (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.
Easy (Score:2)
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 hand
Re: (Score:2)
But if I'm running BIND on my local machine, it would be just as secure under the DNSCurve proposal as with DNSSEC.
If my organization has a central, recursive, trusted DNS server, then I'm just as secure under DNSCurve as with DNSSEC.
The only place DNSCurve loses if if I have a stub resolver pointing to an *untrusted* recursive resolver on another host, instead of running my own recursive caching resolver. So maybe I just shouldn't do that...
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.
What's DNSSec going to cost us? (Score:5, Insightful)
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? (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]
Parent
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.
There's a reason we haven't implemented DNSSEC (Score:5, Insightful)
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 (Score:5, Insightful)
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? (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.
Re: (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.
Okay, you take your time with that. (Score:2, Insightful)
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 shoul
Re: (Score:3, Informative)