Re: DNSSEC Deployment

[Michael Sinatra <michael () RANCID BERKELEY EDU>]

On 05/17/10 13:00, John Kristoff wrote:

> For example, I've asked repeatedly for operators to show some convincing
> evidence of the Kaminsky attack being used in the wild, including
> Kaminsky himself.  So far I've seen none.  I don't doubt it has
> happened, I just haven't seen it.  I'd love to see it.  I've got a tool
> that does it, but I've never seen it or a knock-off used in the wild.
> Maybe as long as the DNS changer infections and malware works, who
> needs to poison caches?

To keep tooting my own horn, I cited Rumsfeld's Razor in one of my 
DNSSEC presentations, although I was not the first to do that--I just 
can't find the previous reference in google.  (There are a few competing 
definitions of Rumsfeld's Razor, and I am talking about the one embedded 
in the remarks that Robert Dugger made to the FDIC:

"Secretary of Defense Donald Rumsfeld was recently given the 2003 
Foot-in-Mouth Award by the British Society for Plain English. The 
Secretary’s award-winning comment was, “…we know there are known knowns; 
there are things we know we know. We also know there are known unknowns; 
that is to say we know there are some things we do not know. But there 
are also unknown unknowns — the ones we don't know we don't know.” Logic 
says there is a fourth category: things we do not think we know or do 
not want to admit we know, but actually do – the "unknown knowns". Thus 
four kinds of uncertainty make up what I will call "Rumsfeld's razor".")

At any rate, the fact that we can't currently put our finger on 
Kaminsky-style attacks doesn't necessarily mean that the DNSSEC 
technology is bad (which was the gist of my question--what is the reason 
for skepticism of the DNSSEC technology).  Implementing DNSSEC protects 
us against unknown unknowns as well.  Now, I am totally with you when it 
comes to the question of whether the increased risks and complexity of 
DNSSEC outweigh the mitigation of rather amorphous risks.

Still, this seems to be more straightforward than the types of risks 
that got us all to implement TCP-MD5 of BGP peering sessions, and I 
think we can pretty much say that that was a big bust.  (I am much less 
sanguine about the success of the various sBGP proposals than I am about 
DNSSEC, btw.)  Where I see increasing benefit from DNSSEC is that the 
activities currently underway are collectively lowering the risks and 
difficulties associated with signing.  There are now more tools out 
there to do DNSSEC, those tools are getting more flexible and easier to 
use, and there are more ways of monitoring and visualizing DNSSEC than 
before.  The experience- and knowledge-base is rapidly growing.  DNSSEC 
isn't a no-brainer, but it's becoming less of a brainer than it was before.

> That said, there may be some utility with DNSSEC beyond the Kaminsky
> cache poison and if so great.  I'd love to hear how its helped for
> real problems if you can share some.  I'd love to be able to
> demonstrate to folks how DNSSEC has helped those that use it.  We
> should be updating our Secure BIND Template soon.  I'm assuming we
> should add the necessary DNSSEC bits there for it?  Feel free to send
> your comments about that or other secure BIND items off line if you have
> them.

Yes, there is.  If you look on the dnsext/namedroppers mailing list, 
there are skeptics who believe that while DNSSEC is a bit much for 
simply securing the A record lookup for www.berkeley.edu, it *is* useful 
for embedding other things.  For example, at UCB, we're beginning to 
place SSHFP records into the DNS to allow ssh clients to use DNS to 
validate the ssh host-keys for servers.  Such a step is of limited 
utility if you don't have a mechanism for validating the very DNS 
responses you're getting.

There are several other possibilities, such as CERT and KEY records.  I 
don't want to make any bold predictions, but we should open up our minds 
to the possibility that there may be better PKI trust mechanisms than 
the standard X.509 mechanism and DNSSEC may be one of them.  (It's hard 
to imagine anything harder or more over-engineered than X.509.)

The part in my mind that's still fuzzy is whether the technology is bad 
or whether our implementations just aren't up to snuff and/or expose us 
to too much risk.  Many people say that they're skeptical of the 
technology and then actually discuss implementation issues that can 
easily be fixed within the existing protocol specifications (or with 
minor modifications thereto).

michael