Dan Kaminsky responds (at length) to DJB's 27C3 DNSSEC presentation

[tptacek]

Three of Kaminsky's seven arguments in favor of DNSSEC rely on "Phreebird", a strange thousand-line proxy he wrote and is pushing heavily. Before relying on any property of Phreebird for the purposes of argument, Kaminsky ought to disclose the extremely poor quality of that code.

I don't mean "bad" in the sense of "probably riddled with exploitable vulnerabilities", although Kaminsky himself acknowledged a double-free a few days ago on Twitter.

I mean more basic things, like, line 455 of phreebird.c which reads an NBO integer off the wire and feeds it directly to calloc() and read() as if it was HBO, or "bad" in the sense of "will fail if a request ever gets split between two TCP segments", or any other number of badnesses.

It's not a crime to publish bad code (it is, in fact, very good thing to do so), but it's irresponsible to urge its immediate adoption or to use it to settle an argument without pointing out that "this really works only in a lab setting".

Unfortunately, Kaminsky posted the most spirited defense of DNSSEC in recent memory on the exact day of our all-hands meeting. I call shenanigans! DNSSEC is evil and Dan hasn't vindicated it; instead, he's taken a small issue (that of online signing) and blown it up way out of proportion. Suffice it to say that online signing isn't the biggest problem with DNSSEC.

[dakami]

Phreebird isn't production code. I've been telling people to use it for internal testing only -- and I've even got that into various articles.

What it does do is show what DNSSEC is capable of -- it's a way to separate fundamental limitations of the protocol (which do exist) from implementation faults (like the horrifying things you have to do to maintain DNSSEC with two year old DNSSEC code).

DJB's talk argues that a whole bunch of things are fundamental limitations of DNSSEC. It implies that it must be a offline signer. This is patently false. Actually, any system that supports offline signing can be an online signer, and Phreebird is an example of one.

I'd love to hear more about what you think the biggest problems with DNSSEC are. Perhaps this could inspire new features for Phreebird!

[gxti]

Phreebird isn't critical in any way to the arguments he makes, it's simply offered as an example of online signing with DNSSEC. It's right there in the first paragraph, mentioned alongside existing, well-known servers which are purportedly adopting more online-signing-like features.

[jrockway]

If there’s one truly strange argument in DJB’s presentation, it’s on Page 39. Here, he complains that in DNSSEC, .org being signed doesn’t sign all the records underneath .org, like wikipedia.org.

I'm not sure this is an argument against DNSSEC, it's more of an argument against DNSSEC's marketing. The DNSSEC folks like to say that DNSSEC is deployed to .org. Well, that's technically true, but since no .org domains are signed themselves, this claim is useless. DNSSEC provides no real security currently.

I watched DJB's talk and I thought the first half was mostly for entertainment, rather than detailed discussion of the weaknesses of DNSSEC.

[guan]

I think Kaminsky is misleading when he says “Wikipedia.org is a delegation, an unsigned one at that” and “Wikipedia’s IP addresses are not actually hosted by the .org server.” The IP addresses of Wikipedia’s nameservers are actually hosted by the .org server in the form of glue records. In this particular case, at least, wikipedia.org is not just a delegation, so there would be some benefit from the .org servers signing that information.

(I know that glueless delegations are common, I even use them myself. But Wikipedia’s delegation is not glueless. DJB does not like them: http://cr.yp.to/djbdns/notes.html)

  ; <<>> DiG 9.6.0-APPLE-P2 <<>> @a0.org.afilias-nst.info. wikipedia.org. ns +norecurs
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51490
  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
  
  ;; QUESTION SECTION:
  ;wikipedia.org.			IN	NS
  
  ;; AUTHORITY SECTION:
  wikipedia.org.		86400	IN	NS	ns2.wikimedia.org.
  wikipedia.org.		86400	IN	NS	ns0.wikimedia.org.
  wikipedia.org.		86400	IN	NS	ns1.wikimedia.org.
  
  ;; ADDITIONAL SECTION:
  ns0.wikimedia.org.	86400	IN	A	208.80.152.130
  ns1.wikimedia.org.	86400	IN	A	208.80.152.142
  ns2.wikimedia.org.	86400	IN	A	91.198.174.4
  
  ;; Query time: 46 msec
  ;; SERVER: 199.19.56.1#53(199.19.56.1)
  ;; WHEN: Thu Jan  6 10:05:40 2011
  ;; MSG SIZE  rcvd: 143

[mike-cardwell]

Did you mean to say that "no" org domains are signed? As far as I understood it, some are, but the vast majority aren't?

I'm not an expert in this stuff, but I thought that getting "org" it's self signed was a massive achievement because it now means that domains beneath "org" can be signed?

If I do an A record lookup of "baddata-a.test.dnssec-tools.org" it returns NXDOMAIN on my system which supports DNSSEC, and 75.119.216.30 on my system which doesn't...

[mike-cardwell]

A thouroughly good read. You should watch the talk that he's referering to before reading this first though:

http://www.vimeo.com/18417770

[alecco]

DJB > Kaminsky

DJB has some of the best cryptographic implementations out there while Kaminsky's only interesting work is actually someone else's (CVE-1999-0024).

[16s]

DJB's sha1 code won the Engineyard sha1 contest back in 2009. His code was 14 times faster than OpenSSL's sha1. They were testing 3,079,431,974 hashes/second.

http://cr.yp.to/nearsha.html

http://www.win.tue.nl/cccc/sha-1-challenge.html

[dakami]

For the record, I thoroughly doubt I was the first person to find that poisoning bug.

I sure as hell wanted to be the last one.

(I'm much prouder of getting DJB's fix in, than I am of finding the bug in the first place. The former took two days. The latter took six months, and convincing people DJB was right. Only now do I understand what sort of a hurdle that was.)

[daeken]

I'm no big Kaminsky fan, but Paketto Keiretsu is freaking awesome. A collection of simple tools, but all great ideas.

[gxti]

How about criticizing the article instead of the person? Hero worship gets us nowhere.

[borism]

so?

[aeden]

If you have any interest at all in encryption, authentication, security and/or DNS then this is one hell of a read.

[requinot59]

The point about the uncacheability of DNSCurve seems correct and a huge concern (http://dankaminsky.com/2011/01/05/djb-ccc/#caching).

[tptacek]

On the one hand, DNSCurve's cacheing impact is a big deal... on the other hand, every endpoint is going to run a full validating DNSSEC stack?

[beagle3]

Where can I find more DJB publications / activities? His cr.yp.to website doesn't seem to have been updated in ages.

[requinot59]

Recent talks (often with PDF slides) of DJB @ http://cr.yp.to/talks.html (scroll to end of page for latest).

[tptacek]

It's updated constantly.