Internet Society comments on Root Zone KSK Rollover
- To: "comments-root-zone-consultation-08mar13@xxxxxxxxx" <comments-root-zone-consultation-08mar13@xxxxxxxxx>
- Subject: Internet Society comments on Root Zone KSK Rollover
- From: Dan York <york@xxxxxxxx>
- Date: Fri, 12 Apr 2013 10:03:35 +0800
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