Internet Society comments on Root Zone KSK Rollover

[Dan York <york@xxxxxxxx>]

To: ICANN DNS Operations Staff

We strongly encourage ICANN to execute a rollover of the root zone KSK as soon 
as feasible and then to continue to do so on a regular interval.

We view it as an architectual inevitability that at some point in the 
relatively near future the root zone KSK will need to be rolled over. The 
emergence of new cryptographic algorithms, changing requirements for the key 
strength and even the stated battery life of the HSM devices used by ICANN all 
make it impossible to assume that the root trust anchor is cast in stone and 
will remain there forever.

Further, in the very unlikely event that the root zone KSK were ever to be 
compromised we believe there needs to be sufficient operational experience 
within ICANN to perform an unscheduled rollover of the root zone KSK with 
minimal disruption to the DNS. We do not see how this operational experience 
can be gained without performing actual rollovers of the root zone KSK. 

In the best scenario, we may find in performing a root zone KSK rollover that 
there are few if any impacts on the DNSSEC validation infrastructure and that 
DNSSEC validation continues as normal. Alternatively, we may find that some 
components of the DNSSEC validation infrastructure will break after a root zone 
KSK rollover.  If so, we as a community need to determine what those failures 
are, fix them, and then execute another root zone KSK rollover to verify that 
the fixes do indeed work. 

In order to minimize any potential impact, we would encourage ICANN, in 
conjunction with the larger community, to clearly identify and document the 
potentially affected parties and list the potential failures, symptoms, 
mitigation measures, etc. We would encourage ICANN to circulate this 
information widely and would note that parties potentially affected include not 
only network operators providing validating resolvers and users relying on 
validation but also application developers looking to build new DNSSEC-related 
capabilities such as the DANE protocol into their applications. We would also 
encourage ICANN to provide tools or procedures for potentially affected parties 
to identify and test the impact of the rollover before, during and after the 
key rollover. An awareness campaign prior to the initial KSK rollover will 
clearly be necessary.

We would also encourage ICANN to undertake any possible measurements of the 
DNSSEC validation infrastructure to attempt to quantify the potential impact. 
There are several efforts underway within the larger DNSSEC community to 
understand the actual deployment of DNSSEC-validating DNS resolvers. Those 
efforts and any additional work may help inform ICANN with regard to the number 
of parties that could potentially be affected by the rollover.

We believe that it is best to execute the root zone KSK rollover now while the 
deployment of DNSSEC-validating DNS resolvers is still relatively low. We are 
seeing growing interest in the deployment of DNSSEC-validating DNS resolvers 
and as more such resolvers are deployed the risk increases for a larger impact. 
We urge ICANN to move forward as quickly as possible with executing a root zone 
KSK rollover to minimize any potential impact.

As noted earlier, we believe that to gain the necessary operational experience, 
ICANN will need to roll the root zone KSK not just once but potentially several 
times initially.  We believe the first rollover should occur as soon as 
feasible.  There then needs to be a period of time when data is collected about 
any impact (or lack thereof) and, if necessary, fixes need to be developed and 
deployed.  A second rollover should then be performed to ensure that the fixes 
work and procedures are indeed automated.  Depending upon the results, 
additional rollovers may be required to ensure procedures are automated enough 
to not cause any trouble in the future.

As far as a timeframe between these initial rollovers, we do not have a 
specific recommendation as we could see the time required for developing and 
deploying fixes varying widely depending upon the complexity of any issues 
encountered.  Planning for a six-month interval would seem to be a reasonable 
interval.  The need is to have an interval short enough to go through the 
initial rollovers quickly but long enough to allow enough time for fixes to be 
deployed by the Internet service providers and network operators who operate 
DNSSEC-validating DNS resolvers as well as any application developers. We 
encourage ICANN to consult with service providers known to have deployed 
validating resolvers to determine the optimal interval between these initial 
rollovers. We also encourage ICANN to consult with ccTLD operators to 
understand their experiences with rolling their own KSKs and to understand 
what, if any, impacts were seen within their user communities.

Once these initial rollovers have been performed, ICANN should then have 
sufficient operational experience with rolling the root zone KSK and issues 
within the DNSSEC validation infrastructure should have been identified and 
fixed.  On this point, we would note that ICANN does need to have some public 
system in place for tracking any issues that are identified during this process 
so that the larger community can understand the issues and also be aware that 
the issues have been addressed.

After the initial rollovers, the rollover of the root zone KSK can move to a 
less frequent interval. We would suggest, though, that the interval should 
still be frequent enough that operational experience is not forgotten and that 
validation tools continue to be tested. An interval of two years seems 
reasonable, but this is just a suggestion and should undergo wider discussion. 
We would again suggest that the operational experience of ccTLD operators be 
gathered by ICANN staff and used when developing the policy.

The end result of this initial period is that rolling the root zone KSK should 
become a routine operation that is regularly executed by ICANN without any 
impacts to the DNS and to DNSSEC validation. At the point that it becomes 
routine ICANN will then be ready to perform an unscheduled root zone KSK 
rollover should such an event ever become required.

The ongoing deployment of DNSSEC represents a serious upgrade in the overall 
security of the Internet, but in order for that deployment to be successful the 
entire system needs to be both tested and trusted.  We encourage ICANN to 
proceed with rolling the root zone KSK along the
lines of what we have outlined here as soon as it is feasible to do so.

Thank you for the consideration,

Dan York and Andrei Robachevsky, Internet Society