DNSSEC: Forgetting The User, Again.

A lot of very smart people are working very hard to make the Internet trustworthy. The Internet Assigned Numbers Authority (IANA) has launched a beta Interim Trust Anchor Repository so top-level domain owners can publish DNSSEC material while ICANN works out signing of the root zones. The ITAR is one more step in the road to DNSSEC. But DNSSEC is a technical solution and, like other technical solutions, ultimately misses the point.DNS is untrustworthy. You don't need to go to the extremes of finding a unique bug in the protocol like Dan Kaminsky to see how easily it is fooled. Anyone with the proper access to the DNS server, the network that carries DNS requests and responses, or the hosts which make requests, can forge replies or subvert DNS. Getting the proper access may be difficult, but once access is gained, it's game over. Worm writers have gone to the point of overwriting a critical file on victim's computers to stop the computer's ability to get security updates. That file is the host and statically maps IP address to host names consulted before a DNS request is sent to a DNS server.

DNSSEC is supposed to put trust into DNS by signing responses indicating that the response is authentic. A few TLD's like Puerto Rico and Sweden are moving forward with DNSSEC while ICANN and IANA figure out when to sign the root zones.

DNSSEC is easily understood using a model similar to SSL (DNSSEC Tools also has a good set of tutorials ). A zone such as example.com has a public/private key pair and the responses are signed using the private key. Public-key cryptography ensures that DNSSEC responses can be verified using the associated public key and there is an extremely ridiculously low chance that the signature could be forged. I won't say impossible because the crypto nerds will beat me up, but for all intents and purposes, the chance of forging a signed response is low enough to be trustworthy.

So that's the answer, right? DNSSEC authoritatively signs records so the DNS forgery problem is no more? Well, no. Let me do some hand waving here and pretend that DNSSEC is starting to roll out on a global scale. The roll out will take time and there is no indication that DNSSEC will reach 100% penetration, though that would be nice. But let's say some sensitive organizations like banks and online stores are starting to support DNSSEC. That's good, but the deployment is uneven, and how is the user to know when a host record should be signed or not?

Another critical component is DNSSEC-aware computers called stub resolvers that can request and process DNSSEC requests. Your workstation should verify DNSSEC responses itself and not rely on the DNS server to do so. DNSSEC-aware stub resolver is reportedly coming to Windows 7 and already is available on platforms like Linux that uses the Bind 9 software.

Of course, applications have to be DNSSEC-aware so they can differentiate between authenticated DNS responses and unauthenticated ones. Some zones will be signed by DNSSEC and some won't. Some hosts will be signed and some won't. In theory, we might want to reject any responses that are not signed, but that assumes that all DNS records will be signed and that would be a bad assumption, today and in the near future. The user will have to make a decision about whether to continue using a site located using an unauthenticated DNS response. We've Been Here Before

I envision DNSSEC deployments very much like SSL deployments. Some Web sites use SSL, some don't. A few sites use EV certificates, most don't. Not every Web site needs to be SSL-enabled. Trying to enforce SSL on all Web sites would be disastrous because virtual hosting would be broken; millions of Web site owners would have to become certificate managers; and the costs in time and money would be exorbitant. Since SSL deployment is uneven, the responsibility of determining what is trusted and what is not falls to the user.

The user is notified of the status of SSL in the Web browser and that interaction is woefully inadequate. When users are met with an SSL problem described in a dialog box, they will invariably click through. But a more subtle attack was demonstrated by Moxie Marlinspike which fools a user into thinking they are at the SSL Web site of their choice when that is not the case.

The attacks work because the way SSL enablement is presented to users is inconsistent. Each browser vendor displays SSL status differently and the display changes with version differences. In addition, Web site owners have opted to make the remaining visual cues confusing. You go to your bank's Web site via unencrypted HTTP, http://www.example.com, and there is a form to log in. That form displays a tiny lock image which is just an image. The authentication request may be sent over SSL, but the user doesn't know that unless they view the page source and look for the form action.

DNS, however, is lower in the stack and hidden from users. I bet most users don't even know how names are resolved to IP addresses nor should they be required to understand how DNS works, much less understand how DNSSEC works. The salient information is in knowing whether the host they are talking to is, in fact, the host they are talking to. DNSSEC can tell us that, but if the presentation is inconsistent and DNSSEC deployment is uneven, too much burden is placed on the user. Just like users can be fooled into trusting fraudulent SSL-enabled Web sites, they could be fooled into trusting fraudulent hosts.

User interaction is just as important as the technical deployment specifications, yet little work is being done on that front. If DNSSEC will actually be useful for users, a few things need to occur:

Users can make the right decisions if they are given the right information. That is just as difficult as figuring out how to generate the response in the first place.