Home / Blogs

DNSSEC Happy Talk Enters a New Era

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.
Phillip Hallam-Baker

So we finally have a signed root zone.

Now when is someone going to answer the question I first asked over five years ago and have still not had an answer to: How do the domain name owner's keys get into the TLD?

Before we have a system people can use there have to be technical standards, validation criteria and a business model. Where are they?

And before we can answer any of those questions we have to answer the even bigger one: what problem is DNSSEC going to solve?

Or to be more precise: which security problem is DNSSEC going to solve. Because if the idea is that DNSSEC is going to eliminate the need for people to pay for those pesky SSL certificates, then expect some tense moments at ICANN meetings. Most registrars sell domain names at cost and make their margins on upsells such as web hosting and SSL certificate resale.

Then there is the question of liability. So far DNSSEC has been run by ICANN and the registries and we can be pretty sure that to the extent issues of liability have been thought about at all, neither is willing to accept it. Which leaves the registrars on the hook for liabilities that are unknown and uncontrolled.

SSL certificate authorities have developed mechanisms that allow them to control their liability and avoid lawsuits. They do not warrant the outcome, they warrant the process. They embed relying party agreements and offer insurance. DNSSEC as currently designed does not provide any of those controls.

So looking at DNSSEC from the registrar's point of view, they are expected to invest in building out an as yet undefined technical infrastructure for a product for which demand has not yet been demonstrated, will cannibalize existing revenues and incur unknown (but uncontrolled) revenues.

Is it really just me who sees it this way?

Is there anyone else interested in looking at these issues?

By Phillip Hallam-Baker, Consultant, Author, Speaker. More blog posts from Phillip Hallam-Baker can also be read here.

Related topics: DNS, DNS Security, Domain Names, ICANN, Security, Top-Level Domains



business models Carl Byington  –  Jul 18, 2010 6:48 PM PDT

> How do the domain name owner's keys get into the TLD?

The same way the domain name owner's NS records get into the TLD. By action of the registrar, paid for by the domain name owner.

> ... technical standards, validation criteria and a business model. Where are they?

That will be coordinated by the same folks that wrote/approved/use the current standards, criteria etc regarding placing NS records into the TLD.

> what problem is DNSSEC going to solve?

Were you sleeping, or just failed to google "Kaminsky dns"?

> ... margins on upsells such as web hosting and SSL certificate resale.

Yes, eventually the need for SSL certificates signed by third parties will go away. Those registrars will continue sell such bits, and some folks will even buy those bits.

> Which leaves the registrars on the hook for liabilities that are unknown and uncontrolled.

In the US at least, anyone can sue anyone at any time for anything. But what *specifically* do you see as an increased risk with dnssec that is not already present with ssl certificates? And specifically why won't the mitigation methods for SSL work equally well for dnssec?

DNSSEC : Kaminsky bug :: steamroller : nut The Famous Brett Watson  –  Jul 18, 2010 9:15 PM PDT

> what problem is DNSSEC going to solve?
Were you sleeping, or just failed to google "Kaminsky dns"?

If it were just about fixing the Kaminsky bug, there were immensely simpler ways to go about it. I refer you to earlier comments from Dan Kaminsky himself.

It is true DNSSEC is a fix for cache poisoning attacks, that is rather better than simply 13-16 bits more entropy.  But it's also true that DNSSEC would be horrible amounts of overkill if that was the only problem it could solve.

If you read his comments on the matter, you'll see that his take on the benefits of DNSSEC are not so much that it solves an existing security problem, but rather that it creates opportunities for distribution of arbitrary application-specific signed data. (That is, at least, my precis of his views.)

If DNSSEC is about fixing the Kaminsky bug, then we've chosen a steamroller as the tool to crack a nut. The nut will indeed be cracked, but at great expense, and the results may leave us feeling that the solution didn't address the problem we actually intended to address.

Let's hope that Dan is right about the secondary benefits. A steamroller makes a lousy nutcracker, but it has other uses. It's fair enough to find secondary uses for a technology like this, but I'd prefer that we built solutions which were well-matched to their primary problem in the first place.

Yes, you have my position pretty well.I Phillip Hallam-Baker  –  Jul 18, 2010 9:40 PM PDT

Yes, you have my position pretty well.

I think that what we need in the Internet is more security, not a pointless standards war between DNSSEC and SSL. That war was lost fifteen years ago and we do not need a repeat. Donald Eastlake's proposal was perfectly sensible when he made it in 1995, it does not make sense for that particular purpose any longer.

We had to get to this point so that people could realize it was a dead end. My strong belief for the past ten years has been that we need to use DNSSEC and X.509 as complimentary infrastructures.

