<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 30, 2019 at 9:36 PM Michael Richardson <<a href="mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@sandelman.ca</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I understood that there was some root zone maintenance times that meant that<br>
changes had to happen on the 11th or something of Jan/May/July/Sept, or some<br>
such.    Otherwise, I like the concept of your schedule.  <br>
It's a bit US centric in terms of bank holidays, etc, but I'm sure that the<br>
exact exclusion list (as you suggest) can worked out.<br><br></blockquote><div><br></div><div>My mistake, I think any common day's off of work should be considered. I imagine</div><div>that there are some lists available to consider for this topic, but I am not aware</div><div>of any good ones at this point. Looking through a bunch of sites online, if all</div><div>holidays were considered, there would be no days available, but there will </div><div>probably have to be a line drawn somewhere, and I'm not the person to decide on</div><div>that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think that this is an important thing to consider, but I think that we need<br>
to think more about what kinds of emergencies it deals with, and which kind<br>
still cause a failure.<br></blockquote><div><br></div><div>Agreed. The scenarios that I had considered were:</div><div><br></div><div>1) Weakness discovered in the use algorithm used to sign the KSK might</div><div>leak bits of the key. (Switching to a new key might buy a month or two to rotate</div><div>the key at a faster rate until a long term mitigation is found)</div><div>2) A vulnerability is found in the software used to sign the zone that might put</div><div>the key at risk when signing the ZSK. In this case, a fix in the vulnerability should</div><div>be implemented before resigning the zone.</div><div>3) The algorithm used to sign the KSK may found to be reversible, or not or</div><div>significantly easier to crack than originally thought. (this is the primary case for</div><div>another key algorithm to be in the set of the backup keys).</div><div><br></div><div>i seem to recall that there was another one, but I can't recall it at this point.</div><div><br></div><div>--tim</div></div></div>