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

[Olaf Kolkman]

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 <paul.hoff...@vpnc.org> 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.

argument I have tried to make in DNSOP.

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

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.

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.



The current considerations need to be made more explicit.


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

Really this is an DNSOP issues, more specifically an issue for RFC4641bis. [I've added dnsop, please remove namedroppers when replying to this note] EKRs argument is based on cryptographic strength and argues another view. 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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop