Home / Blogs

DNSSEC Happy Talk Enters a New Era

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

Filed Under


business models Carl Byington  –  Jul 19, 2010 1:48 AM

> 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 19, 2010 4:15 AM

> 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 19, 2010 4:40 AM

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 19, 2010 4:29 AM

>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 11:58 PM

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 21, 2010 12:32 AM

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 22, 2010 5:25 AM

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 12:22 PM

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.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign


Sponsored byVerisign