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

Edward Lewis Ed.Lewis at neustar.biz
Tue Aug 17 11:58:53 EDT 2010


At 8:13 -0700 8/17/10, Michael Sinatra wrote:
>That's why I want to be careful in how much blame I ascribe to the 
>protocol specification.  I understand why it's there and I do want 
>it to do the right thing, but I also want operators and deployers to 
>understand that it has a consequence in this case.

I've opened a discussion in the IETF WG on this...apparently there 
were previous grumblings.

>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?  (And vice-versa: If a 
>newly-fetched DNSKEY RRSet didn't match a cached RRSIG, then it 
>would re-fetch the RRSIG.)  Is that too much work for the validator? 
>And you'd have to be careful you didn't get into a fetching loop 
>like Microsoft once did with lame delegations in their 
>implementation...

One of the overriding issues is that caches may be "forced" to go 
through other caches and can't cause those caches to refresh.

>It seems the issue is, how does the admin of the authoritative zone 
>signal what algorithms are to be used for signing?  Currently, it is 
>the presence of the key in the DNSKEY RRset.  It also could be the 
>presence of the DS record(s) in the parent and/or trust anchor in 
>the cache.  But that is not currently the case--even if my only 
>trust anchor/DS record is algorithm 10, the presence of an algorithm 
>5 DNSKEY in the zone apex means there must be both algorithm 5 and 
>10 RRSIGs.

We want to rely on the DNSKEY set.

>A third way to signal is by setting some (currently nonexistent and 
>unspecified) flags in the DNSKEY records, which would mean more 
>protocol changes.  The idea is that the admin can signal that s/he 
>no longer wants the key/algorithm to be a requirement for 
>validation, and would allow for more graceful algorithm rollovers. 
>But that's a lot of work.

We've had bad experiences with flags.

>Assuming we're stuck with DNSKEY, the administrator has to take into 
>account cached DNSKEY and RRSIG sets, and/or set their TTLs to 
>ridiculously low levels to gracefully roll the algorithm.  But if 
>the caches could do a little more work to try to better determine 
>what the administrator is trying to do (by some careful refetching), 
>then we may be able to avoid cases II and VIII.

The latter sentence is what we need to pursue.  Sorry for the 
shortened responses here, I'm trying to prepare responses for the 
IETF WG discussion.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
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 mailing list