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.
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!
Tell me something. In the world we live in now, with 10's of well-known mainstream CA's, I see an SSL certificate warning on an otherwise totally OK site about once a month. DNSSEC supposes a world in which everyone runs their own CA; in other words, a world in which there are tens of thousands of CA's.
Where, in that function, do I (a) detect a DNSSEC failure, (b) propose to the user the untrustworthy - but - probably - totally - valid address we got instead, and (c) pop up a dialog to the user to allow them to decide whether to connect? Or, instead, does all this deployed code fail in exactly the same fashion as if the host didn't exist?
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.
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.