When should ICANN roll over the root Key Signing Key (KSK) that is at the core of the DNSSEC global chain of trust? How often should it do a rollover? What kind of notifications should be made in advance? What else should be considered?
These are some of the questions for which ICANN is seeking comment in their “Consultation on Root Zone KSK Rollover“. They want to hear from a range of people out there on several specific questions they list.
COMMENTS ARE DUE BY APRIL 12, 2013!
All comments are to be sent to [email protected]. Do note that submitted comments are posted publicly on ICANN’s website (which enables you to also see what others are saying) after being reviewed by their team.
To step back and explain this a bit, the “Root Zone Management Partners” of ICANN, Verisign and NTIA signed the root of DNS back in July 2010. For those who want the full details, the DNSSEC Practice Statement (DPS) for the root zone KSK spells out the process that occurred.
In keeping with common practice, there are two keys for the root zone: the Key Signing Key (KSK) and the Zone Signing Key (ZSK). The ZSK is used to sign all the records in the root zone – and the KSK is used to sign the ZSK. The ZSK is rolled over quarterly, as described in the DPS for the root zone ZSK.
The root zone KSK has NOT yet been rolled over since the key was put into production in July 2010.
Rolling over the keys in any kind of system such as DNSSEC is an important part of ensuring the system’s integrity. Generating and deploying new keys limits the exposure should an attacker somehow be able to compromise a key. ICANN has a contractual requirement to perform a KSK “within 5 years” of the deployment of the root zone KSK, i.e. by sometime in 2015.
ICANN is asking for comments on a specific set of questions (although the last one is rather open-ended):
- What prerequisites need to be considered prior to a first scheduled KSK rollover?
- When should the first scheduled KSK rollover take place?
- What should the IANA Functions Operator (ICANN) and the other Root Zone Management Partners do to gauge the technical and end-user impact of a KSK rollover following the first scheduled KSK rollover?
- How often should a scheduled KSK rollover take place, following the first one?
- How far should the published calendar for scheduled KSK rollovers extend into the future?
- What public notification should take place in advance of a scheduled KSK rollover?
- What other considerations are necessary for the Root Zone Management Partners to take into consideration prior, during, and after a planned key roll over?
They have also published a PDF file with more background and information.
From our perspective, this is an extremely important consultation and:
WE STRONGLY ENCOURAGE READERS TO SUBMIT COMMENTS BY APRIL 12th!
In our view within the Deploy360 team, we believe that the root KSK needs to be rolled sooner rather than later and should be rolled over on a regular basis. We believe there needs to be solid operational experience with rolling the root KSK so that in the unlikely event that the KSK ever should be compromised an emergency KSK rollover could be rapidly performed with minimal impact. We obviously hope that a compromise of the root KSK will never occur, but see value in having the operational experience so that an unscheduled rollover can be more of of a routine process. There may also be problems found in the initial KSK rollover and we need to find those issues out NOW while DNSSEC is still in the early stages of deployment. If we are going to break anything, lets do it now and fix things before DNSSEC gets massively deployed.
In speaking with others about this issue, I’ve generally found most people having a similar viewpoint. But I have seen some points of view in some mailing lists that we should not roll the KSK this early in the deployment as it could have a negative impact on DNSSEC deployment. As mentioned earlier, the counterpoint is that if a root KSK rollover breaks something, let’s find that out now.
ICANN wants to hear from you – and is again seeking comments up through April 12. Please take a moment to read the consultation document and provide comments if you can.
Note that there will be a session at the DNSSEC Workshop at ICANN 46 next week in Beijing specifically on this KSK rollover topic that will be available for remote viewing (albeit at 2:15pm Beijing time).
P.S. If you would like to understand more about key rollovers, section 4.1 of RFC 6781 goes into detail about different rollover processes.
UPDATE #1: When this post was first published, the comment due date in the block quote near the top incorrectly said the due date was April 20th. This was corrected.