LWN: Comments on "DNSCurve: an alternative to DNSSEC"

DOmain API hack

Jchassy — Mon, 12 Jun 2017 11:49:41 +0000

Here is a big google cloud API exploit. Also I am being hacking so hurry

DNSCurve: an alternative to DNSSEC

job — Tue, 04 Aug 2009 10:38:09 +0000

It's all nitpicking of course. "Most servers" is easily misread as many different server software products and not many different installations. It could have been clearer, that's all.

DNS is a system where flaws, like caching logic, easily can affect different implementations so it's important if the problem is with BIND or the DNS protocol. The BIND monoculture is a bit troublesome too, but that's another issue (I've used both TinyDNS and NSD in production but they all have issues of their own).

DNSCurve: an alternative to DNSSEC

Duncan — Tue, 28 Jul 2009 07:08:20 +0000

You're right here (AFAIK), which makes you effectively wrong above. BIND
/is/ the reference implementation. As such, a reasonably large segment of
the DNS server base is BIND based, and by percentage, it's even higher,
due to (as mentioned) MS, Apple, Cisco, probably other router/network
vendors such as Juniper, etc, all shipping reference implementation (aka
BIND) based code.

So yeah, including all the little shareware etc DNS implementations, plus
DJB's implementation, it's possible that the majority of implementations
numerically weren't affected (tho I'd doubt even that), but certainly, by
share, an overwhelming majority of users /were/ affected. And that's not
even counting all the stub resolvers, tho the exposure there was
effectively per-instance rather than per X-thousands. GLIBC, etc, all
that was affected, a good deal of the caching servers were affected, the
Linux based routers, most or all of them (including the non-glibc ones,
AFAIK) were affected, MS was affected there too, etc. So even those folks
depending on unaffected full resolvers were often at risk due to the stub
resolvers.

So a very large share of the Internet using public was affected at some
level, either from their full DNS server or at the stub-resolver (possibly
at multiple levels there too) level, with a good many affected at multiple
levels, initially.

This is why it was such a big deal. They say it's a big deal when you
actually know someone affected, but this was far larger than that, since
/most/ of the people /everyone/ knew, were affected at at least one level,
many at multiple levels. The SDC and WHO are predicting something like
30-40% swine flu coverage within two years if the vaccines don't stop it.
Luckily it's not fatal for most, just seriously uncomfortable for awhile,
and fatal for a few. (Some have theorized that's one of the reasons it's
pandemic, people aren't actually dying, and are apparently still
contagious a week after they're feeling better, thus allowing it to spread
much more efficiently while bumping down the urgency of guarding against
it.) That makes it a reasonable analogy for the Kaminsky DNS issue, but
bump those rates to 80-90% exposure, possibly more (I actually saw a
figure of 97% somewhere, again, considering all levels, so 80-90% may be
conservative), and that's what they were looking at. That's not just big,
it's apocalyptic in scale, so big that even a single percent kill rate is
a very large number of people!

DNSCurve: an alternative to DNSSEC

eupator — Sun, 19 Jul 2009 07:10:51 +0000

The qmail guarantee was claimed as well, years ago. DJB just didn't pay. His argument was that the exploit can be prevented if rlimit is used to limit the process virtual memory to 4 GB, which he argues should always be the case, and so the bug is not a real security hole.

