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

[Richard Lamb]

The assumption was a HSM replace before 5 years (to be conservative since minimum battery life is 5 years according to spec sheet*) ...and - given strong interest by the community for exercising KSK rollover early on - KSK roll at same time given we would be replacing the HSM anyway.  Not so much because the KSK might be compromised but to exercise the process and understand the effects sooner rather than later. So the wording in the DPS specifically doesn’t say the KSK must be rolled.

*attached.  The manufacturer has said this was a conservative estimate based on tamper circuitry current draw so even if battery date code - which are stamped on the rear of the units - preceded purchase dates, we should be ok. I understand we are replacing HSMs in April so this should no longer be an issue.


-----Original Message-----
From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org] On Behalf Of Edward Lewis
Sent: Monday, February 23, 2015 4:40 PM
To: Paul Hoffman; ksk-rollover at icann.org
Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover

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: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20150223/03b4f15c/smime.p7s>