[ksk-change] Helping the panel name the reasons for the KSK rollover

[Edward Lewis]

I’d like to offer some re-wording.  I may have misunderstood of the points
below were summaries of what has been said elsewhere (hence “data points”)
or whether this is a summary if what’s been said.  So let me know if my
suggestions are jumping the gun.

On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman at vpnc.org> wrote:

>When considering how and when to rollover the root KSK, the community
>also have to consider why. In the past, many different reasons were given
>by various community members, and other community members have stated
>disagreements with some or all of those reasons. Thus, in order to make
>the how and when decision clearer to the community, the new KSK rollover
>panel needs to make explicit the reasoning for a particular rollover
>design.
>
>The following are the most common reasons that have been given for why to
>roll over the root KSK. They are given using mildly positive language,
>and no counter-arguments are given. Each has a short-hand title to help
>facilitate the panel's thinking. If there are other reasons that someone
>in the community feels strongly about, it should be brought up so that
>the panel can consider it as well.
>
>--Paul Hoffman
>
>DPS statement -- Section 6.5 of the DPS for the root zone says that the
>KSK will be rolled over after five years of operation, and that time has
>already passed.

This connotes that the roll is over due, or about to be. The wording is
“after 5 years” and not “within 5 years.”  I wasn’t part of this
discussion, so perhaps there are those with a different memory than what
is printed, but the words here tell me the “clock” in a roll starts after
we have 5 years (and I’ll add “of experience running DNSSEC.”)  So, I’d
suggest changing to “5 years has lapsed” instead of “that time has already
passed.”  (Note, I would consider 6.5’s operation to begin in July 2010, a
quibble, so we haven’t quite reached the 5 year horizon but we are
certainly close enough to say we have.  I note this to perhaps clear up
when “operations” began - if we need to.)


>Cryptographic aging -- The longer a public key is known to an attacker,
>the longer the attacker has to determine the private key.

I would have thought “the longer and more often a public key is in use,
the greater the chance cryptanalysis can be performed to discern the
private key.”  (And you could throw in that the more the key is put to
use, the greater the chance it could be lost - hardware hits a bump and
zeros - or it could be stolen - someone walks off with the healthy HSM.)

I think it’s helpful to separate the failure modes of keys
(exposed/discovered, reverse engineered, lost, copied, stolen and whatever
else) so we don’t "keep tripping over these cords.”  My list probably
duplicates scenarios.

>HSM aging -- The hardware signing modules (HSMs) used for the root key
>have a guaranteed life of five years, and that time has already passed.

I think this is a misstatement.  I don’t want to confuse the story further
so I won’t offer corrective text but encourage someone more familiar with
the lifetime of components (particularly the batteries).

>
>Operational practice for ICANN -- It is good to test the steps of a key
>rollover so that the holders of the key have practice; this helps prevent
>mistakes during future rollovers.

And prepares one for un-scheduled (emergency) changes.


>
>Operational practice for operators -- It is good to test the steps of a
>getting new KSKs so that the users of the key have practice; this helps
>prevent mistakes during future KSK retrievals.

And prepares one for un-scheduled (emergency) changes.

>
>Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger
>than RSA/2048 and had better operational properties, and changing the KSK
>to use this will cause wider adoption throughout the DNSSEC community.

And, if I understand this correctly, smaller response sizes, a important
facet for DNS.  I haven’t confirmed this myself and hope that someone who
has numbers can contribute to this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20150223/0c1fa9a4/smime.p7s>