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

[Ashley Heineman]

Just want to point out that "scheduled rollover of the KSK" was an original basic requirement when DNSSEC was implemented at the root.   Specifically (as referenced in the baseline requirements, with the footnote 12, http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.pdf):

"c) Root Zone KSK Rollover

i) Scheduled rollover of the RZ KSK shall be performed.12
 
12 The Department envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and
proposed by ICANN and VeriSign, based on consultation and input from the affected parties (e.g. root server
operators, large-scale resolver operators, etc). Note that subsequent test plans may specify more or less
frequent RZ KSK rollover to ensure adequate testing."



-----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 10:40 AM
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.