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

From: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Oct 2009 16:09:53 -0400

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.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Oct 2009 14:02:49 -0700

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

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Oct 2009 14:08:16 -0700

[ 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. ]

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

-Ekr

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 7 Oct 2009 09:23:18 +0100

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

>>> mechanism in DNSSEC for the root is a bad idea:  It doesn't  
>>> improve security and only makes things more complicated:
>>>
>>>> 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  
>>>> 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.
>
>

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

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 7 Oct 2009 10:33:15 +0100

On Oct 7, 2009, at 9:23 AM, Olaf Kolkman wrote:

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

s/Yokohama/Hiroshima/

Should I call my travel office? ;-)

--Olaf