Paths2Trust

Kaminsky at Washington Blackhat: DNSSEC is needed

Dan Kaminsky spoke again at Blackhat/Washington about the dangers lurking in DNS, and this time he spent more time talking about DNSSEC.  He even mentioned our company, Secure64, because he feels that to make DNSSEC more widely deployed, we need to AUTOMATE, AUTOMATE, AUTOMATE.   We couldn't agree more!  A summary of his speech is in this article in Internet news .  For the time being, a complete copy of his presentation is at his doxpara.com web site.

It's well worth looking at Dan's slides because he goes into a lot of details and stories about not only how things can go wrong, but jut how wrong they can go.    And he calls a spade a spade.  About signing the root, about Trust Anchor Repositories, about the technical and political barriers to widespread adoption. 

But he posits that these are just temporary issues -- they are solvable.  DNSSEC can and must be widely deployed.  It's great to see Dan taking on more of an evangelist role!

Yup. 

Obama does Cyber-Security!

I find it remarkable that we now have a U.S. President who is technically savvy.

 He is blackberry-addicted, knows how to use email, recruits volunteers and mobilizes people using the web as a tool... and is actually AWARE that CYBER-SECURITY is an incredibly important issue.  Wow!

It was heartening last week to see an article on the front page of the Wall Street Journal mention the appointment of Melissa Hathaway as the cyber-security czar for the national security council.  That's the POPULAR PRESS talking about cyber-security.  The technical rags are writing about it as well, here's on in E-Week "In the Obama Era Routing has to Change, Too. 

Over the last couple of years there have been a lot of preliminary meetings on improving our nation's cyber-security infrastructure.  Bill Worley and/or I have attended meetings at Sandia, MIT, Johns Hopkins, let alone Blackhat & Defcon.  Those meetings set the stage; now is the time to put some wood behind the arrow.  Thank you Mr. President! 

But... will we throw away everything and start all over, as mentioned in this NY Times article?  Or will we make the existing net safer, as mentioned in the CircleID blog posting?

Mostly I see an evolutionary approach, but with a few disruptive technologies thrown in from time to time.  And because of this belief, I am very glad to see that these articles are emphasizing two of my favorite topics on shoring up the existing internet -- by solidifying DNS and BGP with DNSSEC and BGPSEC.   Sure there are lots of other security holes in the internet, but these two need attention quickly. 

Keep it up Mr. President.  Change we can believe in. 

Homeland Security does Cyber Security!

Homeland Security has some really good programs regarding cyber-security.   This article in NETWORK WORLD emphasizes two of them:  BGP security and DNS Security.  Doug Maughan, the program manager highlighted in the article, has been leading these efforts at DHS.  He certainly deserves the credit -- he's been a leading force behind DNSSEC development and commercialization for years.  He funded efforts at Sparta labs to develop DNSSEC tools and also partially funded the project at my company, Secure64, to commercialize an automated DNSSEC signing appliance.

He has also funded the research program at CSU led by Dr. Dan Massey to monitor and alert BGP hijacking attempts. 

All of this is good stuff, and I'm glad to see Doug get the attention that he greatly deserves.  Now let's hope that the incoming federal government funds even more of these efforts.  The priority for developing and commercializing fundamental cyber-security technologies is really important.

Happy New Year!

I just got off a world-wide phone conference with the DNSSEC deployment working group.  There was a good discussion on getting DNSSEC more widely deployed, including barriers and accelerators.

A big issue that people were worried about was the publication of TRUST-ANCHORS.  How do people know they are trustable?  Where do you go to get trust-anchors?  How do you publish to a trust anchor repository?  Should the registrars be involved?

So... let's be pragmatic and proceed with baby steps. 

The TAR-fetcher program I mentioned in an earlier posting should be easily installed by a typical ISP using YUM or some equivalent installation program.  When the program runs, it should allow some simple configuration settings to say which TARS it should fetch.  (I call this "small", "medium" and "large")  Now comes the baby steps...

