DNSSEC versus certificates

| Comments (0) | COMSEC DNS
Sorry it took me so long to get back to this topic. In previous posts I started talking about the possibility of replacing DNSSEC with certificates. Obviously, this can be done technically, but is it a good idea? The basic argument here (advanced by Paul Vixie but also others) is that putting keys in the DNSSEC would better than the existing X.509 infrastructure.

From a cryptographic perspective, this is probably not true: DNSSEC uses generally the same cryptographic techniques as X.509, including supporting MD5 (though it's marked as non-recommended). It may actually be weaker: one potential defense against collision attacks with X.509 is to randomize the serial number, but it's not clear to me that there's something as simple with DNSSEC RRSIG RRs though presumably you could insert a random-looking record if you really wanted to. Cryptographic security isn't the main argument, though. Rather, the idea is that DNSSEC would be more secure for non-cryptographic reasons.

I can see two basic arguments for why DNSSEC would be more secure, one quasi-technical and one administrative. The quasi-technical argument is that there is a smaller surface area for attack. Because a Web client (this is more or less generally true, but Web is the most important case) will accept a certificate from any CA on the trust anchor list, the attacker just needs to find the CA with the weakest procedures and get a certificate from that CA. This works even if the target site already has a certificate from some other CA, because the client has no way of knowing that. By contrast, at least in theory only one registrar is allowed to authorize changes to your domain, the attacker needs to target that registrar. That said, domain name thefts have occurred in the past, and so it's not clear how good a job the registrars actually do. Moreover, it wouldn't be that hard to import this sort of semantics into X.509; the CAs would need to coordinate with the registrars to verify the user's identity, but that's not impossible. Another possibility would be to have a first-come-first-served type system where CA X wouldn't issue certificates for a domain if CA Y had already done so without some sort of enhanced verification. Obviously, this is imperfect, but it would at least make hijacking of popular domains difficult.

The second argument is purely administrative, namely dissatisfaction with CA operational practices. Here's Vixie: "frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down." That said, it's not clear that registrar procedures will be any better (again, there have been DNS name thefts as well), and it's quite possible that they would be worse. Note that in some cases, such as GoDaddy, they're actually the same people. Moreover, there needs to be some coordination between the registrars and the registries, and that's a new opportunity for a point of failure. Anyway, this seems to me to be an open question.

The most difficult problem with this plan seems to be deployment. So far, DNSSEC deployment has been extremely minimal. Until it's more or less ubiquitous, users and clients need to continue trusting X.509 certificates, so adding DNSSEC-based certificates to the mix marginally increases the attack surface area, making the situation worse (though only slightly), not better. And as usual, this is a collective action problem: as long as clients trust X.509 certs there's not a lot of value to server operators to transition to DNSSEC-based certificates, which, of course, means that there's not a lot of incentive for clients (or more likely implementors) to start trusting them either. It's not really clear how to get past this hurdle in the near future.

Leave a comment