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

http://dankaminsky.com/2011/01/05/djb-ccc/

by there • 16 years ago

49 36 16 years ago

aeden• 16 years ago

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

jrockway• 16 years ago

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.

mike-cardwell2• 16 years ago

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...

gxti3• 16 years ago

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.

guan2• 16 years ago

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

dakami7• 16 years ago

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.

mike-cardwell2• 16 years ago

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

http://www.vimeo.com/18417770

alecco2• 16 years ago

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).

borism2• 16 years ago

so?

alecco2• 16 years ago

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.

daeken• 16 years ago

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

16s• 16 years ago

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

tptacek9• 16 years ago

That'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.

gxti3• 16 years ago

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

tptacek9• 16 years ago

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.

dakami7• 16 years ago

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.)

tptacek9• 16 years ago

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.

gxti3• 16 years ago

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.

tptacek9• 16 years ago

I don't think that's true, but the article is right there; anyone can read it critically for themselves.

dakami7• 16 years ago

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!

dakami7• 16 years ago

Oh, hi Tom :)

Was WONDERING why you were so quiet.

tptacek9• 16 years ago

Ok. Here's one. It's a very common C function that appears in some way/shape/form in most client software deployed on the Internet:

  int 
  connect_host(const char *host, u_int16_t port) { 
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    if(sock >= 0) { 
      struct sockaddr_in si;
      memset(&si, 0, sizeof(si));
      si.sin_family = AF_INET;
      si.sin_port = htons(port);
      si.sin_addr.s_addr == inet_addr(host);
      if(si.sin_addr.s_addr == INADDR_NONE) { 
        struct hostent *hp = gethostbyname(host);
        if(hp) {
          memcpy(&(si.sin_addr.s_addr), hp->h_addr, 4);
        }
      }

      if(si.sin_addr.s_addr != INADDR_NONE) { 
        if(connect(sock, 
                  (struct sockaddr*)&si, sizeof(si)) >= 0) {
          return(sock);
        }
      }
      close(sock);
    }
    return(-1);
  }

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?

beagle3• 16 years ago

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

tptacek9• 16 years ago

It's updated constantly.

requinot594• 16 years ago

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

requinot594• 16 years ago

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

tptacek9• 16 years ago

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?

requinot594• 16 years ago

Let'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?

dakami7• 16 years ago

Man, it's 2011, not 1983. If a device can run TLS, it can run DNSSEC.

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

Related Stories