Why DNSSEC?

You've no doubt heard something about DNSSEC - a news release from a vendor announcing their support of the technology, an article about last year's signing of the root or one of the TLDs, or perhaps a memo from your CIO/webmaster/sysadmin/mother-in-law about whether, when and how you should implement it. For many people, the first question is the most important; asking if the extra effort, added complexity and increased potential for operational problems will be worthwhile.

There's a lengthy list of arguments in favor of DNSSEC, but to add another one - ripped from the headlines, as the saying goes - we have the sad situation of SSL/TLS certificates. If you use any services in the so-called cloud, you're dependent on SSL to protect the connection, especially while using open-access wireless networks where the traffic is visible to anyone who might want to install a simple browser extension. Still worse, there might be someone who wants to see or even modify your traffic, and is willing to go to the effort of setting up a man-in-the-middle attack between you and the cloud.

SSL should protect you against such things, since a secured connection can't be decoded or intercepted unless the bad guy has access to the secret part of the SSL key. That's closely guarded information and it's unlikely anyone could get their hands on it for a major player like Microsoft or Google - so instead, the bad guys take the route of pretending to be Microsoft and convincing the SSL certificate authority to give them another certificate. Sounds difficult, right? Perhaps, but it can be done. Alternatively, find a Certificate Authority with weak security and simply break in. This time the certificate seems to actually have been used for an attack.

Now, DNSSEC is designed to protect the DNS; it doesn't replace SSL (or VPNs, or any other version of transport security). But the DNS can contain more than just names and IP addresses. For example, it could be modified to include information about SSL certificates. What if you could use DNSSEC in your own domain to securely inform your clients that the SSL certificates you've installed are the valid ones for your domain? That's the goal of an IETF working group called DNS-based Authentication of Named Entities (DANE). You can see all the details of what they're up to in these working drafts:

Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
Using Secure DNS to Associate Certificates with Domain Names For TLS

The idea is simple: you create a certificate (for www.example.com, say) and configure it on your web server. If you want to, you can have it signed by your favorite SSL CA - that will continue to be useful at least until DANE is widely deployed. In addition, you add a new DNS record, called (at least in the draft stage) TLSA, which the client on the other side of the connection can use to verify the certificate that your server provides. Of course your names should be DNSSEC-signed as well, to make sure that the bad guy can't change the TLSA record and implement his attack that way.

Ultimately, DANE's biggest impact may be on the small sites who don't want to spend money on every single SSL-enabled web server; the TLSA record will let users know that the certificates are legitimate, and depending on the browser implementation will likely avoid the frightening pop-up window that says "This Web Site Is Not Trusted!"

And that may also be the biggest value of DANE deployment. Right now so many websites have self-issued certificates that users can easily become jaded and fall into the habit of clicking through the warning every time. When those scary pop-ups become rare, they'll be much more likely to be taken seriously.

What do you have to do to take advantage of all this goodness? Push forward with DNSSEC deployment by signing your own DNS records, validating DNSSEC signatures on your resolvers, and demanding DNSSEC support from your vendors. We need to have DNSSEC past the tipping point in order for DANE to make sense, but once that happens it should be a no-brainer.

PS - for the hardcore geeks there's a similar DNS record, already standardized, that lets you publish your server's SSH fingerprint. Look at the ssh(1) man page for "VERIFYING HOST KEYS", and at ssh_config(5) for VerifyHostKeyDNS. . .