Paid Advertising
web application security lab

DNSSEC + Certs As a Replacement For SSL’s Transport Security

I was talking with id last night, and then shopped this idea around to a couple local OWASP guys, but now I think it’s baked enough to talk about publicly. I make no bones about the fact that I think SSL is almost entirely worthless against a determined attacker who has man in the middle access and is intent on doing harm, and not just passively listening. Passively listening is limited to people who can get access to a valid cert (through MD2/MD5 collisions, through being a CA or hacking a CA, etc… all of which have been proven possible). That’s bad enough, but put into that that the visual cues tell you nothing about site authenticity (leaving EV certs out of this for the time being) and you’re left with a nearly completely broken security mechanism in the browser. You can debate this fact all you like, but what if I don’t care about site authenticity, I just want to do transport security?

An idea we began toying around with is using DNSSEC. Like DKIM, you can put public certs into DNS records that can be queried by any mechanism that wants to use that. By making a change to the way browsers work to look at the DNS record via DNSSEC a few things become possible. Firstly, you can be assured that you are talking to the correct IP address after the negotiation is complete. That is because the DNS record cannot be spoofed (thanks to DNSSEC) and the certificate can prove that the IP you are talking to is really in control because it can verify that it is the owner of the public key. But wait - there’s more!

SSL certs cost money - but that’s because the CA’s infrastructure needs to be supported. In this model, there is no additional weight on any central authority, outside of DNS itself. So you could theoretically kiss the need for expensive certificates goodbye (sorry CA’s your time may have come!). This obviously couldn’t replace SSL certs in day one, or maybe not even for many years, but for internal applications or for when I want to allow all you readers to ensure you are talking to this server, and not another one, that suddenly becomes possible. It also becomes possible for people in 3rd world countries who cannot afford costly certificates to be able to gain transport security in the browser.

Now you’re probably saying - how is this different than a self signed cert. Well, leaving out of it that the CAs are vulnerable, there are dozens of them that can create certs to MITM you - of foreign origins and that they suffer from collisions… there’s still one major difference. The browser intentionally throws a warning with self signed certs, and even if it didn’t I still can’t verify that it’s my self signed cert and not someone else’s without a significant amount of burden placed on the user.

So now you’re probably saying, there are two single points of failure introduced here - the DNS server and the DNSSEC service itself. Why place additional security burdens on the end user? Well, I’d argue that if DNSSEC is broken, we have a much much bigger problem on our hands than we do than if a CA gets broken into even. If we can secure a CA we should be able to secure a DNSSEC service. I’m not worried about that one nearly as much as I am the individual DNS servers themselves. However, remember that their company already relies on DNS. Let’s say they use Godaddy and rely on them to be primary NS. We’ve already been relying on them to provide lookup security for years. The only difference is now they’re using DNSSEC and now we entrust them with the security of the transport.

The reason I like the idea is that it gives the domain the option to choose - pay for an SSL cert that can be MITM’d or get a free DNSSEC domain cert that can’t. I can’t stop someone from trying to make money off this idea and selling EV DNSSEC domain certs, but I see no reason we can’t make a non extended version completely free to all. Consider this a preliminary RFC - flame away!