It is going to be so much easier to deploy DNSSEC if there is a solid business model on the table for the registrars that gives them an incentive to push DNSSEC as a complimentary upsell rather than a competitor.

Still happy talk Phillip Hallam-Baker  –  Jul 18, 2010 9:29 PM PDT

>The same way the domain name owner's NS records get into the TLD. By action of the registrar, paid for by the domain name owner.

What is the commercial motivation for the registrar to do this?

How is this process secured?

At what point will specs be available to review?

I have been asking these questions of the people that you imagine to have the answers and received nothing but silence. All I hear is people whining in the national press about how the registrars are now the impediment to DNSSEC deployment.

>Were you sleeping, or just failed to google "Kaminsky dns"?

DNSSEC as currently planned is of zero value against that specific attack. Even if someone was to work out what resolvers and applications should be doing when a signature verification fails, real world DNS will still be vulnerable against the far simpler and more frequent name-jacking attack and the insidious and difficult to defend against BGP layer attack.

>Yes, eventually the need for SSL certificates signed by third parties will go away. Those registrars will continue sell such bits, and some folks will even buy those bits.

So given the fact that the registrars own the customer interface here, how does ICANN persuade them to do their bidding? Attempts at coercion would bring an anti-trust suit.

Essentially what ICANN is saying here is that fifteen years after the Web adopted an open, competitive model for PKI services based on X.509v3, ICANN is now going to replace all that with an as-yet unproven model where it just happens to have total control of the apex zone.

There is an important purpose for DNSSEC that only DNSSEC can provide. But that certainly is not replacing a facility that the Web already has with one that provides less security than the weakest form of SSL currently deployed.

>But what *specifically* do you see as an increased risk with dnssec that is not already present with ssl certificates? And specifically why won't the mitigation methods for SSL work equally well for dnssec?

OK, well first I will point out that I was Principal Scientist for VeriSign (the real one) for 12 years and worked with their people before that. And DNSSEC was on the table then as well. I have seen Crocker and Cerf's previous attempt to deploy this particular model of PKI when we called it PEM.

Whole books have been written on how risk and liability are managed in PKI. For example see Ford and Baum 'Secure Electronic Commerce' or the section on PKI in my book 'dotCrime Manifesto' for the condensed version.

The model developed by Baum et. al. copied an number of similar models that were in existence and were known quantities to the courts. In particular the notary model and the insurance model. The reason Baum selected X.509 as the certificate format for SSL is that it was the only format at the time that allowed him to annotate the certificate to incorporate the relying party agreement by reference. The relying party agreement in turn consists of three basic sections, the first essentially denies all claims for liability, the second sets up a series of liability caps and the third sets up a scheme of insurance with cover up to the value of the cap.

The point here was that at the time SSL was first deployed nobody quite knew who would use it or for what purpose. The biggest risk in litigation was the cost of the litigation itself. So it is better for all concerned to simply offer insurance.

DNSSEC has none of these considerations. There is no way to state what the statement means. so even if ICANN comes up with a practices statement there can be no real confidence that a court is going to consider it admissible as being relevant to the proceedings.

The bottom line is that should a party suffer some loss and decide to sue, the registrar, registry and ICANN would all find themselves embroiled in the proceedings and nobody can say with confidence what the reaction of the courts will be.

Contrast this with the SSL case where the registrar knows that the CA is the sole party on the hook for issuing the cert (unless they agreed otherwise as part of their reseller agreement).

As to the likelihood of a loss. Well in the case of SSL this has mostly been mitigated by the fact that every credit card transaction carries insurance and the banks are on the hook for phishing fraud and it is not in their interest to go after the CAs (at this point).

The business of a CA no doubt looks rather simple to people who do not bother themselves with what it entails. But remember that the reason VeriSign was formed as a separate company in the first place was that no other business would. Not even RSA would risk being a CA on their own account.

It might be possible to stampede or threaten the registrars into deploying DNSSEC on the basis that no liability showed up in the SSL case so DNSSEC must be safe, but that is hardly likely when the registrars are also being asked to give up their SSL reseller revenues.

At the very least, to have any success with applying the SSL approach, ICANN would have to start engaging with the people who are asking these questions. I posed the question formally six months ago before giving a talk on this topic at the RSA conference this year. Richard Lamb was present at that talk, he knows that I have raised these issues and will continue to do so.

The current ICANN proposal for DNSSEC is just that, a proposal. I am not raising these points to be awkward or obtuse. I do want to see DNSSEC deployed. But the way to do that in my view is to have less of the happy talk and start thinking about what the real constraints are. I have a plan which I believe meets the constraints as I currently understand them.