To start, an operator wants to verify that nothing has broken by turning on DNSSEC.  Only a few trust-anchors should be installed (maybe .gov, .org, .se and a few others).

After a trial period, the operator could change the configuration to "medium", which would include more trust anchors.  Finally, "large" might include the trust anchors associated with .com or other miscellaneous anchors.

These baby steps allow for incremental optimization and experimentation... on a widespread basis with thousands of ISPs, enterprises and institutions. 

As far as TAR-fetcher programs go, the auto-trust program from nlnetlabs (www.nlnetlabs.nl) is something worth looking at.  Paul Wouters from Xelerance has proposed a utility program to configure and prime DNSSEC.  I'll experiment with that and let you know the results in a future posting.

DNSSEC Awareness

Earlier, I wrote about making DNSSEC deployment happen more widely by separating out the work for DNSSEC signing (the "transmitters") from DNSSEC validating resolvers (the "receivers").  Baby steps are going to be needed to get each side of the equation working, and to eventually build up to a huge deployment.

The activities necessary to get the "receivers" ramped up are: awareness, education, easy-trust-anchors, and diagnostics.  Last-time I wrote about easy-trust-anchors.  Let's go back to awareness & education.

I wrote to the author of the "DNSSEC in 6 minutes" but haven't heard back yet.  I hope to hear soon, but if not, I'll develop my own document.  The cookbook can be quite simple, especially if it references the TAR retrieval scripts.  But how do we get people to know how to do this?  This is the AWARENESS issue.  And maybe INCENTIVES, too...

For starters, we can work with the DNSSEC deployment working group, chaired by Jim Galvin.  There's bound to be good ideas to get wide distribution of the cookbook. 

A new group, the DNSSEC Industry Coalition, has also just formed, as written up in this NetworkWorld article.  As a member of this group, I am thrilled that we are talking about using DNSSEC for more than just protecting against cache poisoning, but using secure DNS to enable new killer applications such as anti-spam and other ideas.  This type of thing might provide the INCENTIVES to get the masses rolling.  Getting registrars involved in the education process will surely help, and that is a major focus of the industry coalition.

In the meantime, if you have any ideas on awareness and education, send them to me and I'll pass them on to the group.

E.T. Phone Home

One of the phrases used in high-tech that drives me absolutely crazy is "all the customer has to do is..." followed by a lengthy set of steps the customer ISN'T going to do.  Not if there is an easier alternative...like doing nothing.

So that's why I don't like the current solutions for deploying DNSSEC trust anchors.  And why I believe it's going to get simpler with some automation scripts.

Does trust-anchor management need automation?  after all, it only takes two lines in the named.conf file:  "dnssec-enable: yes" and a "$include trust_anchors_and_dlv".

But then it gets trickier.  Where do I get the trust anchors file?  How many are there?  How do I know I can trust them?

There is talk of building trust-anchor repositories, but they don't quite exist yet.  Even when they do, I believe a small script needs to be published that Joe the Administrator can download from sourceforge or equivalent.  The script would "phone home" on a regular basis to securely retrieve trust-anchors, validate them against a secure redundant copy elsewhere, verifies signatures, etc.  It might even register itself each time it runs so that a world-wide counter of VALIDATING RESOLVERS could be updated.  Then we could have an animated map of the world display how fast DNSSEC resolvers are being deployed, just like Dan Kaminsky did at Black Hat to show how fast the DNS patch was deployed.

Is this hard to do?  Nope.  Look for it soon. 

In the meantime, if you want to manually install some trust-anchors, I'd suggest leveraging the work done by Duane Wessels over at DNS-OARC.  He has an open validating resolver with trust anchors.  It even uses the ISC DLV which is great!  I tried resolving my company name, www.secure64.com with this resolver and it came back with the AD bit set to indicate "Authenticated Data".  Perfect.  To use the Validating Resolver, check out he secure web site https://www.dns-oarc.net/oarc/services/odvr

