The case against DNSSEC

Also published in www.circleid.com August 14th 2007.

I was talking to my good friend Verner Entwhistle the other day when he suddenly turned to me and said "I don't think we need DNSSEC". Sharp intake of breath. Transpired after a long and involved discussion his case boiled down to four points:

SSL provides known and trusted security, DNSSEC is superfluous.
DNSSEC is complex and potentially prone to errors.
DNSSEC makes DoS attacks worse.
DNSSEC does not solve the last mile problem.

Let's take them one at a time.

SSL provides known and trusted security, DNSSEC is superflous

Untrue.

But the most powerful argument against DNSSEC and the easiest one to refute on two counts:

We have to get to the right place, the right IP address, for SSL to be effective. If I subvert access to your heavily fortified SSL site with a judicious spot of cache poisoning then you come to my site and I control whether we will, or will not, use SSL. Let's suppose I've just diverted access from www.respectedfinancialinstitution.com to my site where I have a doctored copy of the real site. I decide not to use SSL when you login to your account - I wonder, genuinely wonder, just how many of us would notice its absence? I suspect the answer would be very few - even among the savvy.

Alternatively I could provide an SSL certificate in the real name of www.respectedfinancialinstitution.com but sign it myself using a plausible looking name (remember I control this process entirely) such as "The Original Trust Certificate Company, Inc." or even as one of the established SSL vendors. Users will get a dire warning message since we are not a recognized Certificate Authority - a deep and meaningful term to most average users. Unfortunately we see these warning messages quite often on genuine sites (Google is especially bad) and experimental evidence suggests that users will likely click through without even checking the signing details.

In short, SSL is a highly effective strategy but only if the user gets to the right place which, incidentally, is one of the things DNSSEC ensures. DNSSEC makes SSL effective. Without DNSSEC, SSL is a flawed strategy arguably made worse by its apparent security.
The SSL argument also implies that sites that do not use SSL are not important, which is stunningly naive. It's sound-bite analysis at best. To illustrate this point let's take a news site such as the New York Times. Does it use SSL? No it does not. Nor would you expect it to. Now suppose I hijack the NYT and plant an exclusive, plausable, head-line business story to manipulate some stock prices - a sort of on-line "South Sea Bubble" - then go and clean-up. Who do I check with - it's an exclusive story - I have leveraged the NYT's reputation without touching SSL. Or I could have a lot more fun and grab a few other sites as well and plant multiple copies of my story giving it more plausibility.

Finally, let's paint a much darker picture. Suppose the stories I plant, in a number of DNS hijackings such as governments and news media, are synchronized with and designed to amplify the panic effect of a physical act of aggression or even a pseudo act of aggression (propaganda on steroids). Perhaps complete with cell-phone pictures and video - grainy, on-the-spot, sense-of-realism, state-of-the art news reporting and commentary, utterly riveting - and all completely phoney. I hesitate to use emotive words here - but those with any sense of imagination can get the picture. I would venture to suggest that with reasonable execution it could make the panic caused by Orson Welles's "War of the Worlds" broadcast look like a couple of people out for an evening ride in their cars. This scenario, based on premeditated acts of on-line vandalism, leveraging reputations, coupled with our increasing dependancy on the Internet, for me means that, no matter what the cost, DNSSEC is vital for the future integrity of the Internet.

DNSSEC is not superfluous, it is an essential feature the Internet has long lacked.

DNSSEC is Complex and Potentially Prone to Errors

True.

One of the underlying principles of security is that more code = more errors and security holes. In case we forget just do a search for 'security alerts SSL' and then plough through the 1.9m articles listed. But bugs are removed and the world moves forward to a better place.

In a Polyanna'ish way I'd argue that DNSSEC implementations, by coming later to the game, will be relatively more bug-free than some of their security predecessors since they use common crypto libraries that have been heavily de-bugged already.

Some things that are good for us, like medecines, are not always pleasant experiences.

DNSSEC makes DoS Attacks Worse

Untrue.

DNSSEC Authoritative name servers (serving signed zones), at whatever level, would do a trivial amount more work by sending more zone records per request and thus, at worst, would be marginally more vulnerable to DoS attacks.

If DNSSEC security is end-to-end, which many of us argue is the only way forward, the signature validation work (the heavy lifting) is done in the end-user's computer. Any intermediate caching DNS in this scenario is told to keep its hands off (via the Checking Disabled flag) and incurs a relatively trivial overhead through handling a higher volume of zone records.

However, in the current organization of the Internet's DNS hierarchy a security-aware caching resolver at, say, an ISP would do significantly more work per request for secure zones when validating the results. This resolver would be more prone to DoS attacks in a DNSSEC world. This is yet another argument for end-to-end security and for changing the role of intermediate caching name servers.

The DoS problem is designed out by the right implementation of the DNSSEC standards.

DNSSEC does not solve the last mile problem

Untrue.

The DNSSEC standards define end-to-end security. However, to achieve end-to-end security the current stub-resolvers installed on most of the worlds computers would need to be replaced with security aware versions. Analogous to the way in which SSL required browser replacement and upgrade when it was progressively introduced. For those who can be bothered to remember.

DNSSEC provides end-to-end security covering the last millimetre not just the last mile - if I am permitted to mix my metrics.

The Death of Hope

My point in writing is not to argue that DNSSEC is perfect, but rather to argue it is essential. As well as trying to dispel some of the more superficial and pointless arguments used against DNSSEC.

My intent? To try and re-focus all that negative energy into fixing the real implementation issues and problems that are currently being worked by a handful of dedicated folks.

While the rest of us continue to hope that we really are typing our passwords into our bank's web site.

By the way, Verner was convinced.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.