14 Responses to “DNSSEC + Certs As a Replacement For SSL’s Transport Security”

  1. Jules Bonnot Says:

    This has been the idea from the beginning and is, incidentally, why those who control TLDs like .com (ahem verisign) have been “reluctant” to sign their roots. Because, obviously, this would eventually put them out of the CA business. It is one of the main reasons why many believe that DNSSEC will never happen.

  2. RSnake Says:

    Interesting - self serving interests making the world less secure. The only way we can move forward is to apply pressure to those who would stand in our way - boycotting those who aren’t along for the ride. Voting with your dollars.

    Anyway, I’m glad smart people have already thought of this. I look forward to the day when/if this becomes a reality.

  3. Steve Says:

    I don’t see any reason to expect that DNSSEC will be cheaper than X.509 CAs. To make DNSSEC work, the registries or registrars have to sign the subordinate certs (otherwise you can’t be assured of anything), and I can’t see why they aren’t going to plan to charge for that service, and why that service should be priced differently than X.509 CAs. The issue will come down to how the registry operator cares for their private key (otherwise, why trust that the signature is worth anything, and DNSSEC comes tumbling down). In the X.509 world, the CA has to publish and adhere to a certification practice statement, and there are audits of their practices. Registry operators will almost certainly have to do the same thing.

    We remain screwed, don’t we?

  4. Wlet Says:

    I heared that proposal already here in Germany from Lutz Donnerhacke. With all that DNSSEC stuff in place you can also set up anything for secure email (no more keyservers) and verifiy ssh hostkeys (generate it once and put it in a signed record) with dnssec.

    A downside: With larger DNS entries the DNS Reflection DDOS attacks get more weight.


  5. RSnake Says:

    @Steve - not at all, I sign one key at the top, then DNS comes down to my server where I server up as many certs as I want.

    @Wlet - potentially that is true, but there are ways of distributing your DNS if that’s really an issue.

  6. Victor Ramiro Says:

    DNSSEC is designed to give authenticated answers between authoritative server and the resolver (usually an ISP resolver for most internet users). From the resolver to the end-client is not necessarily checked if the signature was or wasn’t done by a given trusted key (except for the AD bit-flag in the response). The idea here exposed implies that end-clients should be able to verify signatures. This will introduce a lot of overhead to all authoritative servers around, since each end-client will be a resolver itself, asking for all RRs involved and verifying locally the signature validity. This, whithout mention bandwidth consumption and routers filtering problems with EDNS answers (used by DNSSEC).

  7. RSnake Says:

    @Victor - can you give an estimate as to what the additional overhead might look like? Is there a way we could cut that down to a reasonable level? I’m definitely open to suggestions.

  8. Michele Orru Says:

    Great article Robert, by the way: I definitely agree with you. After the latest attacks on SSL of Marlinspike & company :), we’re all really scared about the future of online secure transactions and so on. Combining these attacks with BGP attacks can really lead a malicious hacker to rule the world.

    Speaking from an Ethical pen tester point of view (not the geek guy that spent nights on hacking all sort of stuff :) ):
    Your statements here are all correct, but I think that we should stop to see security as something that will break compatiblity, consume more bandwidth and so on. I mean, security (at least in the Transport layer) is something it should be unbreakable, something we should trust on. So an overhead on bandwidths, some headaches on re-configuring routers and build new DNSSEC aware clients is something needed for me.

  9. Scott Dier Says:

    Why not have the authoritative servers deliver the (authenticated) hash of the CA certificate(s) for that domain as one or more TXT records? Then have a record in a certificate presented by a webserver over https that informs the client as to where that domains CA key (over http) can be retrieved from. Certificate engine grabs that cert, verifies its correct against the hash provided by DNS (authenticated by dnssec) and places it as a trusted key for hosts only within that domain. (and have knobs for the paranoid to check each addition by hand)

    Problem is this pushes the PKI ‘problem’ out to edges, sounds great for those of us who can wrap our heads around how to run a PKI efficiently within an organization (and those who can turn this into a dns/pki appliance) but to the average joe businessperson they’ve been outsourcing PKI issues for years. This isn’t (shouldn’t?) part of most companies core business and paying someone else to do it (even at omfg rates) has worked in the past. Why change now?

    Lastly, this really only solves the use case of internet connected devices. non-connected devices such as laptops trying to login through a wpa-enterprise network they’ve not seen before can’t engage in this sort of procedure and would need to ‘revert’ to ‘traditional’ pki.

  10. Dan Kaminsky Says:

    Anyone who spends any time with DNSSEC realizes eventually it’ll be used for much more than simply validating IP addresses. In fact, the validation of A records almost becomes a secondary perk, compared to the ability to bootstrap trust of other protocols.

    X.509 doesn’t scale for two primary reasons: First, it can’t exclude. This means that it doesn’t matter how good your own certificate authority is; some other guy can issue certs freely because he feels like it and browsers will trust his cert just the same. The second is that it can’t delegate. For all the astonishing complexity of chain validation, the ability to *constrain* those chains — for example, to allow an intermediate certificate to only sign for names under * — is nonfunctional enough to be considered absent.

    DNS, even independent of DNSSEC, suffers neither of these faults. At the root level, there *is* no “other root” to exclude, but to corrupt this one you have to attack an adjunct of the state system. Good luck with that. For the TLDs, there’s one *and only one* company that controls each. Only Verisign can corrupt com. Only Afilias can corrupt info. Each excludes the rest.

    Of course, we don’t deal directly with Verisign or Afilias. We deal with Registrars, like GoDaddy and eNom. But look: Since there’s a canonicalization point at the TLD, if there’s a hack at a registrar, you can actually *leave* that registrar, transfer your domain, and be insulated from its insecurity.

    You can’t do that in X.509. And this is just DNS.

    DNSSEC really isn’t that complicated. It’s just adding signatures — and a key transition method — to DNS. Most of the goodies we need for security to scale, come from good ol’ DNS, which has worked remarkably well for a quarter of a century.

    Now, that being said, a ton of work has to be done once the root is signed. It needs to get much, much easier to host signed records — really, it has to be as easy to run DNSSEC as it was to install my patch. And we’re going to have to rethink how endpoints establish end-to-end crypto when the signatures are extracted from the DNS heirarchy. This can involve full recursion in the clients, relegating existing name servers to a mere caching layer. Or it can involve other protocols, such as SSL, providing recently cached DNSSEC chains in-band.

    Yes, we’re going to have to do some work. But nobody can say what we’re doing today is working. So this should be interesting.

  11. Shewfig Says:

    For a method of providing tamper-resistant delivery of small content, DNSSEC seems like a good method - but the key assumption here is that DNSSEC isn’t broken. I want to poke holes in that, because you’re adding a lot of eggs to this basket, and a basket full of eggs is a yummy target.

    Trust in the root DNS record happens through the trust anchor(s). After I trust the identity of the root, I can validate the source and content of anything it gives me - or rather, that the content is the same as whatever was uploaded to it.

    Actual trust, of course, requires that, for the groups that maintain the various branches of the DNS tree hierarchy, the policies, processes, and practices are well-formed and well-executed.

    The first attack vector against the basket of eggs appears to be a “domain hijacking” attack - convince whoever/whatever maintains the parent of the node you’re attacking that you’re authorized to make a change, then do a server replacement with internet-wide visibility. “Best” idea is probably only to replace the KSK, so the “real” site owner can maintain the “real” records. The egg is now hard-boiled: looks the same on casual inspection, but if you own the KSK, you own the zone. Once you’re ready to spring the trap, you can replace anything you want, and reveal that the egg has been poached.

    I like the idea of leveraging the signature expiration date. If it really is only 30 days, then there’s 12 opportunities each year when the zone data _must_ be refreshed, and this is likely the only time that the admins will look at the zone. Furthermore, the expiration date _must_ be public to be any good, so streamline your attack in as a social-engineered follow-up to the zone update 1 day after the update (”the normal guy just left on vacation, he’s on a plane for the next 6 hours, and our web site just fell off the ‘net!”). DNS records are yours for the next 29 days.

    I also like the idea of re-signing the domain yourself, so the “real” owner, presumably unfamiliar with DNSSEC, won’t think it’s necessary. Any good hack should reduce the burden on the real administrator.

    Second vector will be a client-side attack. ‘Nuff said. (Depending on the exploit, the severity will vary from “sunny side up” to “over hard”.)

    Third vector will probably involve something technical (”scrambled”), like abusing the CD bit to tell the server not to validate the data, but tell the client the that the data is good. Vendors generally suck at implementing corner cases of specs. However, this will be hard because presumably the requests and responses themselves will be tamper-resistant. The exploit announcement will fill a room at DefCon, but not actually be useful.

    Fourth vector - malicious DNS server? Eggs Benedict?

  12. Wladimir Palant Says:

    Just a side-note: Firefox actually makes self-signed certs useful. Once you’ve added a permanent exception for that particular self-signed cert it will no longer warn you. Same cert on a different host or different self-signed cert on the same host will produce a warning however. And these exceptions are easy enough to distribute in company networks - copy cert_override.txt file to existing user profiles and place it into the default profile for the new profiles to pick up.

    In general: neat idea though I’m not convinced that DNSSEC is really tamper-proof. In particular, DNS management tools are an obvious (and already used) attack point. Sure, a website owner who looses control over his DNS zone has bigger problems. But now an attacker will not only be able to redirect traffic to his own server but also easily fake a secure connection.

  13. Jakob Schlyter Says:

    I wrote an Internet draft about this back in 2002

    … and my co-author Leif has recently followed this up with the following draft

    Comments on both these documents are most welcome! (you’ll find my email address on

  14. RSnake Says:

    @Jakob - thanks for the links. This recent news puts another nail in the coffin of SSL’s security:

    Why are people still saying SSL solves our problems?