FINAL VERSION TO BE SUBMITTED IF RATIFIED
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
FIRST DRAFT SUBMITTED
The first draft submitted will be placed here before the call for comments begins.
Another proposed Draft (Hadia)
The At– Large Advisory Committee (ALAC) of the ICANN takes this opportunity to thank ICANN org for opening for public comments the plan to restart the Root Key Signing (KSK) Rollover Process and is glad to provide its comments herein
The postponement of the KSK roll over on 11 October 2017 was based on newly discovered information concerning validating recursive resolvers that might not be ready for the rollover, to this end ICANN org researched the new data to determine if it could be useful in determining when to roll the root KSK, however on 18 December 2017, ICANN org reported to the community the results of its research, in that report, ICANN detailed that the collected data does not provide any clear explanation as to why so many resolvers appeared to still be using only the 2010 KSK. Most of the messages received at the root zone that indicated that particular resolvers were not ready for the rollover were not helpful, ICANN org could often not determine which resolvers sent the message or why those resolvers had not updated their trust anchors. Additionally, even when the resolvers were identified efforts to contact the operator were often unsuccessful.
Taking into consideration that
- It is not for seen that new reliable data will be available soon.
- There is nothing to indicate that operators of DNS resolvers that are operating with only the 2010 KSK will fix their systems soon.
- The existence of DNSSEC is important to protect the integrity of the DNS data, where DNSSEC applies digital signatures to DNS data to authenticate the data's origin and verify its integrity as it moves throughout the Internet.
- It was agreed that each root zone KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation and 6 years have already elapsed
- Postponing the KSK rollover might put the security of the DNS at risk, where the key could be compromised, lost among others risks stated in the SSAC Advisory on DNSSEC Key Rollover in the Root Zone on 7 November 2013.
The ALAC recognizes that while it is important to guarantee that the users affected are as minimum as possible it is equally important for the security of the DNS to proceed with the KSK Rollover. To this end the ALAC supports the proposed plan for the KSK rollover while highlighting the importance of an extensive outreach plan and requesting a detailed PR plan that includes all the necessary information and documents, and post-rollover recovery guides for unprepared DNS resolvers, This is in addition to the recommendations previously mentioned in the
-----------------------------------------------------------------------------------------------------------------------------------------------------
The ALAC is pleased to have the opportunity to comment on the “Plan to Restart the Root KSK Rollover Process”.
DNSSEC changes the nature of the most decentralized service of the Internet, the DNS, fundamentally. It transforms a lightweight "lookup table" into a trustworthy database. It's trust is made up of two important fragments: solid cryptography implementations and transparent operations.
DNSSEC anchors the zone trust by hopping the delegation hierarchy backwards. But this process does terminate at the root. Implementing the trust for the root itself is incredible hard, ultimately it's not a technical problem at all. At this point, the trust (KSK) information needs to be put in the hands of countless network operators all over the world. This task is attributed to ICANN. AtLarge has to do it's own outreach on this subject using it's own distributed structure.
Cryptographic elements always have a lifetime, if they are keys or algorithms. It is good operational practice to change the keys regularly in order update the material and to ensure, that all processes are still in place. Changes of algorithms require a working key change process. Therefore the important root keys (where all the trust is rooted) need to be changed, too.
During the preparations of the rollover, various issues arose especially from embedded and operator-less devices. Efforts were made to estimate the impact of an KSK change for affected user groups. But all the data is still vague.
The proposed plan is to schedule the rollover for October this year, missing two possible earlier dates. The gained time should be used for intensify the communication with the network operator crowd out there. Waiting for new protocols to be deployed in order to guess more accurately is not an option. So the communication should concentrate on preparation check lists and post-rollover recovery guides for validating recursors.
ALAC supports this plan: Shifting the schedule by exactly one year makes is much more easy for outsiders to keep in time with the activities. April is clearly to short for the necessary communication. Starting in July will collide with holiday breaks in several countries. Because we depend on the operators, the October date is more appropriate in terms of workload and memorizing the important dates.
The rise of IoT starts to create swamps of non updateable network devices. If the KSK rollover is further delayed, more and more such devices will be deployed, all of them unable to deal with an upcoming KSK change. The only chance to get those developers and companies on board is to rollover the KSK. Regularly.
-------------------------------------------------------------------------------------------------------------------------------------------------
