(Posted from my personal email because that's how I'm subscribed here.) Dear colleagues,
I just posted an update on the root KSK roll project at https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project. The text is reproduced below for your convenience and please let me offer the customary apology if you receive duplicate postings of this message on multiple mailing lists. Matt -- Matt Larson <matt.lar...@icann.org> VP of Research, Office of the CTO, ICANN The ICANN org is today announcing that it will not roll the root zone KSK in the first quarter of 2018. We have decided that we do not yet have enough information to set a specific date for the rollover. We want to make clear, however, that the ICANN org is committed to rolling the root zone KSK and we will continue to discuss this important process with the community, gather their feedback and give all interested parties advance notice of at least one calendar quarter when we set the date for the rollover. Furthermore, we are soliciting input from the community to help determine, if possible, appropriate objective criteria to measure the possible negative impact of the root KSK rollover on Internet users, and acceptable values for those criteria before a rollover. This is in accordance with the bottom-up, multi-stakeholder model that has been so successful for ICANN policy development. On 27 September 2017, the ICANN org announced it was postponing the root zone KSK rollover for at least one quarter, leaving open the possibility the root KSK rollover might occur in the first quarter of 2018. We have since realized that our analysis and preparation will require additional time. In a previous post, we described our analysis of recursive resolver trust anchor configuration information reported using the protocol defined in RFC 8145, Signaling Trust Anchor Knowledge in DNS SecurityExtensions (DNSSEC). Our analysis revealed that about 4% of the approximately 12,000 DNSSEC-validating resolvers reporting during the month of September 2017 were configured with only KSK-2010 (the shorthand for the current root KSK) and would have been unable to resolve DNS queries after the rollover occurred. The ICANN org's decision to postpone the rollover was based on the concern that we did not understand why those resolvers were not properly configured, and we needed time to investigate. Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped. In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010. To proceed with the root KSK rollover, the ICANN org must have confidence that the rollover will not have an unacceptable negative impact on Internet users. The challenge we have encountered since we began to analyze the RFC 8145 trust anchor configuration reports from resolvers is assessing the impact on users. We can make a number of assumptions: for example, it is unlikely that a recursive resolver running at a dynamic address could support a large number of users since it does not offer a stable address for any devices to send queries to for resolution. But ultimately, determining potential user impact based on the data available to us is difficult and we are therefore soliciting the community's input. Input and discussion on acceptable criteria for proceeding with the KSK roll will take place on an existing email list that is already being used for discussion of the root KSK rollover. We encourage anyone interested in contributing to join the mailing list by visiting https://mm.icann.org/mailman/listinfo/ksk-rollover. The ICANN org will monitor this mailing list and beginning on 15 January 2018, we will develop a draft plan for proceeding with the root KSK roll based on the input received and discussion on the mailing list. The plan will be published by 31 January 2018 and undergo a formal ICANN public comment process to gather further input. We will hold a session at ICANN61 in San Juan, Puerto Rico, to discuss the plan and hear from the community in person. Our intent is to have a revised plan available for community review and public comment prior to ICANN62 in Panama City, Panama, with a final plan published soon thereafter. Throughout the process we'll continue to keep the community updated on the root KSK rollover project's progress.
