March 2018 - comments-ksk-rollover-restart-01feb18@icann.org

[Comments-ksk-rollover-restart-01feb18] Comments on ksk rollover
by Bill Snow March 30, 2018

March 30, 2018

We have reviewed the plan for continuing the root ksk rollover published by ICANN. We think the proposed schedule is fine and the reasoning behind it is sensible. We think that the data you have collected relating to RFC 8145 provides no clear evidence of widespread negative outcomes for end-users when signatures by KSK-2010 are removed. We suggest that you go right ahead. We are aware of another idea that might be of use: it's not our idea, but we've heard it from various places and think it's worth mentioning. If a future KSK rollover was structured as an algorithm roll to a desirable new algorithm that would benefit from wider implementation, validators that didn't support the new algorithm would fail open (go insecure) rather than failing closed (go dark), regardless of whether they had managed to update their local trust anchor with the new KSK (see RFC 4035 section 4.2 and RFC 6840 section 5.2). This approach might have the dual attractive qualities that the worst-case end-user impact would be a lack of validation rather than a failure to validate and also that it would encourage deployment of algorithms like ECDSA (RFC 6605) that have smaller keys and signatures. Something to think about for the future, perhaps. Bill Snow Snake Hill Labs

1 0

[Comments-ksk-rollover-restart-01feb18] Verisign comments on ICANN’s “Plan to Restart the Root Key Signing Key (KSK) Rollover Process”
by Kaliski, Burt March 30, 2018

March 30, 2018

Verisign is pleased to provide the attached comments on ICANN’s “Plan to Restart the Root Key Signing Key (KSK) Rollover Process,” per the request for public comment at https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en. * Burt

1 0

[Comments-ksk-rollover-restart-01feb18] Roll the KSK as planned
by Tony Finch March 27, 2018

March 27, 2018

Please go ahead and roll the root KSK as planned on the 11th October 2018. The ongoing work on trust anchor telemetry and KSK sentinel might be useful for making an informed decision, but there is the risk of getting into the trap that there is never enough data. It would be bad to delay again and again for just one more experiment. KSK sentinel might provide better data than trust anchor telemetry, but I fear it is too late for this rollover, and it may never be deployed by the problem sites that cause concern. So maybe the quest for data is not absolutely crucial. I increasingly think RFC 5011 is insufficient and not actually very helpful. It was implemented rather late and it seems many deployments don’t use it at all. It only solves the easy problem of online rollovers: it doesn’t help with bootstrapping or recovery. RFC 7958 moves the problem around rather than solving it. It suggests that we can treat personal PGP keys or self-signed X.509 keys with unclear provenance as more trusted than the root key, with all its elaborate documentation, protections, and ceremonial. It adds more points of failure, whereas a proper solution should disperse trust. I think the best short term option is to put more emphasis on using software updates for distributing the root trust anchors. The software is already trusted, so using it for key distribution doesn't introduce a new point of failure. Most vendors have a plausible security update process. Software updates can solve the same problems as RFC 5011, in a straight-forward and familiar way. Across the ecosystem as a whole it disperses trust amongst the vendors. Longer term I would like a mechanism that addresses bootstrap and recovery (because you can’t get your software update without DNS) but that is not doable before the rollover later this year. Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire, Northeast Forties: Southeasterly 6 to gale 8. Rough or very rough. Occasional sleet. Moderate, occasionally very poor.

1 0

[Comments-ksk-rollover-restart-01feb18] Plan for Continuing the Root KSK Rollover
by Joe Abley March 16, 2018

March 16, 2018

Afilias has reviewed the document “Plan for Continuing the Root KSK Rollover” published by the ICANN Office of the CTO on 1 February 2018, as well as the public outreach that continues to be carried out by ICANN on this subject. Afilias has considerable experience managing KSK rollovers in top-level domain and other zones, e.g. as part of the regular transition of TLDs to Afilias registry management, ensuring that our technical staff have operational confidence in the processes involved. As a leading supporter of DNSSEC deployment, we understand the operational importance of proper key management and the root zone is not an exception. We believe that the depth of consideration that has been given by ICANN to the potential outcomes of the root zone KSK rollover is appropriate and sufficient. However, after extensive analysis it seems clear today that the data sets that caused ICANN to exercise caution are noisy and ambiguous, and do not contain clear evidence that significant negative end-user impact is likely. We also believe that there is a significant and larger risk in not rolling the KSK. There is important work that remains to be done relating to both scheduled and emergency Root KSK Rollover that cannot reasonably proceed until this work is done. ICANN’s cryptographic asset management is of a very high standard; however, the lack of a demonstrated ability to execute both scheduled and emergency KSK Rollover with confidence presents a significant gap. In our considered opinion, a balanced risk assessment supports the prompt execution of the Plan for Continuing the Root KSK Rollover without further delay. Afilias further recommends that ICANN facilitates planning and community consultation on measurement of and improvements to the many technical mechanisms involved in KSK Rollover, and establishes a regular cadence for future scheduled Root KSK Rollovers. Regards, Joe Abley Infrastructure Scientist Afilias

1 0

[Comments-ksk-rollover-restart-01feb18] KSK Rollover - Jacques Latour Comments
by Jacques Latour March 14, 2018

March 14, 2018

