[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"
Ed.Lewis at neustar.biz
Tue Aug 17 09:00:24 EDT 2010
At 23:07 -0700 8/15/10, Michael Sinatra wrote:
>The problem is that this method can lead to validation failures and zone
>bogusity if not done exactly right. The reason is to accommodate those
>implementations that enforce (probably correctly) a strict interpretation
>of the last paragraph of section 2.2 of RFC 4035:
> "There MUST be an RRSIG for each RRset using at least one DNSKEY of
> each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
> itself MUST be signed by each algorithm appearing in the DS RRset
> located at the delegating parent (if any)."
>Here's the wrinkle: Although I can remove all algo 5 DS records in the
>parent, as long as I have an algo 5 DNSKEY in the DNSKEY RRSet, I MUST
>continue to sign with algo 5 (using, of course, one of the algo 5 keys
>in that DNSKEY RRSet). Moreover, clients who have cached the DNSKEY
>records WILL experience validation failures until TTL+propagation delay
>after you remove the algo 5 DNSKEYs, *if* you stop signing with those
>keys when you remove them. I have verified this with such an
>implementation (unbound 1.4.6, which strictly enforces RFC 4035 section 2.2).
>The irony is that RFC 4035 section 2.2 is designed to prevent algorithm
>downgrade attacks, but it also makes *upgrading* algorithms more difficult.
I'm having a little trouble coming to understand this as a protocol
issue, so I gotta ask something. It might be a validation algorithm
The issue is when a cache receives a set and attempts to validate it.
Here are the cases:
The cache has:--> old-alg-only both-alg-keys new-alg-only
The cache gets-v
Old sig only I II III
Both sigs IV V VI
New sig only VII VIII IX
Case I, II, IV, V, VI, VIII, IX are no problem, right?
Case III - the signature's key is not around anymore. In this case
validation will fail. If we include RFC 2181's trustworthyness
calculation, the cache should be aware that it should seek a more
authortitative version of the set. I am assuming this case only
happens when the subject cache has learned this off another cache.
Case VII - the problem is that the cache holds the set with the old
key and perhaps that has the highest trustworthiness (the authority
itself). This is the one case we have to avoid - and I believe that
through TTL management we can.
Is there a problem in one of the other cases?
NeuStar You can leave a voice message at +1-571-434-5468
Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
More information about the Dnssec-deployment