[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"

[Edward Lewis]

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

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?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.