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.
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.
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
If you'll notice, that's glue for ns0, ns1, and ns2. This information from the parent is just there to say "here's where to go to resolve information from the child".
It's not the actual IP addresses for all the child data, like www.wikimedia.org.
DJB's basically saying "how can you say .org is signed when not every child in .org is signed". No delegated solution could ever offer that feature. If DJBCurve doesn't support signed and unsigned children, it's a thoroughly irrelevant technology that should be laughed out of the room.
Bashing DNSSEC for supporting a basic reality of delegated trust is flat out unfair.
Here’s what I think DJB is saying: It’s the IP addresses for ns0, ns1, ns2, and it’s published by the .org servers. Why not sign that information, even if the Wikipedia folks haven’t implemented DNSSEC themselves? I don’t think he expects the .org servers to sign information not published by them.
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...
Yes, in order to validate the chain of trust the TLD must be signed but sibling 2LDs have nothing to do with whether a particular 2LD can be signed. If wikipedia.org wants to sign, they can do so, because their parent (.org) is signed, but it doesn't matter whether widgets.org is signed.
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.
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.)
This is one person saying another person's claims about DNSSEC are not credible, in part based on benchmarking done in private. One of these people is a cryptography of world renown, the author of the mainstream DNS server with the single best security track record, and the holder of multiple crypto and encoding speed records. The other is a security researcher. Both are speaking in an area of claimed expertise. Their background is extremely relevant to evaluating their claims.
I don't understand how Kaminsky gets more attention. His "answer" to DJB gets attention in HN while the original presentation barely gets any. People will probably walk out with a very biased opinion.
You're making an apples-oranges comparison, as did Kaminsky. The threat models covered by Curve and SEC are totally different. That's the point I'm making.
Meanwhile: Kaminsky is stipulating that every endpoint is going to implement all of DNSSEC. So, furthermore: I don't think he gets to cite "overhead" as an issue with DNSCurve.
Er, DJB and I are both presuming endpoints will validate -- we're both end-to-end security people. And that's fine, it ain't 1983 anymore, and a device that can handle TLS can handle both DNSCurve and DNSSEC (remember, the crypto construct in Curve is only about 8x faster).
What I'm saying is that mass adoption of DNSCurve eliminates the caching layer in DNS, and that will cause a major increase in traffic to the authoritatives, especially TLDs and the root.
The notion of "endpoint validation" has an entirely different meaning in DNSCurve than it does in DNSSEC.
In DNSSEC, all the security resides in the actual DNS records. End-to-end security means verifying each step in the DNS chain, from .org through "www". This is the only way DNSSEC provides any value.
Unlike DNSSEC (shockingly), DNSCurve protects the actual conversation between a name resolver and a name server, irrespective of the RR's configured for a zone. DNSCurve (for the most part) does not care about your RR's. When one speaks of "end-to-end DNSCurve", one is talking about a hypothetical universe in which the root servers all the way down are speaking DNSCurve.
That world is never going to happen.
The point of DNSCurve is that it provides a degree of security --- by my reckoning, the most important degree --- even if the roots don't adopt DNSCurve. And in that universe, caching works just fine: DNSCurve is only going to be used to connect endpoints to caches.
But most people will not deploy a local dns{sec|curve} cache daemon, and use their ISP/OpenDNS/Google DNS instead, and caching is possible at this level instead, isn't it?
If each client endpoint were using a dns cache for classic DNS, the increase in traffic would also be a "concern", no?
Neither DNSSEC or DNSCurve are interesting if they're securing just IP addresses. So we both need code on the client, to link into certificate validation stacks and the like.
The difference is, when DNSSEC has code on the client, it can still leverage the caching infrastructure. When DNSCurve has code on the client, it has to bypass it entirely.
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.