[ksk-change] Helping the panel name the reasons for the KSK rollover
askuma at microsoft.com
Mon Feb 23 15:21:21 UTC 2015
Wondering if the rare case of the root KSK being discovered to be compromised should also get a mention in that list. Are not the others just precaution to avoid this case, or there are other steps when this happens?
From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org] On Behalf Of Paul Hoffman
Sent: Monday, February 23, 2015 20:45
To: ksk-rollover at icann.org
Subject: [ksk-change] Helping the panel name the reasons for the KSK rollover
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.
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.
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
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.
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.
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.
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.
ksk-rollover mailing list
ksk-rollover at icann.org
More information about the ksk-rollover