PUBLICCOMMENTCLOSE
2018-04-02 00:00:00.0 UTC
STATEMENTNAME
<p><a href="https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en">Plan to Restart the Root Key Signing Key (KSK) Rollover Process</a></p>
STATEMENTSTATUS
<p><ac:structured-macro ac:name="status" ac:schema-version="1" ac:macro-id="9639f7ae-5e24-49f4-bccf-4bd712782f67"><ac:parameter ac:name="colour">Green</ac:parameter><ac:parameter ac:name="title">ADOPTED</ac:parameter></ac:structured-macro></p><p>13Y, 0N, 0A</p>
STATEMENTASSIGNEE
<p><ac:link><ri:user ri:userkey="8aa0802249f42f260149f430898e000f" /></ac:link></p><p><ac:link><ri:user ri:userkey="8aa0802257ef2f160159203824ca002b" /></ac:link></p><p><ac:link><ri:user ri:userkey="8aa0802257ef2f160158c08697500018" /><ac:plain-text-link-body><![CDATA[Javier Rúa-Jovet]]></ac:plain-text-link-body></ac:link></p><p><ac:link><ri:user ri:userkey="8aa0802249f42f260149f4308bb0043b" /></ac:link></p><p><ac:link><ri:user ri:userkey="8aa0802249f42f260149f4308992002e" /></ac:link></p>
STAFFCONTACT
<p class="contact-name">Paul Hoffman<br /><a href="mailto:paul.hoffman@icann.org">paul.hoffman@icann.org</a></p>
STATEMENTNUMBER
<p><strong> <strong>AL-ALAC-ST-0418-02-01-EN</strong><br /></strong></p>
PUBLICCOMMENTINFO
<h2>Brief Overview</h2><p><strong><em>Purpose:</em></strong> This Public Comment seeks public review of the plan to roll the root key signing key (KSK). The plan includes more publicity about being prepared for the rollover, analysis of the data being seen indicating the level of preparedness, and the actual rollover itself on 11 October 2018.</p><p><strong><em>Current Status:</em></strong> The technical community discussed possible ways to determine when to roll the root KSK on the <a href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a> mailing list, and <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> used that discussion as the basis for this plan.</p><p><strong><em>Next Steps:</em></strong> <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> organization will prepare a final plan that bases on the input from the public comments and present a full plan to the <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> Board for approval.</p><h2>Section I: Description and Explanation</h2><p>The Plan for Continuing the Root KSK Rollover (<a href="https://www.icann.org/en/system/files/files/plan-continuing-root-ksk-rollover-01feb18-en.pdf">https://www.icann.org/en/system/files/files/plan-continuing-root-ksk-rollover-01feb18-en.pdf</a> [PDF, 93 KB]) describes how <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> intends to roll the root key signing key (KSK). It is based on input from the community that followed <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr>'s earlier decision to postpone the rollover. In summary, the plan is to roll the root KSK on 11 October 2018 after more publicity that is intended to help prepare operators for the rollover and making more data about the preparedness available.</p><h2>Section II: Background</h2><p>In 2009, the <abbr title="Root Zone">Root Zone</abbr> Management partners (<abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> and Verisign, also called the “RZM partners”) collaborated to deploy <abbr title="Domain Name">Domain Name</abbr> System <abbr title="Security – Security, Stability and Resiliency (SSR)">Security</abbr> Extensions (<abbr title="DNS Security Extensions">DNSSEC</abbr>) in the root zone, which culminated in the first publication of a validated signed root zone in July 2010. That signature was based on a key signing key (KSK) that is maintained securely by <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr>. It was later 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.”</p><p>In December 2014, <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> solicited volunteers from the community to participate with the RZM Partners in a Design Team to develop the <abbr title="Root Zone">Root Zone</abbr> KSK Rollover Plan. That plan was put out for public comment on 6 August 2015, and was published on 7 March 2016.</p><p>On 27 September 2017, <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> announced that the plan to change the cryptographic key that helps protect the <abbr title="Domain Name">Domain Name</abbr> System (<abbr title="Domain Name System">DNS</abbr>) is being postponed. On 18 December 2017, <abbr title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr> began collecting comment from the community about the acceptable criteria for proceeding with the KSK rollover. The result of that discussion on the <a href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a> mailing list is the plan that is now open for comment.</p><h2>Section III: Relevant Resources</h2><p><strong><em>Plan for Continuing the Root KSK Rollover</em></strong>: <a href="https://www.icann.org/en/system/files/files/plan-continuing-root-ksk-rollover-01feb18-en.pdf">https://www.icann.org/en/system/files/files/plan-continuing-root-ksk-rollover-01feb18-en.pdf</a> [PDF, 93 KB]</p><h2>Section IV: Additional Information</h2><p><br /></p><ul style="margin-left: 20px;"><li><em><abbr title="Root Zone">Root Zone</abbr> KSK Rollover</em>: <a href="https://www.icann.org/resources/pages/ksk-rollover">https://www.icann.org/resources/pages/ksk-rollover</a></li><li><em><abbr title="Root Zone">Root Zone</abbr> KSK Rollover Plan</em>: <a href="https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf">https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf</a> [PDF, 1.19 MB]</li><li><em>KSK Rollover Postponed</em>: <a href="https://www.icann.org/news/announcement-2017-09-27-en">https://www.icann.org/news/announcement-2017-09-27-en</a></li><li><em>Update on the Root KSK Rollover Project</em>: <a href="https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project">https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project</a></li></ul><p><br /></p><h2>Section V: Reports</h2><h2>Staff Contact</h2><p><span class="contact-name">Paul Hoffman</span><br /><a href="mailto:paul.hoffman@icann.org">paul.hoffman@icann.org</a></p>
FINALVERSION
<p><ac:structured-macro ac:name="view-file" ac:schema-version="1" ac:macro-id="dcb210bf-7d77-48cd-b539-9c23e7c92c5a"><ac:parameter ac:name="name"><ri:attachment ri:filename="AL-ALAC-ST-0418-02-01-EN.pdf" /></ac:parameter><ac:parameter ac:name="height">250</ac:parameter></ac:structured-macro></p>
FINALDRAFT
<p><br /></p><p>The ALAC and At-Large Community understand the need to roll the KSK but parts of the community have strong concerns for the potential impact on users world-wide.</p><p>We believe that a holistic review is needed including a risk assessment of the alternatives, in time for further discussion at ICANN62. The assessment should include then current information related to the RFC 8145 trust anchor reports, the prognosis for availability of the in-development IETF “sentinel” mechanism and the potential for using the sentinel mechanism to create a greater level of comfort prior to the KSK rollover.</p><p>In parallel, ICANN should ramp up its awareness campaign using all possible conduits to reach ISP, telcos, and governments as well as critical sectors who must be able to continue to function post-rollover and who may be in a position to communicate with key DNS providers in their regions. Banking is one such sector that must not be put offline and which may have valuable contacts in their local areas. RIRs may have good contact information for large ISPs and other large users in their regions.</p><p>ICANN should also make available an information packet, in at least the languages ICANN normally supports, and preferably more, which will allow users and businesses to understand the issue (i.e. in simple terms) and tell them what they need to do/ask with regard to their local ISPs.</p><p>ICANN should provide a simple test web address and/or application that will allow users to verify if the resolver they typically use is DNSSEC-aware. If it is not, then they are likely to be unaffected by the KSK rollover. If their resolver is DNSSEC-aware, then they should be told what to do to try to verify that their provider is aware of and prepared for the rollover (recognizing that the technical support most end-users can contact will not likely be aware of terms such as DNSSEC, KSK or Rollover). <a href="http://dnssec.donnerhacke.de">http://dnssec.donnerhacke.de</a> is an example on which such a tool may be modelled.</p><p>ICANN should provide a list (either viewable or searchable) of DNS resolvers known to be DNSSEC enabled for which we definitively know either do or do not have the new trust-anchor installed, and the awareness campaign should describe how end users can check this list. An automated app that users could run on various platforms would be even better.</p><p>Lastly, the At-Large Community has concerns that the rollover is scheduled to take place on a Thursday (and most likely Friday in some parts of the world). That seems like a plan designed to maximize and prolong any problems. We would like to understand the potential and possibility of a minimal delay to ensure that the day-of-the-week issue reduces impact instead of increases it.</p>
FIRSTDRAFT
<p>Another proposed Draft (Hadia)</p><p>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</p><p>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.</p><p>Taking into consideration that</p><ul><li>It is not for seen that new reliable data will be available soon. </li><li>There is nothing to indicate that operators of DNS resolvers that are operating with only the 2010 KSK will fix their systems soon. </li><li>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.</li><li>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</li><li>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.</li></ul><p><br /></p><p>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 </p><p>-----------------------------------------------------------------------------------------------------------------------------------------------------</p><p>The ALAC is pleased to have the opportunity to comment on the “Plan to Restart the Root KSK Rollover Process”.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>ICANN should provide a test page for the end users, which tell them in a very simple way, if they are affected by the KSK rollover or not (example <a href="http://dnssec.donnerhacke.de/)">http://dnssec.donnerhacke.de/)</a>. This page should offer a link to the gathered information from RFC 8145: The end user can enter the IP of the resolver (preferably automatically detected using a Nonce-FQDN) to check, if the active resolver is already trusting all active keys. This tool should be stay in place for further rollovers.</p><p>There are some recommendations:</p><ul><li>Do not publish changes near the end of the week (Friday to Sunday can not considered as work days), choose only Tuesday or Wednesday.</li><li>Because it's impossible to gather detailed information about every possible situation, prepare a worldwide anti-blame PR action. Try to get this event into the news, it has to be broadcasted in the same way as the Year2000 problem. Ensure, that every problem during the roll over will be attributed to the ISPs. Strictly speaking try to blame the ISPs, hosters, and IoT companies beforehand through the press, (social) media, and TV shows. This action has to reach the climax some weeks before the date.</li><li>Use the opportunities of the distributed ICANN sub-organisations (for AtLarge: ALSs) to distribute knowledge into the communities.</li><li>Allow the end users to self-test their own environment by providing a appropriate web-page.</li></ul><p>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.</p><p>-------------------------------------------------------------------------------------------------------------------------------------------------</p><p>Alternative Text: (courtesy of John Laprise)</p><p>Whereas:</p><ul><li>SSAC has issued two advisories on the KSK Rollover</li><li><a href="https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf">[SAC063] SSAC Advisory on DNSSEC Key Rollover in the Root Zone (07 November 2013)</a></li><li><a href="https://www.icann.org/en/system/files/files/sac-073-en.pdf">[SAC073] SSAC Comments on Root Zone Key Signing Key Rollover Plan (05 October 2015)</a></li><li>ICANN issued a <a href="https://www.icann.org/en/system/files/files/plan-continuing-root-ksk-rollover-01feb18-en.pdf">revised KSK Rollover draft plan</a> for public comment and plans to execute the rollover in October 2018</li><li>The KSK Rollover was a topic of intense discussion during the ICANN61 meeting in Puerto Rico</li><li>ALAC affirms that the KSK Rollover is necessary</li><li>ALAC is cognizant of the nature of the risks of action and delay but not their relative weights</li></ul><p>Resolved:</p><p>The ALAC advises the Board</p><ul><li>to provide a holistic risk assessment to the community on the KSK Rollover at ICANN62 comparing the relative risks of implementing the KSK rollover as provided in the revised plan vs. further delaying the KSK rollover. The risk assessment should include an evaluation of both the technical and reputational risks to the security and stability of the Internet and should reflect opinions of the SSAC, RSAC, and Risk Committee</li><li>To direct ICANN to develop a robust ISP mitigation strategy in the event of resolver failure affecting end users and communicate it to the community</li><li>To provide clarification on the communication plan. ALAC notes that the recipients for the KSK rollover communication plan considerably overlap those of the DNSSEC implementation</li></ul><p>Furthermore</p><ul><li>Upon receipt of the risk assessment at ICANN62, ALAC will be better prepared to offer advice on the KSK Rollover Plan in a timely fashion prior to its proposed execution in October 2018</li></ul>
CALLOPEN
2018-04-01 00:00:00.0 UTC
CALLCLOSE
2018-04-02 00:00:00.0 UTC
VOTEOPEN
2018-04-03 00:00:00.0 UTC
VOTECLOSE
2018-04-06 00:00:00.0 UTC
SUBMISSION
2018-04-02 00:00:00.0 UTC