6 ms·
Dan Kaminsky responds (at length) to DJB's 27C3 DNSSEC presentation
- jrockway 16y agoIf 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.
- mike-cardwell 16y agoDid 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...
- gxti 16y agoYes, 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.
- guan 16y agoI 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 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
- dakami 16y agoIf 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.
- guan 16y agoHere’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.
- mike-cardwell 16y agoA thouroughly good read. You should watch the talk that he's referering to before reading this first though: http://www.vimeo.com/18417770 http://www.vimeo.com/18417770
- deleted 16y ago[deleted]
- aeden 16y agoIf you have any interest at all in encryption, authentication, security and/or DNS then this is one hell of a read.
- alecco 16y agoDJB > 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).
- borism 16y agoso?
- alecco 16y agoI 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.
- borism 16y agowell, if true, then that is a problem of HN, not DJB or Kaminsky's. but I think you have wrong metrics for "attention" or "relevance" in the first place.
- daeken 16y agoI'm no big Kaminsky fan, but Paketto Keiretsu is freaking awesome. A collection of simple tools, but all great ideas.
- 16s 16y agoDJB'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://cr.yp.to/nearsha.html http://www.win.tue.nl/cccc/sha-1-challenge.html http://www.win.tue.nl/cccc/sha-1-challenge.html
- tptacek 16y agoThat's far from the only speed record he's set; among other things, he's also held the record for the fastest AES implementation and the fastest FFT.
- shooll 16y ago( http://www.findsoso.com http://www.findsoso.com / ) (( http://www.findsoso.com http://www.findsoso.com / ) We need your support and trust!!! Dear friends, please temporarily stop your footsteps To our website Walk around A look at Maybe you'll find happiness in your sight shopping heaven and earth You'll find our price is more suitable for you. Welcome to our website ( http://www.findsoso.com http://www.findsoso.com / ) Thanks to the support! ( http://www.findsoso.com http://www.findsoso.com / ) ( http://www.findsoso.com http://www.findsoso.com / ) ( http://www.findsoso.com http://www.findsoso.com /
- tptacek 16y agoThree 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.
- gxti 16y agoPhreebird 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.
- tptacek 16y agoI don't think that's true, but the article is right there; anyone can read it critically for themselves.
- dakami 16y agoPhreebird 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!
- beagle3 16y agoWhere can I find more DJB publications / activities? His cr.yp.to website doesn't seem to have been updated in ages.
- tptacek 16y agoIt's updated constantly.
- requinot59 16y agoRecent talks (often with PDF slides) of DJB @ http://cr.yp.to/talks.html http://cr.yp.to/talks.html (scroll to end of page for latest).
- requinot59 16y agoThe point about the uncacheability of DNSCurve seems correct and a huge concern (http://dankaminsky.com/2011/01/05/djb-ccc/#caching http://dankaminsky.com/2011/01/05/djb-ccc/#caching).
- tptacek 16y agoOn 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?
- requinot59 16y agoLet's say that I, like the majority, use my ISP DNS servers. And that my ISP supports DNSCurve. Can it cache (Curved)DNS responses among all of its clients?
- tptacek 16y agoYou'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.
- dakami 16y agoEr, 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.
- requinot59 16y agoBut 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?