Slashdot Mirror

I'm surprised there is no standard for encrypted DNS yet, can someone explain why it isn't a thing?

Isn't that what DNSCurve (http://dnscurve.org/) is about?

Good point; There are implementation techniques and specific curves which are patented and it is possible to make an implementation that is not patented. For example: http://dnscurve.org/crypto.html

If there's a USA wish/murmur to combat bad things on the internet, why not pull another Tor and fund development of things like DNCCurve/CurveCP through this?

Right. You'd want to many the same query to many peers, and compare the results. Due to the expense of this, you'd want to heavily cache responses and always be re-querying hostnames in the background if you want to honor the original TTL.

Any idea if something like DNS Curve could be useful here? It relies on the domain/zone owner to have a private key.. I don't see how you could ensure the integrity of a DNS response, unless the P2P network simply routed your queries to the domain/zone owner's nameservers.

DNSCurve looks pretty sweet; especially how it encrypts packets, instead of just signing them (like DNSSEC). Hiding the query and response seems very useful to avoid prying eyes.

In case anybody else did not know what an amplifier attack is:

http://dnscurve.org/amplification.html

Only if the answer does not change. If the answer changes, somebody who can view your traffic can replay old responses.

DNSCurve does not have this problem.

http://dnscurve.org/replays.html

Hopefully you've looked over dnscurve

I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html

DNSSEC certifies the data, while DNSCurve only certifies the connection between the DNS server and the resolver.

With DNSSEC, you know that the DNS records you receive are correct.

With DNSCurve, your ISP's caching resolver knows that it is talking to the proper DNS server. You do not know that you are talking to your ISP's resolver instead of an imposter, and you do not know if your ISP is forwarding the records accurately.

DNSSEC can be used for interesting things like distributing public keys. DNSCurve cannot, because it still requires you to trust your ISP and your ISP's network. (Or alternatively it would require that shared caching resolvers not be used, which would cause a major increase in traffic to the authoritative servers.)

I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html

We need a 'djb' tag. Dan's been talking about, and working on this kind of thing for years.

If 'this kind of thing' means DNSCurve rather than DNSSEC then sure, you are dead on! But rather we can see that DNSCurve != DNSSEC. DJB is, as usual, thinking that his idea's are better than an entire consortium and I'm sure that we will see him continue to break RFC at his whim because he simply does not understand, he thinks that he is better than others or some magical being had tapped him on the shoulder. Maybe you should take a trip back in a TARDIS to last year?.

I know... I know, don't feed the trolls.

DNSCurve and DNSSEC have complementary security goals. If both were widely deployed then each one would provide some security that the other does not provide.

According to their site, it would be possible to just put a DNSCurve cache in front of your authoritative DNS server and not need to change the latter at all.

DNSSEC rely on having a central "trusted" authority to sign all the dns keys. Not even speaking about the inherent security issues with this model, that means that everyone will depend on a single authority for name resolutions (sure Network Solutions loves this)

DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.

See http://dnscurve.org/index.html

