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

[Olaf Kolkman <[e-mail]>]

On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote:

> [ Moderators note: Post was moderated, either because it was posted by
>   a non-subscriber, or because it was over 20K.
>   With the massive amount of spam, it is easy to miss and therefore
>   delete relevant posts by non-subscribers.
>   Please fix your subscription addresses. ]
>
> On Tue, Oct 6, 2009 at 2:02 PM, Paul Hoffman <[e-mail]>  
> wrote:
>> At 4:09 PM -0400 10/6/09, Nicholas Weaver wrote:
>>> Eric Rescorla has an explanation why the zone signing key rollover  
>>> mechanism in DNSSEC for the root is a bad idea:  It doesn't  
>>> improve security and only makes things more complicated:
>>>
>>> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
>>>
>>>> The more general lesson here is that changing keys rapidly is  
>>>> nearly useless as a method of preventing analytic attacks. It's  
>>>> almost never practical to change keys frequently enough to have a  
>>>> significant impact on the attacker's required level of effort. If  
>>>> you're that close to the edge of a successful attack, what you  
>>>> need is a stronger key, not to change your weak keys more  
>>>> frequently. In the specific case of DNSSEC, just expanding the  
>>>> size of the packet by 10 bytes or so would have as much if not  
>>>> more security impact at a far lower system complexity cost.
>>
>> I won't speak for Ekr, but I see his argument being against ZSKs in  
>> general, not just at the root. It's the same
>> argument I have tried to make in DNSOP.
>
>
> 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.

EKRs argument is based on cryptographic strength and argues another  
view.

The current considerations need to be made more explicit.


I've added this as an issue to the issue tracker.

See (http://www.nlnetlabs.nl//svn/I-D-dnsop-rfc4641bis/trunk/open-issues/ 
)

I hope I can address a few of the issues before Yokohama.

--Olaf




________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam