Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Using DNS To Distribute Trust
In <a href="http://www.informationweek.com/blog/main/archives/2009/02/dnssec_forgetti.html">"DNSSEC: Forgetting The User, Again</a>," I opined about why users should be notified about signed vs. unsigned DNS responses. Dan Kaminsky, a security researcher with IOActive, and I got into a quick conversation about DNSSEC, SSL, and trust on the Internet. Kaminsky had some interesting thoughts on distributing trust.
13 Min Read
In "DNSSEC: Forgetting The User, Again," I opined about why users should be notified about signed vs. unsigned DNS responses. Dan Kaminsky, a security researcher with IOActive, and I got into a quick conversation about DNSSEC, SSL, and trust on the Internet. Kaminsky had some interesting thoughts on distributing trust.DNS is a distributed database. Each domain owner is authoritative for its part of the name space and, on the assumption that domain owners want others to actually reach their servers, there is an inherent level of trust in the integrity of DNS. If you want your organization to receive e-mail, you have to publish a valid mail exchange record in DNS. If you don't supply a valid mail exchange record, then mail clients and mail servers don't know where to send e-mail to your organization. If you want users to view your Web site, you have to supply valid host records to your Web server or they can't find you. As a distributed database, DNS can be used for a lot more than hostname to IP address resolution. For example, DNS may become even more important as VoIP spreads and records are used to locate people and devices.
DNS is an amazing set of standards when you start to really examine how it works and the benefits it provides. As Kaminsky points out, "DNS provides a canonical, federated, universally supported name space. There are no others," Kaminsky pointed out in his Black Hat Federal Presentation 2008 And The New (Old) Nature Of Critical Infrastructure. Federation is that elusive notion that organizations which both cooperate and compete can be authoritative for their organization's information and rely on the information published by other organizations. Other attempts at federation are difficult because it requires trust where there are no formal agreements, as can be seen with attempts to federate user identification in the Internet from Microsoft's failed Passport to the nascent OpenID intiative, but DNS is an example of federation that works.
Unfortunately, DNS is easy to subvert if you have the right access. The DNS protocol was never designed to enforce integrity -- by integrity I mean the data the domain owner publishes is the same data you receive in response to a DNS request. Integrity was assumed because it made sense for the federated, distributed database to have integrity. But subverting the integrity of DNS has benefits for an attacker because they can direct users whereever they want by poisoning the cache, poisoning the host, poisoning the server, or poisoning the responses. Of course, if DNS is subverted, there are other indicators higher up the stack that might indicate that we are not talking to the server we think we are talking to, like host name mismatching errors in SSL, or odd-looking URLs in Web browsers.
DNSSEC To The Rescue?
DNSSEC is a set of security extensions that try to address the shortcomings of DNS -- namely, ensuring that responses to requests are coming from the authoritative source, the domain owner, and haven't been modified enroute. By creating a chain of trust from the root servers down to the client, you can be sure that you're reaching the places that the domain owner wants you to reach.
Kaminsky puts it this way: "DNSSEC isn't 'We got the DNS layer right.' It's about, 'We can trust DNS, now let's bootstrap trust through it.'" He points out that DNS already is used to bootstrap trust. When you forget your password to a Web site, you answer a few secret questions and the system sends you e-mail with a URL to reset your password. The system gets the destination for your mail server from DNS and your Web client finds out where the password reset server is through DNS. But what if an attacker could redirect e-mail to your domain through their server and make modifications on the fly or redirect your client to a Web proxy of the attacker's choice?
Web browsers rely on host names to enforce the same origin policy so that mobile code from one domain can't interact with pages from another domain. Even SSL, which does provide end-to end encryption, uses host names to match the destination server host name and digital certificate. Directly or indirectly, host names are a critical underpinning of how we interact with and place trust in the servers we think we connect with.
DNSSEC has a long history. Standardization efforts started back in the mid-'90s and have continued today. The core protocols and a number of extensions have been defined and rolled into DNS servers and some clients, but it's been a long road. ISCs Bind software has supported DNSSEC for years, but Microsoft's DNS server in Windows 2003 had basic support to cache DNSSEC records, and doesn't validate or sign them. Windows 7 is supposed to have DNSSEC support, probably due to the U.S. government's requirement to migrate to DNSSEC, but Windows 7 isn't shipping. Apple has no support for DNSSEC, either. On the operational side, a few Top Level Domains (TLD's) have been signed, such as .gov, .pr, .se, and a few others, but it's slow going. ICANN is still trying to decide when to sign the root zone and VeriSign, which manages the .com and .net TLDs, is planning on rolling out DNSSEC sometime in 2011.
One of the main barriers to DNSSEC deployment is that it is so difficult with current software. Web site administrators from Fortune 500 organizations to people hosting a vanity domain on a shared service have a difficult enough time getting application security correct. Trying to get them to be key managers and actively ensure that their DNSSEC-enabled zones are properly configured and managed is asking too much.
Kaminsky's point is that
DNSSEC is way too much of a pain to deploy today. We have to do a lot -- across everyone you named [TLD owners, registrars, hosting providers, etc.] -- to make DNSSEC as easy to deploy as SPR [source port randomization -- a semipermanent solution to the DNS cache poisoning within DNS that Kaminsky announced in 2007]. It turns out the protocol ain't too bad. The implementations just need some work to automate their support for the protocol. I'm personally working to deal with this. Secure64 and Xelerance are demonstrating how straightforward DNSSEC deployment can be, but to really migrate the ecosystem, we have to get BIND on board, too.
In reality, most domain owners really don't need to be involved in DNSSEC management. A reasonable set of defaults for signing expiration can be developed and deployed and the user need be none the wiser. Hosting services could automate DNSSEC management as part of their core services. How many of you have actually set your DNS zone settings different from the defaults? There really isn't much need, except in rare cases. Organizations that need more control over DNSSEC can certainly have that option, but they would most likely also have the expertise to make wise decisions.
What DNSSEC Can Do For You
In Kaminsky's view,
there are two, fairly different scenarios for DNSSEC. There's protecting against cache poisoning attacks in general -- providing a more solid barrier against the attacks I found last year. This stuff requires no user awareness whatsoever. And then there's fixing security of applications in general, which is a totally different problem.
To fix applications in general, we need a scalable facility for end-to-end trust. We don't have one today. It simply does not exist. Where I think we can go with DNSSEC is to inject it into the endpoints themselves that need trusted data. From an OS perspective, this is the stub getting fatter; from the browser perspective, this is the browser bootstrapping trusted protocols directly via DNSSEC, rather than trusting a hodgepodge of 200-plus certificate authorities. In the long term, the existing name server infrastructure becomes little more than a caching layer -- critical, yes, but not trusted like it once was.
What about SSL? SSL is supposed to provide the end-to-end security by validating the servers identity and setting up encryption to keep data private.
SSL offers a comprehensive level of security, against whatever man-in-the-middle attacks are going on -- with the exception of when something goes wrong with the crypto, something goes wrong with the certificate authority infrastructure, the crypto is disabled, or the crypto is misapplied to an incorrect name.
December's work by Stevens and Sotirov was about a crypto bug, where the certificate authorities issued a certificate they shouldn't (signed with MD5 in a particular way). SSL can't protect against that. The recent work by Moxie was about dealing with the UI issues of no crypto, or crypto to a similar-seeming name. That's what Extended Validation is about -- providing a stronger signal regarding the precise name you're speaking to. (It's important to note that EV only deals with similar names, not exact. Sotirov's SSL break with MD5, my SSL break via hijacking of a certificate authorities' e-mail-based authentication of a user, and Mike Zusman's tricking of a CA into granting him a certificate for Live all bypass EV. See Barth and Jackson's Beware of Finer-Grained Origins paper for details.)
Certificate authorities have problems, cannot all be trusted, and come and go as their owning companies change. We do not always know what certificate authorities to trust, but we must continuously consult them whenever we change infrastructure. The root name servers are stable, dependable, centrally coordinated, and guaranteed to be around in 10 years. We know what root name servers to trust, and we can add new hosts to our domains without requesting permission from a central authority. DNS and DNSSEC leverages the federation already in place for DNS. It's actually an alternative to the existing certificate authority system, open for a whole new era of applications.
Not every Web site needs encryption offered by SSL. For that matter, any Web site on a virtual Web server -- such as when one Web server has multiple Web sites sharing the same IP address and differentiated by a hostname -- can't support SSL at all. We don't always need confidentiality, but we always want to know that the site we think we are connecting to is, in fact, the site we are connecting to. DNSSEC is one step in the process (there are other ways of launching a man in the middle attack that neither DNS nor DNSSEC can address) of reaching the host we intend to be assuring us that hostnames responses are issued from the authoritative source -- the domain owner.
In cases where SSL is necessary, like when you connect to your bank or order widgets from an e-commerce site, you want your private information like banking numbers, credit card numbers, and password, encrypted. One of the problems that Moxie highlighted is that Web browsers are inconsistent in how they indicate when SSL is active and the Web applications themselves are inconsistent in using SSL. Most bank Web site home pages are accessed over plain old HTTP, but the username/password form is sent to the Web server over HTTP without any clear indication that SSL is being used until after you press Submit. And as Moxie demonstrated, the indicators are often very, very subtle. It's hard to determine when to expect SSL and when not to. Paypal.com is a notable exception to that rule because the entire site is sent over SSL. But PayPal is the exception and not the norm (and other financial institutions would do well to follow PayPal's lead).
DNSSEC will take time to deploy. During that time, some sites, even trusted sites like banks and online retailers, will use DNSSEC and some won't. How SSL is used today is an excellent example of uneven usage of a technology. That leads to confusion by users. During the transition to DNSSEC, users will have to be notified when a DNS response has been validated or not, otherwise, why bother? But it's not enough, for the same reason that using SSL unevenly even within the same Web site isn't enough. Users won't know what to expect. But DNS, backed up by DNSSEC, can tell users what to expect.
Distributing Trust
Kaminsky thinks
We shouldn't be presenting DNSSEC information to the user, any more than we should be flashing in their face that their DNS source ports are randomized. What does that mean to them? SSL, authenticated presently via the CA system and possibly in the future via DNSSEC, does mean something -- it says that you're talking to the name you think you're talking to. EV tells you even more, because it adds human eyes to the process, declaring that the name you're looking at is in fact the brand you're hoping to communicate with.
Consider for a moment how few sites have SSL interfaces at all -- and how even those that do, screw it up. If SSL certs, as distributed through DNS, were as widely deployed as my SPR patch, users would be seeing a lot more locks -- and browser developers could start designing their browsers to assume security would be there, and alarming otherwise.
That's an interesting concept. Users and applications don't know what to expect and you shouldn't expect users to remember that this Web site or that Web site uses SSL or not. That's silly, especially when the use of SSL even within the same Web site is inconsistent. If the domain owner states that SSL is used for particular hosts, then other applications know something useful, right?
But even that breaks down. Sometimes when you transition to SSL, there is no change in hostname, thus there is no way, via DNS, to indicate the URI, the path of a URL after the host portion, that requires SSL. I had said that all of Paypal.com is only accessible over SSL. That's not entirely accurate. If you type in http://www.paypal.com, you will be redirected to https://www.paypal.com. Redirection from HTTP to HTTPS is a common tactic so that users can type in the familiar URL but get redirected to the SSL-protected site. Marlinspike's presentation demonstrated that he was still able to trick users into giving up their PayPal account credentials because they unaware that they were accessing Paypal.com via SSL. I suppose text records could be used to communicate when and where SSL is used, but I think a new record format would have to be standardized. Besides, all of this is moot, at least for the immediate future, because DNSSEC will take time to deploy and therefore its use will be inconsistent.
Maybe DNS is the way to communicate expectations and trust to arbitrary users. The federation already is in place, like Kaminsky points out. As long as the meaning of DNSSEC responses isn't overstated -- DNSSEC is an assertion of authority, not a statement of "security" -- then DNS with DNSSEC is a viable distribution mechanism.
About the Author
You May Also Like
More Insights
