ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Comments on draft recommendation from root KSK rollover design group

  • To: comments-root-ksk-06aug15@xxxxxxxxx
  • Subject: Comments on draft recommendation from root KSK rollover design group
  • From: João Damas <joao@xxxxxxxxxx>
  • Date: Mon, 5 Oct 2015 13:38:31 -0400

Comments on draft recommendation from root KSK rollover design group

I would like to start by thanking ICANN and the design team to give the 
community the opportunity to provide comments on this draft document. I am 
including my comments below. I would also like to support comments that have 
been expressed by others, in particular those of APNIC labs strongly resonate 
with my own observations. I am not including those same comments below, even 
though I share and support them.

Justification of the need to roll the KSK
There is very little in the draft report reasoning for the need to perform a 
root KSK rollover at this time, or in the future. Given that the need for this 
elaborate process of study and consultation derives directly from the 
recognised existence of a risk of disruption to part of Internet operations it 
would be good to have some background on how the need for the rollover was 

This may well be outside the scope of work for the design group, having been 
handed a mandate about studying how to do it rather than why to do it but more 
references to those sources of decision input would be necessary.

Additionally, the two more frequently cited reasons are:

a) the need to kick the tyres so that there is up to date operational 
experience on how to perform a KSK rollover, particularly to ensure that the 
capacity to react to an unscheduled rollover process exists and the process is 
well understood is valid but might be better exercised in a controlled 
environment, that might itself share some of the production infrastructure and 
surely should share the methodology so as to ensure the applicability of the 
process to the real scenario.

b) the need to conform to the current text of the Root KSK DPS. While 
recognising that the DPS is there to be followed it is also true that it is not 
something written in stone and that there would be a lot less risk if the 
default rollover period stated in the DPS is recognised as part of standard 
template text that was left in place by all reviewers as an issue to consider 
for the future at a time when the goal was to get the root zone signed as soon 
as possible. Therefore an option to address this difference between DPS and 
current operational practice might just require an update to the DPS with text 
that addresses the circumstances and recommendations that would trigger a key 
rollover in more depth than the current text does.

As a last comment, the current draft document spends, as it should, a lot of 
effort in trying to analyse and issue recommendations for the process of 
publication of the incoming and outgoing KSKs in the root zone but does not 
address the need to re-examine the processes involved in the generation of the 
incoming key nor the signing of the ZSKs. As a TCR I am first hand witness to 
this process and understand the need for automation of the process. It would be 
good to note that this automation was put in place for a specific case where 
there is only one KSK in existence. I believe there is a need to review all the 
steps, from a procedural and implementation point of view to ensure that, for 
instance, the outgoing KSK is not cleared from the HSMs too early, that the 
correct key is indeed used at each step where it needs to be used, with 
consistency, etc.

Best regards,
Joao Luis Silva Damas

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy