the good and bad of dnssec so

Late last year, Mike StJohns transcribed one of his DNSSEC-related rants into Internet-Draft form (recently expired). The name of his proposal, “Signature Only DNSSEC” has been referred to as “DNSSEC SO” in shorthand. Mike’s idea was soundly rejected by the IETF working group that it was presented to, DNSEXT. I’ll outline some theories why in a bit. But, its rejection was not because it was a horrible idea. In fact, from some points of view, it is a pretty good idea. In a nutshell, DNSSEC SO says:

• Drop the NSEC (née NXT) or NSEC3 records, and just concentrate on being able to positively verify records, and
• because successful chains of trust through zones don’t actually involve NSEC records, this can coexist with standard DNSSEC.

The draft certainly talks about other things (like off-tree chains of trust) which are interesting too, but this is the main thrust. By eliminating the NSEC records (what MSJ calls “Provable Non-Existence”, or PNE), you’ve simplified DNSSEC and, in one fell swoop, eliminated all of the angst generated by the NSEC records (leading to things like NSEC3 and on-line NSEC generation).

This isn’t to say that DNSSEC SO removes all of the Hard from DNSSEC, but it does go a long way. However, let’s take a look at the main purposes of DNSSEC:

1. Protect legacy and security-unaware Internet applications from DNS spoofing attacks, and
2. Enable new applications to use DNS as security scaffolding.

Purpose #1 is why (I believe) that DNSSEC was pursued in the first place. Purpose #2 was thought of later as a compelling reason to continue. Or rather, #2 is the reason why we would have wide-scale deployment of DNS in the absence of a highly publicized attack on the DNS.

And now we can see why DNSSEC SO was rejected: it is utterly useless for purpose #1. And, since most new applications have to live an world without universal DNSSEC deployment (SO or otherwise), DNSSEC SO isn’t as useful for purpose #2 as it might be.

Let me explain.

Standard DNSSEC (including things like NSEC3) says that DNS responses, after being validated, fall into one of three states (actually four, but never mind): SECURE, INSECURE, and BOGUS. That is: it validated and was signed; it wasn’t signed, but that was proven to be OK; and it failed to validated (for any reason). When a response is BOGUS, the response is withheld from the application. Thus, an unaware application is spared from the effects of the spoofing attack.

DNSSEC SO says that responses, after validation, only fall into two states: SECURE and NOT SECURE. That is: it validated and it was signed; or it wasn’t signed or didn’t validate. So spoofing attacks just get passed on the unaware client, which can’t distinguish them from normal DNS responses.

OK, so what about purpose #2? Imagine an application that might be aware of DNSSEC and might really want to use it for security scaffolding. Let’s call it DKIM, an application that looks up cryptographic keys in DNS for the purpose of deciding to accept or reject email. It might decide that it is only going to use DKIM keys that have been signed and verified by DNSSEC. This is great, and, in fact, DNSSEC SO works here just fine. However, at this point in time, DKIM cannot afford to restrict itself to only using keys signed with DNSSEC. Even with DNSSEC SO, it is going to take a while to get enough infrastructure in place so that any zone that wants to can be signed and trusted. And DKIM needs as many email senders and receivers to use it as possible.

…So why was DNSSEC SO rejected by the IETF? I suppose that everyone who spoke up saying “No” has his/her own reason, but my belief was that it was because DNSSEC SO rejects the initial requirement for DNSSEC, and that the initial requirement (purpose #1, above) is still valid. Also, the working group was obviously tired of working on DNSSEC, and DNSSEC SO represented another 6 to 12 month round of effort for what seemed like little gain. In other words, “too little, too late”.