-----Original Message-----
From: Richard Lamb
Sent: Monday, February 23, 2015 5:17 PM
To: Edward Lewis; Paul Hoffman; ksk-rollover@icann.org
Subject: RE: [ksk-change] Helping the panel name the reasons for the KSK rollover
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@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Edward Lewis
Sent: Monday, February 23, 2015 4:40 PM
To: Paul Hoffman; ksk-rollover@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@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.
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover