Can we replace certificates with DNSSEC?

| Comments (0) | COMSEC SYSSEC
In the wake of the recent attack on MD5 in certificates (see my summary here), the topic of replacing X.509 certificates with DNSSEC has come up.
i wasn't clever but i was in that hallway. it's more complicated than RFC 2538, but there does seem to be a way forward involving SSL/TLS (to get channel encryption) but where a self-signed key could be verified using a CERT RR (to get endpoint identity authentication). the attacks recently have been against MD5 (used by some X.509 CA's) and against an X.509 CA's identity verification methods (used at certificate granting time). no recent attack has shaken my confidence in SSL/TLS negotiation or encryption, but 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.

The basic observation is as follows: the role of certificates in SSL is to bind domain names (e.g., www.educatedguesswork.org) to public keys. But this creates a parallel authentication hierarchy; the CA is attesting to your ownership of some DNS zone, but you also need to be able to control the zone itself, or people won't be able to talk to you. It's natural, then, to think about just stuffing your public key in the DNS. Unfortunately, you can't trust the DNS, at least not without DNSSEC. However, if you had DNSSEC (so the argument goes) you could stuff public keys into the DNS and people could then trust them and skip the whole certificate step. This is a fairly natural idea and has been proposed many times over the years (I remember proposing it back in 1996 or so).

It's not clear that this is really as useful as it sounds, for reasons I'll get into in a subsequent post. However, right now let's assume it's useful and explore the design space a bit.

Mostly when this topic comes up, there is a lot of discussion of encoding. In particular, there are two big issues:

  • Should we store certificates or keys?
  • What resource record type should we use?

Certificates versus keys
The argument for keys rather than certificates is straightforward: certificates are redundant. Most of the stuff in the certificate is various kinds of control information (issuer, serial, the signature, etc.) that isn't relevant here because the DNSSEC record is itself a quasi-certificate. And since this stuff is big and we'd like DNS records to fit within 576 bytes, it's naturally to strip things down as much as we can. There's an RR type for this for IPsec, but not SSL.

The counterargument here is that most of our software is already designed to deal with certificates and it's a pain to make it use raw public keys. For instance, if you're doing SSL, the server is going to send you a certificate and you can just memcmp() it against the certificate you get out of DNSSEC. Note that you don't need to use a real certificate here. Self-signed works fine. This also has the advantage that it's a a useful transition mechanism in settings where you don't have DNSSEC; if you have a mechanism for putting certificates in DNS, potentially you could use it as part of a mechanism to reduce client-server traffic (the client tells the server "I think I have your cert, don't send it to me if it has hash X") which doesn't rely on the DNS to provide authenticated data. Oh, adn btw, there already is an RR for doing this as well.

There's actually a third possibility: have the DNS store a digest of the certificate. This lets the DNS act as an authentication channel for the server certificate but doesn't chew up as much bandwidth as the certificate or the public key. Of course, that still requires some channel for the certificate, but if you're doing SSL that happens by default. It obviously works less well for non-cert protocols like SSH, and doesn't give you any kind of preloading benefit.

RR Type
The second issue is what resource record type should be used. While this seems like a topic that ought to be of interest only to DNS weenies, it turns out to be important for at least one reason: you can have multiple services with different keys running on different ports on the same host. As far as I can tell, none of the proposed mechanisms really provide for this. It's not really an issue for IPsec, where there is more or less one cert for each IP, but it's definitely an issue for SSL or SSH. One could imagine inventing a new record type which segregated by port, or using a TXT record, or... Anyway, my impression is that this isn't totally trivial.

Of course, we've totally ignored the question of whether this is a good plan. But this post is getting awfully long, so I'll deal with it in a subsequent post.

Leave a comment