To see how he did it:

https://www.dns-oarc.net/files/odvr/configs/bind/named.conf
https://www.dns-oarc.net/files/odvr/configs/bind/trusted-keys.conf

https://www.dns-oarc.net/files/odvr/configs/unbound/unbound.conf
https://www.dns-oarc.net/files/odvr/configs/unbound/trusted-keys.conf
https://www.dns-oarc.net/files/odvr/configs/unbound/dlv-keys.conf

Building towards a tipping point: the DNSSEC "Receiver"

OK, getting back to the main subject....

How might we get the bazillion DNS caching servers out there to turn on DNSSEC validation (the "receiver" part of DNSSEC)?  Well, in fact, there are multiple activities that need to ramp up to enable a DNSSEC tipping point:

1. Awareness: all the "Joe the Administrator" guys have to know that it's a good idea to turn this on, don't-cha-know

2. Education and Demonstrations: and they need to know that it's fairly easy to turn it on, you-betcha!

3. Trust-Anchors and DLV's we can trust:  this is the big missing piece... Joe the Administrator has to regularly update trust anchors and it better be painless.  (ok, no more political jokes...)

4. Diagnostics:  prove to Joe that it is really working and isn't doing bad things

These will be the subjects of multiple blog postings.  But let's start with a brief intro to #2: education.  Joe the Administrator needs a really simple recipe...something like the DNSSEC in 6 minutes tutorial -- only shorter and simpler to talk about just the validation side of DNSSEC.  (http://www.usenix.org/event/lisa08/dnssec_bof.pdf)

I think separating out the receiver side (validation) side from the transmitter side (zone signing) will make this a simple recipe that administrators can deal with.  But the recipe will be incomplete without setting up trust anchors.  Making that simple will be the subject of the next posting.
 

Breaker...Breaker.....DNSSEC will only rollout if we do it in baby steps

It seems that people are reluctant to do DNSSEC until there is  a huge rollout across the world and the root zone is signed.  Well guess what?  It won't happen that way.  It's going to happen in baby steps, one piece at a time.  Eventually critical mass will be achieved.  I'd like to predict how that rollout will occur over the next several blogs I publish.  In the meantime, a little background:

It turns out that DNSSEC is a lot like CB or ham radio.  You have a transmitter, you have receivers.  In the case of DNSSEC, you have authoritative DNS servers that sign their data (the transmitters), and caching servers that validate the signatures upon reception (the receivers).

There has been a lot of news lately about ramping up the number of transmitters.  The signing of .GOV and .ORG are noteworthy.  The secspider at UCLA shows the number of signed zones climbing  (http://secspider.cs.ucla.edu/).l

But what about the receivers?  Some large organizations like Comcast have set up trial sites (http://www.dnssec.comcast.net/), but I think we're missing a huge opportunity here.  The average DNS administrator probably doesn't know jack about setting up DNSSEC. 
 
Can we fix this? Are the DNS servers out there at least sort-of-possibly "ready" to do DNSSEC?  The answer is YES.   Although this article at networkworld (http://www.networkworld.com/news/2008/111008-dns-server-kaminsky.html?hpg1=bn) writes about how many servers HAVEN'T been patched for the Kaminsky exploit, it's easy to turn it around to see that a huge number of servers have upgraded their DNS.  This means there are LOTS of DNS servers out there that are at least capable of doing DNSSEC -- the "receiver" side of the equation. 

Now we need to make it "falling off a log easy" for Joe Administrator to actually turn DNSSEC on and set up a safe set of Trust Anchors.  If we do that, we complete the circuit.  We have transmitters AND receivers.  BREAKER BREAKER!  (ok,I never did own a CB radio, and I'm lousy at faking the lingo, but what the heck...)

Next blog:  ideas on how to get Joe Administrator to actually turn DNSSEC on at sites around the world.

hello world

Hello world.