Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea (tm)

[Joe Abley <[e-mail]>]

[from a namedroppers thread, re-pointed as per Olaf's suggestion below]

On 2009-10-07, at 09:23, Olaf Kolkman wrote:

> On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote:
>
>> I don't have a general position on ZSKs--perhaps it's a good idea for
>> some other reason--but I don't
>> think that rolling the keys over at high rates provides any
>> significant security benefit, no matter
>> where in the hierarchy you're doing it.
>
> Really this is an DNSOP issues, more specifically an issue for  
> RFC4641bis.
>
> [I've added dnsop, please remove namedroppers when replying to this  
> note]
>
> RFC4641 argues for frequent ZSK rollovers, the argument therein is
> based on operational arguments that are (implicitly) based on operator
> acces to private keys and/or the timeline in which changes in which
> the (zone) operator may need to be replaced.

I skimmed through 4641 to try and refresh my memory, but couldn't find  
the discussion on ZSK rollover frequency. No doubt this is my  
deficiency.

 From my perspective the operational argument is that procedures which  
are rarely exercised may not be exercised well when they are needed (a  
backup that is not regularly tested cannot really be relied upon; a  
protect path that is never used might not work when it is needed, etc).

Frequent key rollover has the operational benefit of when you need to  
do an emergency roll you know the procedures work.

 From this perspective we might roll a ZSK more frequently than a KSK  
because the ZSK needs to be stored on-line to facilitate re-signing  
when the zone changes. With the KSK we have the option of keeping it  
off-line, and arguably the risk of compromise is consequently lower.  
Regular testing of the machinery is still important, however.

I am no crypto expert, but ekr's concern over the cryptographic  
benefits of frequent key roll seemed entirely reasonable.

I think the operational benefit is real, however.


Joe