Comments on draft recommendation from root KSK rollover design group
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 determined. 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 |