Dan Kaminsky's Blog

Well, we’ve got something that works.  So, of course we have to muck with it 🙂

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.

That happens to be true for most existing protocols, because most existing protocols were designed to interface with X.509.  The classic model is to connect, receive a certificate, and then interrogate that certificate against various requirements like:

• Is the subject name correct?
• Do I trust this particular Certificate Authority?
• Has this certificate expired?
• 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.

In the new model, all the above requirements effectively get subsumed at the DNSSEC layer.  If the TXT KEY1 record resolves at all, that means:

• The name was correct
• The one root — the DNS root — has validated the record
• The record hasn’t expired
• Since the record is short lived, it doesn’t need to be revoked.  Revocation basically happens all the time, by default
• Policies in the TXT KEY1 (Secure-Transport-Security, Secure Renegotiation) are available for review

In other words, most of the complexity around certificate validation disappears; if DNSSEC reports the name was resolved securely, you’re done.  (The cost is that, unlike with certificates, you need to have network access to validate the name.)

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!

(Yes, DNS has its own round trips — but DNS, unlike HTTPS or even HTTP, has a site-wide caching layer in front of effectively all users.  It was the failure to support this caching layer that ultimately made DNSCurve not work.)

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.

Thus, the first thing I’ll probably be implementing for Phreebird Suite 1.03 is support for inserting full key material into the DNS, instead of just a hash.  This might look something like:

http://www.hospital-link.org IN TXT “v=key1 pka=rsa e=65537 m=ANknyBHye+RFyUa2Y3WDsXd+F0GJgDjxRSegPNnoqABL2
QfQut7t9CymrNwnE+wMwaaZF0LmjSfSgRSwS4L6ssXQuyBZYiijl
rVh9nbBbUbS/brGDz3RyXeaWDP2BnYyrVFfKV9u+BKLrebFCDm
zQ0OpW5Ed1+PPUd91WY6NgKtT”

Not sure if this is the precise format I’ll implement — there are pros and cons to Base64, and I need to do my homework on PKCS1.5 type issues — but I’m convinced that being able to store the raw public key in DNS is useful.  I’ll come closer to a decision as I get closer to writing this code.  (Thanks to John Gilmore, who convinced me that something like this was necessary and helpful.)

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.