<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Apr 2019 at 07:59, Joe Abley <<a href="mailto:jabley@hopcount.ca">jabley@hopcount.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
1. We should move briskly towards a steady state where it is obvious and unremarkable to all stakeholders and relying parties that the KSK changes from time to time. Nobody should bake a particular KSK into software; the responsibilities for tracking trust anchors within any particular software ecosystem should be clear; client-side machinery should be exercised regularly.<br></blockquote><div><br></div><div>On the subject of "nobody should bake a particular key into software...",  John Dickinson and I were entertaining the notion last week of writing up advice to the effect that implementers should deprecate the notion of non-5011 trust anchors; all configured trust anchors should be treated as potentially doing 5011 rolls, always.  The reasoning being that if the authoritative operator isn't doing 5011 there's no harm (it's a no-op), and if they are then you don't want anyone accidentally hard-coding the trust anchor statically.</div><div><br></div><div>I'm persuaded by the use case Paul Ebersman brought up, that some networks may prefer to control when and how trust anchor updates happen on their network, and so maybe this advice should be a statement about defaults, rather than advice to never have static keys.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">3. A regular schedule of data collection will become possible, instead of ad-hoc coordination for individual rollover events, reducing cost and promoting consistency in what is collected and how it is stored and made available for analysis.<br></blockquote><div><br></div><div>DNS-OARC would be happy to continue coordinating data collection events around the major steps in KSK rolls. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
4. An emergency key-roll due to key compromise (of any number of flavours) will be expected, easy to execute and easy to understand from the client side. Contributing oil on the wheels might be long-timebase pre-publication of standby keys and the processes for an emergency roll closely resembling (or being identical to) processes for a scheduled roll.<br></blockquote><div><br></div><div>Pre-publishing keys for the purposes of emergency roll in the event of compromise sounds hard, and definitely expensive, given how they key material is handled today.  I think a third signing party location would be required, with each key stored in only two locations.  This is probably achievable, but I suspect it'll take a while for people to agree on costs and location, and then more time to get it set up.</div><div><br></div><div>We will likely want to come up with an interim plan for emergency rolls until something like the above can be arranged.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
5. It should be unnecessary for ICANN to ever have to do an outreach programme around a scheduled KSK rollover.<br></blockquote><div><br></div><div>Hear hear!</div><div> </div></div></div>