DNS: March 2011 Archives


March 30, 2011

Over the past few years, there has been a lot of interest in putting TLS keys (or references to TLS keys) in the DNS (see here for background). Recently, IETF spun up the DNS-based Authentication of Names (DANE) WG which is designed to address this issue. The way that DANE for TLS works is that you can publish either:
  • A list of certificates (or hashes) which correspond to the TLS server itself.
  • A list of certificates (or hashes) which correspond to CAs in the TLS certificate chain.

In either case, the semantics are that the server certificate/chain must match one of the provided certificates. This match is both necessary and sufficient, which is to say that the client is supposed to accept an otherwise invalid certificate (i.e., one that it wouldn't ordinarily verify) if it is approved via DANE. Obviously, in order for this to work, you need to have the relevant DNS records protected with DNSSEC, since otherwise any attacker who can inject DNS records can simply generate a valid-appearing TLS connection, which obviates the whole point of TLS.

What's the point?
I've been trying to work out what I think about DANE for a while. My initial reaction was that it was a total non starter; anything that relies on DNSSEC has a huge deployment hurdle to jump. A little before today's WG, I started to rethink a bit. At a high level, it seems that DANE-type technology serves two purposes:

  • Cert lock: protecting the server from mis-issued certificates, e.g., one of the 100+ certificates embedded in your average browser other than the one that the legitimate server certificate was issued by.
  • Alternate certification: a lot of people complain that it's too inconvenient to get a CA-issued certificate (I don't really believe this) and putting keys in the DNS presents an alternative, allegedly easier avenue.

These objectives have fairly different value curves as a function of deployment. Cert lock is a mechanism for controlling the attack surface, so once you have deployed the DNS records, the value is roughly linear in the number of clients who are able to verify those records. If 50% of users deploy the ability to verify DNS-based certificates then that's 50% of users who aren't vulnerable to CA malfeasance.

By contrast, alternate certification's value is that you don't need to deal with a CA, so it saves you the cost of the certificate ($20-$100) plus whatever hassle it is dealing with the CA. However, if you don't get a CA certificate, than if X% of the users in the universe are DNS-certificate capable then 100-X% of users can't talk to you server at all without getting some horrible error/warning. So as a practical matter, you can't discard the CA-issued certificate until a very high proportion of clients are DNS-certificate capable. Since you obviously want clients to be able to talk to you this means you don't get any benefit at all until nearly all the clients in the world have upgraded.

So, I think that cert lock is a fairly compelling application of certificates in the DNS, whereas alternate certification isn't really that compelling, at least during the (very long) period when a large fraction of the machines in the world haven't upgraded.

Does cert lock need DNSSEC?
As of this morning, I thought that cert lock didn't really need DNSSEC. The argument runs like this: let's say that the attacker can forge DNS records. The worst he can do is suppress or replace the certificate indication in the DNS to point to his own certificate, but since that certificate must be valid and the ability to attack DNS implies the ability redirect traffic (via modifying A records) then he could have done this in any case, so DANE doesn't make this any worse. On the other hand, there may be some attackers who can't attack DNS, or clients who have cached copies of the cert lock records in DNS, in which case clients are protected from attack. So while DNSSEC is desirable, it's not actually required.

On second thought (and after some comments by Martin Rex), I'm a little less sure. An attacker who can intercept your connection is most likely also able to inject DNS records, so a naive client doesn't get protected by a cert lock style mechanism unless for some reason the attacker is unable to attack DNS. It's possible that a client might have a cached DNS record that contained a cert lock record, in which case it would be protected, but the duration of the cache time to live also limits the responsiveness of the client to unexpected certificate changes, so there are tradeoffs here.

Overall, then, I'm not sure how valuable I think a DNS-based cert lock mechanism is in the absence of DNSSEC. As they say, my views are evolving