Never mind that qmail didn't set such a resource limit (and still doesn't), requirement to do so by hand was not documented (and still isn't), and no one generally does so, as you can verify by running 'ulimit -v'.

DNSCurve: an alternative to DNSSEC

job — Fri, 17 Jul 2009 22:50:22 +0000

As far as I know, they are. Apple ships BIND mostly as-is, Microsoft at least their 2000 product is clearly BIND 4-based, Cisco wouldn't surprise me if they too started out with it. It was more or less the reference code for DNS.

DNSCurve: an alternative to DNSSEC

forthy — Thu, 16 Jul 2009 08:47:03 +0000

I don't know what the original poster does want to explain, but here's my take:

DNSCurve protects the communication with the authoritive DNS server. I.e. if you do a fully recursive query, you get an authoritive and protected answer. However, that is not how DNS is supposed to work. DNS is usually implemented as distributed cache - you ask your lokal DNS cache, which forwards unknown queries to the provider's cache, which in turn does recursive queries when necessary. This model takes a lot of load from the root servers, though breaking the provider's cache with censorship and other net-nanny-like government regulation will cause more people to implement their own recursive querying DNS server. If everybody does, because DNSCurve requires that, .com would not have 5 million clients per day, but 500 million clients. And an awful lot more queries.

This distributed cache is the model DNSSEC supports - by presigning the records. DNS records have a TTL, so "replay attacks" aren't attacks, anyway (they are part of the design of the whole DNS system!). You have to wait for the TTL to expire before you can be sure that record changes have propagated.

Completely unrelated is that ECC is a better asymmetric encryption system than RSA; but as usual, "just good enough" plus network effects is what wins.

DNSCurve: an alternative to DNSSEC

dlang — Wed, 15 Jul 2009 01:05:40 +0000

so educate us rather than just making a statement like this

also, just because neither one is a complete superset of the other doesn't mean that it isn't a case of either/or

I don't think that I've heard anyone advocating using both.

DNSCurve: an alternative to DNSSEC

marka — Wed, 15 Jul 2009 00:57:32 +0000

DNSCurve and DNSSEC DO NOT address the same issues. Only someone that doesn't understand the strengths and weakness of both would see one as a replacement for the other.

DNSCurve: an alternative to DNSSEC

foom — Mon, 13 Jul 2009 15:00:40 +0000

Just call it 0x76d06 and all will be well. :)

DNSCurve: an alternative to DNSSEC

alankila — Mon, 13 Jul 2009 12:48:32 +0000

The elliptic curve is defined on function y² = x³ + 486662 * x² + x. Since it contains the number of the beast, and everyone will need to use this number before they can do commerce on the internet, I predict that this technology will not be adopted.

Fedora 11 uses DNSSEC by default

rahulsundaram — Sun, 12 Jul 2009 09:26:49 +0000

http://fedoraproject.org/wiki/Features/DNSSEC

It would be interesting to see how this plays out in the future

Patents and the brokeness of them

smoogen — Fri, 10 Jul 2009 20:38:06 +0000

Sadly the patent system does not seem to work that way. One of the big ways to make a patent infinitely long is to add an 'invention' to an existing patented item. The first patent may expire but your additional patent still covers the method where it relates to your extension of the invention. Rinse and repeat.

