IMHO, the suggested wording is backwards.
It's not that the ZSK effectivity period is shorter than the KSK's,
the KSK effectivity period is longer than the ZSK's. The reason is
operational, not cryptographic.
Way back in time (circa '99-'02)...consensus of those participating
in workshops was that it was wise to change the ZSK a lot but we
found it to be a pain to have to wait to tell the workshop
coordinator/registry operator to get them to update the key in the
workshop zone. So we invented the idea of ZSK/KSK. We just wanted
to have a KSK that lasted longer than a ZSK.
We rationalized that a KSK would last longer because 1) it generated
only a few signatures over the same time period compared to a ZSK, 2)
because it was only needed when the key set changed, it was open to
the air less frequently, and 3) since it was used only to validate
the key set, it could be longer (thus taking longer to do the
signature validation) but not needed in every validation (of records
in a particular zone). Because it was longer lasting we didn't have
to stop and get the attention of the parent so frequently.
(Reason 3 is why so many TLDs now have the KSK twice as long as the ZSK.)
I'm not saying that any of the above was smart wrt cryptography -
crypto-experts never made any statements to us back then. The KSK
being longer than the ZSK was for operational convenience.
Also, what was not anticipated was the coming of automated
provisioning, like that enabled by EPP, in reducing the latency of
getting the parent to make a change. (Around 2000, we envisioned
parent zone updates on the order of 1/day or n/week, not every 15
minutes.) At the time too - HSMs didn't exist in our world, and we
still thought that all signing would be done on a machine with an
air-gap to the Internet.
So many assumptions have changed...but the idea of KSK/ZSK hasn't.
If I were to fit this into the text below...
#<t>
# The motivation for having the KSK's effectivity period
# longer than the ZSK's effectivity period is rooted in the
# operational consideration that a change in the KSK involves
# interaction with an external entity, usually the parent zone
# or possibly a trust anchor repository, and this interaction
# is anticipated to have significant latency (including the
# need to verify the other party has made the necessary change.
#</t>
At 9:09 -0500 1/21/10, 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>
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
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