Hi, Please roll over the KSK as per plan. Please roll over the KSK on an annual basis (or every 2 years) Please develop better processes to automate the KSK rollover (not 5011) Please don't delay further! Collateral damage of rolling the key: There will be some but it will be short lived. We need to take in account the human behaviour, and not being an expert human behavioral analyst, I know that people fix things when broken and not when it's working. So getting a 100% of people's attention to fix something not broken is almost impossible. It's impossible to have 100% readiness. The majority of DNSSEC validation today is via google DNS. I think we need to go ahead with the roll over, have the humans fix the problems as they arise, and start re-building the trust in DNSSEC globally! (before it's too late!) In my opinion, the uncertainty (with delaying the rollover) could start eroding the 'people' trust in DNSSEC as a technology. The sooner we get over this hurdle the better we are. I'm on the camp that DNSSEC is a viable technology, and we made an error in not rolling the key sooner and we need to acknowledge in advance there will be some collateral damage 'for people not running up to date stuff' but it's inevitable to bring this technology to maturity. If we don't take this risk, might as well turn it off because people won't trust it. Going from pulse to dial tone telephone, going from analog to digital TV, all had its share of collateral damage. Perfection is not an option, I think we're ready, let's do it! And we should work with all the major search engine to make the DNSSEC/DNS failure related searches are more relevant during the rollover, on terms like SERVFAIL, DNSSEC, DNS resolution failure, etc.... and links to resolve. They won't be searching for KSK rollover and it should be mobile friendly. The google top box (don't know what's it called) should say on DNS/DNSSEC search on the day we roll the key "We just rolled the KEY, if you're experiencing DNS issues, please ..." Jacques Jacques Latour - CTO Canadian Internet Registration Authority (CIRA) Tel: (613) 237-5335 ext.294 | www.cira.ca<http://www.cira.ca/> [Cira K+186 H Tag]

1 0

[Comments-ksk-rollover-restart-01feb18] Comments in response to Plan to Restart the Root Key Signing Key (KSK) Rollover Process
by Geoff Huston March 14, 2018

March 14, 2018

I would like to voice my support of the ICANN plan to restart the KSK rollover process. I was a member of the KSK Rollover Design team, and I am of the view that the plan as described in the Design Team was carefully appraised by ICANN staff, and the proposed plan to roll the key reflected the major objectives of the Design Team report and made some changes that further enhanced the resiliency and robustness of hte overall process. The decision to suspend the Planned KSK roll in 2017 was a responsible action in the light of unanticipated data from the reporting mechanisms from resolvers that apparently have implemented RFC8145. However, it is clear following further examination of the implicit signal from the RFC8145 mechanism that most of this signal contains mis-attribution of resolvers as being DNSSEC-validating resolvers and mis-attribution of resolvers through the various actions of query handling between the reporting resolver and the data collection points at the root. In other words, it is becoming apparent that the signal within the RFC8145 mechanisms is a largely flawed signal. There is still time between now and October 2018 to further study the RFC8145 data to confirm that much of this signal is flawed. There is still ample time to experiment with the proposed sentinel mechanism, but further delay at this point in time would, in my view, serve more to erode confidence in DNSSEC than it would build any further confidence in this proposed KSK roll process. Every crypto system needs an ability to change its key at some point. A regularly scheduled roll the key provides operational experience in this potentially rather esoteric activity, and one of the benefits, as I perceive it, is that we can gain experience with this event and use that experience to further enhance the process. It is an abstract exercise to wait for a ‘perfect’ key roll process, and I am of the view that experience will refine and enhance our thinking that an abstract exercise never can. Yes, there is a need for a clearer signal about the preparedness of the Internet’s DNSSEC-validaitng resolvers for the KSK roll, and yes, we might consider a mechanism that is different from that detailed in RFC5011, and yes, we might want to look at systems that include standby keys, but my position is that the best way to design refinements to this process is to use experience from each iteration to make incremental improvements. So, I am strongly supportive of the ICANN plan to restart the KSK rollover process. kind regards, Geoff Huston Chief Scientist, APNIC

1 0

[Comments-ksk-rollover-restart-01feb18] Comment on the KSK rollover plan
by Barry Leiba March 13, 2018

March 13, 2018

I observe that: 1. The current data leads me to understand that fairly few actual users will be affected because their service providers are not properly prepared for the rollover. 2. Even for those users who are affected, the affect will not be to deny them access to the Internet, but, rather, to cause a fallback to insecure DNS. 3. That fallback is, while not ideal, not devastating, and… 4. …the issues will almost certainly be resolved quickly. 5. Delaying the rollover by 3 months, or 6, or 9, is not likely to make a significant difference in preparedness; we’ve been planning this for long enough to lead to the conclusion that anyone unprepared will continue to be unprepared until they are forced to correct that. 6. Doing this first-time KSK rollover is critical to show that we can do it and to gather experience to make it possible to do regular 5-year rollovers as originally planned. 7. Not doing the rollover prevents us from gathering that experience and prevents us from being prepared should a rollover actually be necessary in the future because of a compromised key. I conclude that the risk of not doing the rollover forthwith far exceeds the risk of doing it. I urge ICANN to continue with the plan to roll the root zone KSK on 11 October. -- Barry Leiba (barryleiba(a)computer.org) http://internetmessagingtechnology.org/

1 0

[Comments-ksk-rollover-restart-01feb18] Continuing Root KSK Rollover - 2/1/18 plan
by Frederico A C Neves March 10, 2018

March 10, 2018

I believe that the current Plan is sound. Please proceed with the Rollover on Oct 11th 2018. I just would like to see a more detailed outreach plan. Specially one that provides documentation/presentation material that could be used by local operators community. All operators community engaged at ICANN should be leveraged in this effort, ccNSO members in particular, because of their geographic dispersion and closer ties to their local communities. I'm looking forward to the Roll, the lessons we'll learn with this and the plan for the next one. This should be a regular operation and not something treated as a one in the lifetime of this technology. Frederico Neves

1 0