I personally find djbdns easier to use and less error prone than BIND for most stuff ( http://cr.yp.to/djbdns/blurb/easeofuse.html ).

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

I might recommend looking further into this "new crypto" business.

Here are a couple links in case they're hard to find:

1. http://dnscurve.org/dnssec.html
2. http://dnscurve.org/crypto.html

Just in case it's also hard to follow links, here's some selected text:

IEEE P1363 standardized elliptic-curve cryptography in the late 1990s. NIST standardized several elliptic curves following the P1363 recommendations. In 2005, NSA issued a new "Suite B" standard, recommending the NIST elliptic curves (at two specific security levels) for all public-key cryptography and withdrawing previous recommendations of RSA.

I might recommend looking further into this "new crypto" business.

Here are a couple links in case they're hard to find:

1. http://dnscurve.org/dnssec.html
2. http://dnscurve.org/crypto.html

Just in case it's also hard to follow links, here's some selected text:

IEEE P1363 standardized elliptic-curve cryptography in the late 1990s. NIST standardized several elliptic curves following the P1363 recommendations. In 2005, NSA issued a new "Suite B" standard, recommending the NIST elliptic curves (at two specific security levels) for all public-key cryptography and withdrawing previous recommendations of RSA.

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSSEC is currently deployed live in multiple countries, .gov and .arpa are now signed (but only for testing purposes at the moment). Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly better in order to garner support at this stage, and I'm not seeing it.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.

DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.

If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC, .gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse .arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.

Rubbish. Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it. Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

Actually, there are a lot more than two major holdups:

1. DNSSEC is slow. It makes your nameservers vulnerable to denial-of-service attacks
2. DNSSEC is incompatible with many firewalls; publishing DNSSEC will make you invisible to some sites
3. DNSSEC is very complicated. It's very hard for nameservers that aren't based on BIND to implement it. I should point out that the nameservers that aren't based on BIND have actually been practically immune to the recent DNS attacks...
4. DNSSEC requires administrators change their behavior significantly. This means retraining and reimplementation of many processes
5. DNSSEC requires cooperation from all the parents, not just the roots.
6. DNSSEC requires that clients reject unsigned data

The list goes on. There is another way, but because the BIND company controls a root server and has voting powers, and "because we've already invested so much in DNSSEC", it's unlikely the deadlock will be broken: DNSSEC will continue to suck so badly that nobody will want to use it, and other systems will be blacklisted because they're not DNSSEC.

Hesitant? Hesitant!?

Look, this isn't a bunch of ninnies holding back progress. DNSSEC is a replacement for DNS. It always has been, and for some god awful reason it's taken its architects over a decade to get nowhere. Deploying DNSSEC gains you nothing and costs you a lot: You have install costs, heavier hardware, changes to your internal infrastructure- those are the obvious ones-then you've also got the fact that the DNSSEC tokens will get your DNS packets stripped by some firewalls which means you disappear from the Internet- and this is my favorite, DNSSEC actually reduces security by making it easier to launch denial of service attacks on you.

Meanwhile, competing systems are rebuffed as "we've already invested all this time into DNSSEC".

If so, inventing some other more secure upgrade to DNS really is a waste of time (unless it's somehow easier to adopt than DNSSEC).

Like for example, dnscurve, which requires very little effort to set up, is actually backwards compatible with DNS, protects against some denial of service attacks (instead of creating them), and oh yeah doesn't require the cooperation of the parent zone.

DNSSEC is a joke. A bad bad joke. Replacing DNS with something not-DNS isn't any better an idea than replacing the Internet with something not-Internet. It's 2008 and there are still sites without MX records. You simply cannot "replace" all of the Internets all at once. It just doesn't work. Someone needs to take away the ISC's talking privileges until they stop fucking things up.

Is DJB's DNSCurve a viable solution?

As an ISP, I'd happily implement a secure DNS protocol if there were one - right now the closest thing is DNSCurve, but it seems that the asshats that created the problem- are prone to continue promoting a "solution" that requires more powerful hardware, puts servers and clients at a greater risk for denial-of-service attacks, and frankly doesn't work.

DNSCurve seems very attractive, but would require cooperation from the root servers- some of which have a vested interest in promoting the unworkable and broken-by-design DNSSec protocols.

Meanwhile, DNSSec, in addition to requiring cooperation from the root servers, also requires that every firewall; every dns client and server, and every dns-inspecting or dns-aware device get rewritten- or potentially rewritten because DNSSec is incompatible with DNS.

The people dragging their heels here are the BIND group. They want to promote a buggy and broken solution just like they always do simply because it's their solution.

http://dnscurve.org/index.html

DJB's take on it, although it's gone quiet...

Note that DNSCurve and DNSSEC solve different problems. DNSCurve secures that communication channel, where DNSSEC secures the actual data.

Look at this comparison. DNSSEC doesn't provide any confidentiality, but DNSCurve and DNSSEC both (theoretically) provide data integrity- the securing of the data- it's just that DNSCurve does it better.

DNSSEC has one benefit (in my mind), and that's that DNSSEC turns a MITM-attack vector into a "mere" denial-of-service attack (see Integrity despite corruption of one's own computers). This seems contrived to me, being as how sites big enough to be interesting targets for this kind of attack, could detect the failure trivially.

dnscurve

Note that DNSCurve and DNSSEC solve different problems. DNSCurve secures that communication channel, where DNSSEC secures the actual data.

I'm definitely no security specialist, but I would reckon that securing the data is more useful, while securing the channel is easier, and hence has a greater chance of actually being deployed.

Compare this to the e-mail situation. PGP secures the actual mail message, while SMTP over SSL secures the communication channel. SMTP over SSL is widely deployed, while PGP is unknown outside of some geek circles.

DNSSEC is a protocol similar to, but not compatible with DNS. It is difficult to deploy and requires much more powerful hardware than current DNS servers otherwise require. DNSSEC offers no security guarantee unless DNS is completely replaced with DNSSEC.

dnscurve, on the other hand, is fully backwards compatible with DNS, would be dead-simple to deploy, requires a fraction of the computing power than DNSSEC requires, and it can be deployed incrementally.

Yes, but they solve slightly different problems. Basically, DNSCurve is point-to-point and DNSSEC is end-to-end. This distinction is very important to keep in mind, since DNS resolution often goes through multiple "middlemen", some or all of which you may not particularly trust.

There is a decent page on the site you linked, highlighting the differences between the two solutions: http://dnscurve.org/dnssec.html

I'm not here to give DJB a handjob, but I do think his idea of DNSCurve is quite brilliant.

http://dnscurve.org/