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>
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/
===================================
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
