[Dnssec-deployment] cases - was Re: Barbie sez: "Algorithm rollovers are HARD!"
michael at rancid.berkeley.edu
Wed Aug 18 13:28:01 EDT 2010
On 8/18/10 9:58 AM, Andrew Sullivan wrote:
> On Tue, Aug 17, 2010 at 08:13:41AM -0700, Michael Sinatra wrote:
>> Would it be reasonable for the cache, in a situation where it saw an
>> algorithm mismatch between a cached DNSKEY and a newly-fetched RRSIG, to
>> re-fetch (ONCE only) the DNSKEY and then declare a validation failure if
>> it still didn't match?
> No, because the definite article there is wrong. If you're a cache,
> you can't tell whether there's another cache in front of you. This is
> annoying and bad, but it's the way the world is. And since you can't
> tell that other cache, "No, I really mean it, please invalidate your
> cache and go fetch the authoritative result," you're out of luck here.
>> It seems the issue is, how does the admin of the authoritative zone
>> signal what algorithms are to be used for signing?
> It doesn't. That's the reason that timing these changes is so tricky.
Moreover, even if we think that unbound is being too strict, there is no
way for an administrator to know that there aren't other clients out
there for whom an algorithm rollover will cause them to lose support for
validation. If I upgrade from alg 5 to alg 10 and have both algs in my
DNSKEY records, even if we agree that a client that supports both 5 and
10 should be able to validate if it has sigs for only one alg, I can't
rule out the fact that there are clients that have support for alg 5 and
not for alg 10. For those clients, even the spirit of section 2.2
demands that they return a validation failure in such a situation. Even
if I don't mind my zone becoming insecure for some clients, I *do* mind
if it goes off the air for these clients due to validation failure.
So, from an admin's perspective, I need take the extra steps regardless.
More information about the Dnssec-deployment