davidb dives invarious musings and babblings.

I’m at the IETF this week, and so I get to turn my brain to thinking about IETF-y things, like Internet Drafts that I think should (and could) be written.

Idea #1: Cache Poisoning Resilience

This would be a draft that describes steps beyond RFC 2181 that a resolver must do to protect itself from cache poisoning. (RFC 2181 addresses this problem by introducing credibility rules in section 5.4.1.) Modern caching resolvers need to do more to protect themselves from name poisoning attacks like malicious CNAME chains. I would expect this draft to be able to lay out a few simple rules like:

• Discard any RRs in a response that are “irrelevant” (i.e., answer RRs that do not match qname/sname, addtional RRs that don’t match names in the RDATA of answer and authority RRs, etc.)
• Discard any RRs in a response that are not at or below the queried zone.

Idea #2: Authoritative Servers Should Not Chase CNAMEs

This is a draft discouraging authoritative servers from chasing CNAMEs out-of-zone (or, optionally, at all), based on conclusions presented in draft idea #1. This draft could either side-step or confront other possibly controversial things about CNAME processing, like whether or not the authority section should apply the head or the tail of a CNAME chain.

Idea #3: DNS Name Compression Standards

A draft mandating the DNS name compression only be done in one direction. Virtually all (or perhaps even actually all) implementations have DNS compression pointers only pointing to earlier in the message. This draft would propose that forward-pointing compression pointers should be treated as format errors. This would accomplish two things:

1. Simplify what implementers need to support when parsing messages, and
2. outlaw any possibility of having to deal with a compression pointer loop.

And, in the process, effectively codify standard practice.

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”.