On Jan 21, 2010, at 3:09 PM, Rose, Scott W. wrote: > Perhaps the wording is a bit incorrect in that it an insider attack (the > admin accessing the key) is not the biggest threat. The ZSK is accessed > more often and if it isn't on an HSM (or similar), there could be a risk > that it could be exposed by someone other than the responsible DNS admin. Of > course the use of an HSM minimizes this risk. > > How about this as suggested text? > > <t> > The motivation for having the ZSK's effectivity period > shorter than the KSK's effectivity period is rooted in the > operational consideration that the ZSK may be at more > risk of exposure as the ZSK is often used more frequently > (e.g. zone data updates, etc.). If ZSK's are maintained on > cryptographic Hardware Security Modules (HSM) than the > motivation to have different key effectivity periods is > weakend. > </t> >
I understand EKR's remark (thanks) in addition to the improvement Scott suggested there is the argument that if a rollover remains a special event it is bound to go wrong, while if it is part of regular operational procedure the operators do not have to go through the learning curve. That argument works, but not in the case that EKR brought up, if _the_ operator gets sacked the rollover done by the new one is the first one that new operator does, she wouldn't have the benefit of operational routine. --Olaf [nothing below, only context] > Scott > On 1/21/10 8:34 AM, "Eric Rescorla" <e...@rtfm.com> wrote: > >> I'm not really an active member of the WG, so I certainly wouldn't say that >> my position has much of an affect on consensus, but I'm unconvinced >> by the argument offered below. >> >> Sure, the ZSK is at greater risk because operators have access to it, but >> so what? If an operator actually steals the key (or, say, is fired), you >> change the key then. However, given that you allow the operator to sign >> stuff with the key as long as he's employed, I don't see how repeatedly >> changing it during that period offers much value at all. >> >> -Ekr >> >> >> On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman <o...@nlnetlabs.nl> wrote: >>> >>> >>> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has >>> the open issues listed and a per issue highlight of their history. >>> >>> This issue is captured in >>> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency >>> current content of that page is replicated below. >>> >>> I welcome substantive discussion on-list while I'd be happy to receive >>> editorial comments off-list >>> >>> If the chair believes the current text captures consensus I will move this >>> issue to the closed issues list. >>> >>> --Olaf >>> >>> >>> $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $ >>> 2008090101 >>> ZSK-roll-frequency >>> EKR/ Paul Hoffman >>> Added: 7 Oct 2009 >>> >>> See: >>> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html >>> >>> >>> 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. >>> >>> Resolution: >>> >>> >>> Added the following paragraph to section 3.3: >>> >>> <t> >>> The motivation for having the ZSK's effectivity period >>> shorter than the KSK's effectivity period is rooted in the >>> operational consideration that it is more likely that >>> operators have more frequent read access to the ZSK than to >>> the KSK. If ZSK's are maintained on cryptographic Hardware >>> Security Modules (HSM) than the motivation to have different >>> key effectivity periods is weakend. >>> >>> </t> >>> >>> ________________________________________________________ >>> >>> Olaf M. Kolkman NLnet Labs >>> Science Park 140, >>> http://www.nlnetlabs.nl/ 1098 XG Amsterdam >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > =================================== > Scott Rose > NIST > sco...@nist.gov > ph: +1 301-975-8439 > Google Voice: +1-571-249-3671 > > http://www.dnsops.gov/ > =================================== > ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