What I do not yet know, and due to the prevailing 'happy talk' sentiment cannot know is that I have a complete set of constraints.

counter-example Carl Byington  –  Jul 20, 2010 4:58 PM PDT

pir.org claims that GoDaddy, DynDNS and NamesBeyond are ready to push dnssec keys into the .org zone, with another 24 registrars in the "comming" weeks. Of course that wording is intentionally sufficiently imprecise so that it can never be disproven. But in any case, it seems that not all the registrars are as worried as you about the implications for their SSL certificate revenue or their potential liability.

Are they planning to do anything more Phillip Hallam-Baker  –  Jul 20, 2010 5:32 PM PDT

Are they planning to do anything more than sign the domains they manage in-house and register their own key with .org?

OK, so here's the deal Dan Kaminsky  –  Jul 21, 2010 10:25 PM PDT

So, look.  It's July 2008, I've just come out with the DNS flaw, and you know who I'm spending hours and hours on the phone with?

Certificate Authorities.

You know what we're not talking about?

How SSL makes the DNS attack irrelevant.

Quite the contrary:  The CA's almost uniformly employ DV — Domain Validation — to determine whether or not to issue a certificate.  DV means there's a MX lookup, or even an A lookup, to implement challenge/response.  Something goes wrong with DNS (or BGP), and a cert is issued.

You can throw all the policy theory out you want.  From the hacker perspective, it doesn't mean much.  Put simply, I don't even care what CA you use.  I just need to find the worst CA in the world, and attack those guys.

The interesting thing about DNSSEC is that it just doesn't work this way.  We have many registrars, but only one can get hacked to compromise your domain.  We have many registries, but again, only one counts.  Yes, we have one root, but man is that thing locked down.

Fifteen years ago, DNSSEC may have lost.  But X.509 did not win.  There are but a million SSL endpoints on the Internet today.

Half have invalid certificates.

All were vulnerable to the same cache poisoning attack (given a man in the middle).

Phillip, I can't emphasize enough, PKI didn't work like we thought it would.  And it hasn't worked since.  We need to learn from our failures or we will never build working systems.

If you had called the CA side Phillip Hallam-Baker  –  Jul 22, 2010 5:22 AM PDT

If you had called the CA side of VeriSign rather than the DNS side you would have received a different response.

The problem is that DNSSEC as currently configured gives even less security than a DV cert. You have all the insecurity of DV certs minus end to end security. Your packets are still vulnerable to BGP level attacks.

The most common attack on the DNS is not a protocol level attack, it is namejacking a registrar. The way the system is configured any registrar can claim that it is managing any name at any time. Worst CA in the world meet worst registrar in the world…

And as you know, some of those registrars are themselves controlled by criminals.

At the moment DNSSEC can do anything and nothing because it is just raw technology. What that system is going to turn out to be good for is going to depend on how much accountability and how much liability the companies running it are willing to accept.

Now you yourself are positing DNSSEC as a potential rival to SSL. I don't think that is the way to look at it. I don't think a standards war gets us any further. And at this point all the applications are SSL enabled and most of the registrars make more money from reselling SSL certs than from domain names that are usually a loss leader.

What I think we should be using DNSSEC for is to enable secure distribution of security policy. Allow an endpoint to know that a mail server always offers STARTTLS. When you look through what that type of capability can mean in the Web Services space it is powerful. But only if you understand what level of trust the ICANN DNSSEC root is providing and at what point you need to supplement it with Trusted Third Party validation.

At the moment the DNSSEC people are positioning their proposal as being superior to what already exists while in forums like this saying that only a fool would expect to rely on it. I think we have an expectations gap.

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Leading Internet Associations Strengthen Cooperation

5 Afilias Top Level Domains Now Licensed for Sale in China

Radix Announces Largest New gTLD Sale with Casino.Online

2016 Year in Review: The Trending Keywords in .COM and .NET Domain Registrations

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

A Look at How the New .SPACE TLD Has Performed Over the Past 2 Years

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Startup League Reports from WebSummit, Lisbon

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

.SPACE Becomes the Choice of the First Ever Space Nation Asgardia

Government Guidance for Email Authentication Has Arrived in USA and UK

Afilias Chairman Jonathan Robinson Wins ICANN's 2016 Leadership Award at ICANN 57

ValiMail Raises $12M for Its Email Authentication Service

MarkMonitor Supports Brand Holders' Efforts Regarding .Feedback Registry

Don't Gamble With Your DNS

8 Tips to Find Your Perfect .COM Domain Name

Why .com is the Venture Capital Community's Power Player

Defending Against Layer 7 DDoS Attacks