This week in our group meeting Alex gave a presentation about the status of DNSSEC. DNSSEC is supposed to improve the security of the Domain Name System (DNS) by cryptographically signing DNS responses. Thus, with DNSSEC, you can be sure that when you visit www.google.com, you are visiting a machine (IP address) that is actually associated with Google, rather than visiting some random attacker’s website. Recently a number of DNS vulnerabilities have been found that make it very easy (under some circumstances) to forge DNS responses, so the security case for DNSSEC would appear to be very strong. By the end of our discussion, however, we had reached a very different conclusion. Let me explain.
First, let’s assume that DNSSEC is adopted in record time, say within the next year – 95%+ penetration on secured servers and clients. Next, let’s assume that all the major security problems with DNSSEC – such as the lack of key revocation – have been resolved. In this hypothetical world, we would now have a DNS infrastructure hardened against forgery attacks. Mission accomplished, right? Maybe not. In fact, I think there’s a good chance that we would actually be in worse shape than we are now. Things would be worse because the Internet would become both less reliable and less secure. These problems would arise precisely because of the success of DNSSEC.
The key insight is that a successful DNSSEC would inevitably kill SSL certificates; instead, SSL would just use the keys conveyed by DNSSEC. Why bother maintaining two sets of cryptographic credentials when you can get away with one? Once this happens, the incentives for breaking DNSSEC become enormous.
And break it they will, because DNS admins at all levels have minimal experience safeguarding cryptographic credentials – they know how to keep servers running, not how to keep secrets. The first priority with DNS will always be availability, and such availability in DNS means that entries have to be changed with short notice. Therefore, many more people will have access to domain signing keys than should from a security perspective. Thus, attackers will get the keys. And those keys will be trusted even more than SSL certificates, because they will be used to block network connections.
So, in an effort to secure DNS, we will make DNS less reliable (because it will be harder to make timely updates) and we’ll make the Internet less secure (because connections to secure websites will be authenticated using much less reliable signatures).
We currently have some faith in cryptographic credentials because they are issued by parties that value their reputation for security (because their business depends upon it). Instead, we’re going to make organizations who have a reputation for reliability – DNS registrars – and we’re going to give them a fundamental security responsibility that detracts from their core mission of reliability. The parties implementing DNSSEC actually have significant incentives to trade off security for reliability, even though everybody else on the Internet will have an increasing requirement that DNS be secure (because it will replace SSL certificates).
So, what’s the connection to the financial meltdown? Well, that meltdown can be, in part, attributed to mismatches between incentives and expectations of trustworthiness. Credit rating agencies were expected to look out for buyers of securities but were paid by the sellers of securities. Developers of mortgage-backed securities expected banks to continue to make loans as they had in the past, even though mortgage-backed securities gave banks every incentive to be careless when giving out loans – if the loans went bad, they wouldn’t lose any money because they’d sold the loan to somebody else!
New technologies, whether DNSSEC or financial securitization, inevitably have secondary effects on human decision making. Technologists must realize that tools designed to increase security or manage risk can, in practice, lead to reduced security or disastrous levels of risk.
everyone in the financial world having too much faith in the models underlying structured financial instruments (such as mortgage-backed securities). Those models became untrustworthy the moment they were used to create structured financial instruments, because such instruments removed the incentives for banks to be careful when giving out loans (they no longer faced the risk of mortgage defaults).
In our discussion, Luc made an interesting point that reliability and security are generally in conflict in practice, but yet system designers seem to keep wanting to do both at the same time. I think there’s a deep insight here, but I’m not quite sure what it is. All I do know is that if we’re going to get reliability and security, we need more flexible ways to manage the trade-offs between them.