<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 10, 2018 at 5:33 AM, Petr Špaček <span dir="ltr"><<a href="mailto:petr.spacek@nic.cz" target="_blank">petr.spacek@nic.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5.1.2018 23:12, David Conrad wrote:<br>
> On January 5, 2018 at 2:06:10 AM, S Moonesamy (<a href="mailto:sm%2Bicann@elandsys.com">sm+icann@elandsys.com</a><br>
</span><span class="">> <mailto:<a href="mailto:sm%2Bicann@elandsys.com">sm+icann@elandsys.com</a>><wbr>) wrote:<br>
>> The plan was put on hold because of the <br>
>> data from September 2017. At the moment it is <br>
>> unknown if/when there will be a KSK roll. Is not <br>
>> doing a KSK roll by 2020 [1] a viable option? <br>
><br>
> Speaking personally, I’m hoping we can do the rollover long before 2020.<br>
> The key is for the community to provide some sort of guidance to the<br>
> ICANN Org about how to move forward. So far, my impression is that to<br>
> date, most of the input from this mailing list has been “do it now”,<br>
> implying we do NOT need to assess "the impact on users” (as mentioned<br>
> in <a href="https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project" rel="noreferrer" target="_blank">https://www.icann.org/news/<wbr>blog/update-on-the-root-ksk-<wbr>rollover-project</a>).<br>
> This means that the plan that will be published on 31 January for public<br>
> comment will say the input we have received suggests the majority of<br>
> contributors do not believe we need to take potential negative impact of<br>
> the KSK rollover into account.<br>
<br>
</span>I think this is misunderstanding. I haven't seen anyone saying that "we<br>
[do not] need to take potential negative impact of the KSK rollover into<br>
account", rather than "people will fix it if it really breaks".<br>
<br>
Let me state my interpretation of the discussion (in the following text,<br>
"contributors" reads "me"):<br>
<br>
Contributors believe that there is no way to reliably measure readiness<br>
for the rollover, and that tools for such measurement will not be<br>
available in upcoming years.<br>
<br>
---<br>
While not having reliable data, contributors believe that KSK rollover<br>
process already got sufficient publicity and that breakage will be dealt<br>
with swiftly, similarly to other security issues or DDoS attacks. For<br>
these reasons risk of postponing KSK rollover indefinitely is deemed to<br>
be higher than risk of breakage which will be fixed using usual methods.<br>
---<br>
<br>
I hope it helps to explain how others might read this discussion.<br></blockquote><div><br></div><div><br></div><div>I think there will always be breakage, in the old pre-RFC5011 and KSK design discussions there was one case identified as non-solvable </div><div> --- old OS/Box comes alive i.e. </div><div>I think we now have a second class of failures that was not "anticipated"  </div><div>  -- non-persistence i.e. resolver can not store state in a way that will be used if resolver is restarted.</div><div>  -- operators hard code keys i.e. disable RFC5011 (trusted-keys vs managed-keys) </div><div><br></div><div>RFC5011 assumes that timings and state of keys can be stored and will survive reboot/restart, </div><div>this seems to be violated by some operators by design (i.e. configuration information is non-writeable by the Resolver process) </div><div>and in some cases a mixture of the old OS and use of modern technologies like containers. </div><div><br></div><div>Having said this I'm going to argue that we should proceed with roll by picking a day and </div><div>generating a PR outreach to try to minimize outages. </div><div><br></div><div>     Olafur</div><div><br></div></div></div></div>