The immediate architectural question is whether we should support the storage of full keying data in DNS. See, right now, we’re just storing the hash of keying data — a nice, fixed size blob that can fit into a text record without much fuss. There’s a fundamental assumption with this approach: Any protocol we happen to use, will negotiate a public key (presently inside a certificate) at the application layer. DNSSEC only needs to be used to validate the data received at that layer.
Is the subject name correct?
Do I trust this particular Certificate Authority?
Has this certificate been revoked?
Are there any policies embedded in this certificate that mean I should reject it despite everything else being in order?
Shockingly, this required a decent amount of expertise to be able to handle correctly. So most programmers don’t — the amount of software out there that doesn’t even make sure it’s encrypting to the right identity is basically ‘almost everything that isn’t a browser’. The blame isn’t only on the APIs — certificates are really expensive to deploy organizationally, so a lot of companies just throw up their hands and do what they can. See: The Little Black Box project, which archives fixed private keys shipped on devices.
So, you end up with an interesting question: Why should a protocol even push a certificate at the application layer? Practically all the interesting semantics that were supposed to be extracted from the certificate are sort of inherited for free from DNS, now that it’s been enhanced with DNSSEC. So, at least in the common protocol case, why parse a cert? Why expose oneself to ASN.1, to manually checking policy fields, to all that rigamarole? In fact, why suffer the application layer burden of moving the cert blob itself?
It’s a legitimate question, and it doesn’t just affect new protocol work. Google has been investing a tremendous amount in TLS to try to reduce the number of round trips the protocol requires. See, the more round trips between client and server, the slower the protocol has to be. If TLS requires the certificate before initiating an encrypted communication, that’s another round trip.
If DNS can remove that round trip, TLS gets faster. Huzzah!
It’s not just TLS. Most crypto protocols could be simplified fairly significantly if they had a secure DNSSEC endpoint from which to request key material. If we’re to win the war on passwords, if we’re to get globalized IPsec security in the cloud, if we’re to get secure email, we desperately need simplification. Requiring certificates only when necessary, as opposed to any time a public key is needed, is a pretty big win from where I stand.
There are also very nice things that happen to IPSEC, if key material can be directly extracted. There’s a lot of complexity in IPSEC key exchange, and DNSSEC can potentially drop this entire portion of IPsec’s complexity load. That’s very nice.
What I’m pretty sure about, however, is that I don’t ever want to put full certificates into the DNS. This has been tried — in fact, there’s an RRTYPE for it: CERT. A number of implementations have actually gone with CERT, only to abandon the format after a while. The things are just too big.
So, does that mean DNSSEC can only bootstrap a small amount of trusted data? No. Lets talk in the next post about embedding large form data.