

Dan Kaminsky responds (at length) to DJB's 27C3 DNSSEC presentation - there
http://dankaminsky.com/2011/01/05/djb-ccc/

======
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!

~~~
tptacek
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_?

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

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

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

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

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

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

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

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