And the one issue is that while many developers will say "oh we aren't in the US so we do not have to worry..." they forget about reciprocal treaties their nation may have signed with the US which basically covers their works anyway :(.

DNSCurve: an alternative to DNSSEC

incase — Fri, 10 Jul 2009 09:27:37 +0000

At least in the USA, you mean....
Bad enough though...

DNSCurve: an alternative to DNSSEC

djao — Thu, 09 Jul 2009 15:42:40 +0000

Disclaimer: I am a researcher working on ECC.

I have no evidence, but my informed opinion is that more people are working on ECC than RSA these days. Even though RSA has been around longer, the unexplored territory for ECC is larger, and researchers tend to concentrate on unexplored areas.

To give one example, the best known attack on ECC can be implemented in about 20 kilobytes of code, whereas the best known attack on RSA requires about 3 megabytes for a typical implementation. (You might complain that it's unfair to compare a high level language to a low level language, but the language difference is actually part of my comparison -- the NFS attack on RSA does not benefit from high-level abstraction, whereas the Pollard rho attack on ECC does.) Putting yourself into a researcher's shoes for a moment, if you had to pick an area for research, knowing that it takes one day to learn how to attack ECC and three months to learn how to attack RSA, and keeping in mind the publish or perish environment of research, which would you choose? In my view it is not really true that making progress on ECC is any harder or more inaccessible than making progress on RSA, and indeed the contrary seems to hold.

Regarding your comment that "RSA is used for practically everything" and that "popularity is damn important", it is true on PC platforms that RSA is much more popular. The situation changes completely, however, when you consider mobile phone platforms, which are computationally constrained and in many cases require ECC. RIM recently bought Certicom (an ECC company), and prior to that had been licensing Certicom technology for many years. Microsoft's smartphones use ECC exclusively as well. I might also point out that the number of mobile phones in the world far exceeds the number of PCs. Again, I have no hard numbers, but I would not be surprised if ECC deployments outnumbered RSA once mobile phones are included.

DNSCurve: an alternative to DNSSEC

elanthis — Thu, 09 Jul 2009 15:00:10 +0000

I have to wonder if ECC has stayed secure solely because it's not interesting to try to hack it since RSA is used for practically everything. I'm sure researchers worked on cracking ECC techniques, but I'm willing to bet far, far less researchers looked into ECC than looked into cracking MD5 or SHA-1 or RSA cryptography.

Popularity is damn important with cryptography. 100 peers are more valuable than 10 peers reviewing a technique because it increases the chances of getting a peer who gets the rare stroke of luck/genius to find the hole.

DNSCurve: an alternative to DNSSEC

charlieb — Thu, 09 Jul 2009 14:30:31 +0000

I think you are confusing the qmail guarantee with the djbdns guarantee:

http://news.ycombinator.com/item?id=502651

DNSCurve: an alternative to DNSSEC

jake — Thu, 09 Jul 2009 14:00:14 +0000

> To say that "most other DNS servers" needed patching is a bit of an
> overstatement, it was mostly (only?) BIND and its derivatives that did.

Hmm, if you are only talking about free software DNS servers, then maybe.
But there was the whole "coordinated vendor response" that patched numerous
vendor DNS implementations on the same day. Apple, Microsoft, Cisco, et al.
all patched their (presumably not all BIND-derived) DNS servers.

jake

DNSCurve: an alternative to DNSSEC

nix — Thu, 09 Jul 2009 13:59:41 +0000

Yes, sure... by which point you've already experienced chilling effects from months to years of patent uncertainty, and probably heaps of legal expenses too. Patent attacks work even if the patent is grossly bogus :(

DNSCurve: an alternative to DNSSEC

job — Thu, 09 Jul 2009 13:27:59 +0000

To say that "most other DNS servers" needed patching is a bit of an overstatement, it was mostly (only?) BIND and its derivatives that did. Most other software already did the port randomization. It is fair to credit Bernstein with work on this solution however.

DNSCurve is interesting, and there is no doubt it is better designed than many of the alternatives. But I believe it is ten years too late to change DNSSEC. At least two country level TLDs are already fully rolled out, and many more (including .org) is in a testing stage. Here in .se, many of the large ISP's resolvers validate signatures and there is a small but growing customer pressure to support "safe names on the net" toward the rest.

Halting this train when it works in practice would be difficult. The important thing is that we get signatures in DNS, and that we get it soon.

DNSCurve: an alternative to DNSSEC

droundy — Thu, 09 Jul 2009 13:22:21 +0000

But if the algorithm was published 25 years ago, even if there is a more recent patent, it will be trivial to find prior art that even the dullest judge ought to recognize.

DNSCurve: an alternative to DNSSEC

nix — Thu, 09 Jul 2009 10:57:59 +0000

DJB's patents page has at least one example of something described in 1976 being independently reinvented and patented in 1990... so mere age won't prevent yet more patents popping up.

DNSCurve: an alternative to DNSSEC

pkern — Thu, 09 Jul 2009 08:57:58 +0000

Actually the qmail security guarantee was claimed in the meantime.

DNSCurve: an alternative to DNSSEC

Tobu — Thu, 09 Jul 2009 08:15:37 +0000

A few criticisms of DNSCurve from Stéphane Bortzmeyer's blog:

The encryption algorithm is hard-coded in the protocol. Not many algorithms are suitable due to limits on record length.
DNSCurve secures the conduit, not the message. It can't be used to protect against malicious caches, and isn't a functionnal equivalent to DNSSEC.

DNSCurve: an alternative to DNSSEC

dlang — Thu, 09 Jul 2009 05:45:49 +0000

one good thing about using an algorithm as old as ECC is that any patents that may exist should be hitting teir 20 year lifetime and expiring soon (if they haven't already)

those who remember the RSA patents expiring will remember that there was a lot of use of the algorithms prior to the expiration, so when the magic day finally hit the software was well tested and ready for widespread use. it will take a while for people to get comfortable with the idea of doing that much encryption, so I expect that patents shouldn't be that bad a problem.

at least this time djb is advocating a protocol specification rather than just a specific implementation. that should avoid a lot of the problems that people (including me) have had with his stuff in the past

as for the idea of DNSSEC being safer due to the encryption keys being on another box, people who are interested in doing that sort of thing right will buy hardware encryption accelerators that isolate the key from the system, and almost everyone else will have their keys on the servers so that they can update things easily. so I don't see it as a very singnificant difference in risk.