26

Looking at all the people who question the viability of DNSSEC, it's no wonder that the adoption rates are so poor.

However, what about DNSCurve? It supposedly fixes all the DNS security and privacy problems independent of DNSSEC, doesn't suffer from the problems that are specific and unique to DNSSEC, and, should one disregard the maturity of either approach, seems to be a clear win for the situation — yet even though it's much-much younger than DNSSEC, there are still practically no implementations for DNSCurve, other than djbdns and DNSCrypt support by OpenDNS. Why?

Community
  • 1
cnst
  • 1,884
  • 2
  • 19
  • 30
  • IMO what we need a protocol that combines the advantages of DNSSEC and and DNSCurve. The confidentiality and performance (CPU cost, size overhead, anti amplification) of DNSCurve and the the signature chain concept from DNSSEC. – CodesInChaos Nov 20 '13 at 09:58
  • 3
    Also, that link that "explains" how DNSCurve solves all the problems DNSSEC suffers from? A list of papers by djb written in what certainly sounds like his trademark "my way is obviously superior and everyone who does things different from me is either stupid or letting their ego get in the way of common sense - unlike me, of course; I don't have an ego, I'm just that good. And if you don't like it, screw you" style that's probably done more to retard adoption of his various contributions than relative merits. – Shadur Nov 20 '13 at 12:06
  • 6
    Technical merits aside, the answer can be boiled down to "Paul Vixie introduced DNSSEC, and Dan Bernstein introduced DNSCurve." – gowenfawr Nov 20 '13 at 12:22
  • 4
    [Yes, we need to develop one universal standard](http://xkcd.com/927/) – jackweirdy Nov 20 '13 at 12:54
  • 5
    DNSSEC was designed by the DNS people to do security in a way that is compatible with all of DNS's goals. DNSCurve was designed smart researcher with a strong personality to do security in a way that makes more sense to security people, and less sense to DNS people. – tylerl Nov 20 '13 at 18:21
  • @tylerl, By that, are you saying that you are supporting the DNS guys or the researchers? – Pacerier May 22 '15 at 04:51
  • @Pacerier neither. I'm not taking sides, I'm just telling you what the two opinions are. – tylerl May 22 '15 at 07:51
  • @tylerl, Which do you think is the way forward? – Pacerier May 22 '15 at 10:57
  • 1
    @Pacerier Each has its purpose. One guarantees the integrity of the conversation, and the other guarantees the correctness of the data. It's like how, TLS guarantees that your connection to Gmail is secure, but it doesn't guarantee that the email you read there is truthful. DNSSEC can guarantee truthfulness, but thats about it. Ultimately I think DNSSec is more urgent because it could readily replace our horribly broken TLS PKI, while nearly the entire benefit of DNSCurve can be achieved with a VPN to your DNS server. – tylerl May 23 '15 at 03:16
  • @tylerl, regarding your "VPN to your server" comment, it sounds like you're thinking DNSCrypt, which is merely an application of DNSCurve; DNSCurve by itself, if you're running a recursive resolver, does in fact guarantee the integrity of the conversation – cnst May 23 '15 at 08:15
  • @cnst Sort of. DNSCurve (and yes DNSCrypt) provides confidentiality and integrity of the conversation, but not the content. Just like a VPN. If the party you're communicating with is authoritative and trustworthy, then you've got something. Again, just like a VPN. But this is still a fundamentally different story from DNSSEC, which can guarantee trustworthy results irrespective of the trustworthiness of all the world's individual ISPs running recursive resolvers. – tylerl May 23 '15 at 08:43
  • @cnst With DNSCurve, your results are not guaranteed, even if you run your own recursive resolver. All a MITM actor (e.g. a greedy ISP or an oppressive nation-state) needs to do is intercept and modify the NS records ostensibly coming from the TLD servers. By manipulating the nameserver names, they control the DNSCurve keys, and can trivially direct traffic to their own poisoned servers and distribute modified but still "authenticated" records. There no chain of trust with DNSCurve, and therefore there is no content integrity. – tylerl May 23 '15 at 08:50
  • 1
    @tylerl, what do you mean there's no chain of trust? what's to prevent you from providing nameserver names in the root zone files etc. – cnst May 23 '15 at 09:02
  • @cnst That's explained in my answer and my previous comment. A mitm can change the response to the root/TLD query, and there's no way for you to know. – tylerl May 23 '15 at 19:26
  • See also the use-case of DNSCrypt (which is a bit different and - IMHO - superior than DNSCurve): https://dnscrypt.org/#deployment There you have some nice ASCII diagrams showing that DNSCrypt & DNSSEC can certainly work together very well. – rugk Jul 07 '16 at 14:30

2 Answers2

51

There's a problem:

DNSCurve is more like TLS for DNS servers, in comparison to DNSSEC, which is signed records. DNSCurve uses point-to-point cryptography to secure communication, while DNSSEC uses pre-calculated signatures to ensure the accuracy of the supplied records.

So we can summaraize it like this:
DNSSEC: Accurate Results
DNSCurve: Encrypted Traffic

Theoretically you can use traffic encryption to ensure accuracy, the way TLS does for websites. Except that it's not really the encryption that's ensuring your accuracy, is the authentication provided through the PKI. And there's a set of critical problems with the basic DNSCurve PKI.

The first problem here is that with DNSCurve, each and every DNS server involved needs a private key, and since the key signature is encoded into the resolver's address, then in the case of anycast DNS servers, each server needs the same private key. But even if they use different keys, you're still trusting the local security where the DNS Server is installed. If the server is installed somewhere hostile, then the results can be compromised. This is not true with DNSSEC.

ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will not be implemented, ever. Many of the root servers operate in less-trusted locations, and the potential for abuse by local governments would be enormous. This is precisely why DNSSEC was designed such that signing happens outside the DNS server. DNS relies on a vast network of server which may not be individually trustworthy, so DNSSEC was designed such that the trust is based solely on the information they serve, not the honesty of the operator.

The second problem is that DNSCurve secures the public key by encoding it into the resolver name. But DNSSEC does not sign the resolver name. This means that DNSSEC (which is implemented in the root zone) cannot be used as a trust root for DNSCurve, because the one thing that DNSCurve requires to be accurate is in fact the very thing for which DNSSEC cannot ensure accuracy.

So essentially DNSCurve is pretty much a non-starter. While it can be used to guarantee the security of your communication with a single DNS resolver, there currently is no way of globally anchoring your trust in a way that could guarantee the accuracy of any results you retrieve.

Unless DNSCurve is re-designed to allow for trusted key distribution, it will have to remain a client-side security tool rather than a tool for ensuring the authenticity of DNS records.

Since DNSCurve is relatively new and was developed largely by djb in isolation, presumably these show-stopping issues were simple oversights on his part, and may be fixed at some future date. Though given Dr. Bernstein's track record of maintaining his inventions, I wouldn't hold my breath.

ckujau
  • 267
  • 1
  • 6
tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 8
    djb also suffers from a severe "my way or the high way, and if you've got a problem with that, screw you" attitude which tends to severely slow the adoption of any of his works, regardless of their merit. – Shadur Nov 20 '13 at 12:03
  • 3
    @Shadur: While that is true (and on top of that, DJB suffers from a seriously-unmaintainable-unreadable-code problem and some other problems) it is undeniable that DJB's stuff works, and works amazingly well. I've rarely seen software which is so much rubbish at first sight and so much ingenous at second sight as his stuff. Which distinguishes him from 1 million lamers who have the same attitude but _don't_ produce stunning stuff. – Damon Apr 14 '14 at 14:07
  • @damon Unfortunately at this point the vast majority of the people who've had to deal with him have pretty much decided that it doesn't *matter* how good his software is if the price for using it is dealing with DJB. And perhaps that's for the best -- if his code's that unmaintainable for anyone who isn't him, what'll happen when he stops maintaining it? – Shadur Apr 14 '14 at 14:10
  • @tylerl, So [how is OpenDNS](https://blog.opendns.com/2010/02/23/opendns-dnscurve/) affiliated to djb? – Pacerier Feb 16 '15 at 19:31
  • @Pacerier they use a protocol he designed. Their focus and value proposition is also very different from the people who run the root zones. – tylerl Feb 16 '15 at 19:40
  • @tylerl, You might want to elaborate on why you stated that djb has a bad track record of maintaining his inventions.. – Pacerier May 22 '15 at 04:33
  • @Pacerier *Really?* How about qmail, djbdns, and daemontools, and just to name a few. By contrast, NaCl is actively maintained, but only because it's maintained by other people. Can you give a single example of *anything* djb has released and actively maintained? Even one? – tylerl May 22 '15 at 04:43
  • @tylerl, I'm saying readers might need more context. Because while the software djbdns is *pretty* famous, djb and his other projects aren't that well-known. – Pacerier May 22 '15 at 10:57
  • @Pacerier Bernstein has a long and proud history of creating really well-written software (djbdns, qmail, etc.) but releasing it with a license that does not allow derivative works (so the community is not allowed to maintain them) and then abandoning them. He has since released is most popular works into the public domain, so people can maintain them now if they want. But he's not interested in putting any more time into them. – tylerl May 23 '15 at 03:24
  • well, basically, for DNSCurve to work, you have to run a DNSCurve-enabled resolvers from the top; since noone's going to stop running bind, and DNSCurve is unlikely to make it into BIND, it's not like you can get away without running the DNSCurve-aware authentic resolvers in parallel. – cnst May 24 '15 at 03:04
  • You write that "DNSSEC does not sign the resolver name." But if the parent zone is DNSSEC-enabled, the DNSCurve-signed zone's NS (delegation / resolver name) e.g. example.org NS uz5svv9j6p8j05ms321fjtdms06tw23uv5ck1n2650847c8t29up49.ns1.example.org is signed. You may be thinking that the A/AAAA records for uz5... is not signed within the parent zone (in fact, DNSSEC specifically requires that glue must not be signed), but the public key is embedded in the name itself, so that even an attacker who forged glue or otherwise poisoned the A/AAAA data would still need the private key. – Alex Dupuy Dec 11 '15 at 21:03
  • @AlexDupuy Here's the answer to your question delivered by someone more authoritative than me: https://youtu.be/eOGezLjlzFU?t=47m3s (feel free to watch the rest of the video for more context). – tylerl Dec 13 '15 at 20:00
  • You're right, thanks, I was confused by the fact that the NS record in a DNSSEC-signed child zone *is* signed, and other references to "glue records should not be signed by DNSSEC in parent domain" (typically glue refers only to additional A/AAAA records, but in this case includes the NS records themselves). – Alex Dupuy Dec 14 '15 at 19:34
  • Can you explain 'Many of the root servers operate in less-trusted locations, and the potential for abuse by local governments would be enormous.'? Isn't it the root servers that sign the DNSSEC records? Plus with regular DNS we are trusting the root servers anyway... – quantumtremor Feb 18 '17 at 13:03
10

The major reason is that DNSSEC was already being adopted by the major root servers when DNSCurve came out. Furthermore they do not tackle the same problems, they overlap on some points but differ on others. They could very well be used together.

Note that we have had a question DNSSec (Comcast) vs DNSCurve (OpenDNS) which details the differences very well:

First of all, DNSSEC does NOT sign your queries. Rather DNSSEC allows a zone (such as a domain) to be signed by its owner, and allows a resolver (for instance, Comcast's DNS servers) to verify the signature, and therefore be sure that the zone data it gets is authentic. It protects the resolver from receiving bad data, but does nothing to prevent MITM or snooping between you and the resolver.

DNSCurve on the other hand encrypts communications between recursive resolvers and authoritative servers and allows authoritative servers to sign their data against forgery, but does nothing to protect an end-user client from a bad recursive resolver. OpenDNS's DNSCrypt solution is based on the same technology as DNSCurve, but protects the last-mile between a trusted 3rd party recursive resolver like OpenDNS and the end-client.

As for which is more secure, neither is. They are both secure, however the security is applied in different areas. In either case you are picking which aspect of DNS security is more important, rather than which security tool is stronger.

Community
  • 1
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196