<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 12:40, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.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">On Tue, 2 Apr 2019, Matthew Pounsett wrote:<br>
<br>
> On the subject of "nobody should bake a particular key into software...",  John Dickinson and I were entertaining the notion<br>
> last week of writing up advice to the effect that implementers should deprecate the notion of non-5011 trust anchors;<br>
<br>
Today this is simply impossible. All machines installed fresh within the<br>
last 29 days of a KSK roll would die.<br></blockquote><div><br></div><div>I believe that is just another case of a no-op.  That would be solved in the same way that static keys deployed in that time are solved today, which is to say it's implementation (or distribution) specific.  </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>
> I'm persuaded by the use case Paul Ebersman brought up, that some networks may prefer to control when and how trust anchor<br>
> updates happen on their network, and so maybe this advice should be a statement about defaults, rather than advice to never have<br>
> static keys.  <br>
<br>
We've had this discussion a number of times over the years. You won't<br>
get a different outcome now. 5011 is fundamentally broken and needs<br>
another mechanism to support it or a mechanism to replace it.<br></blockquote><div><br></div><div>Broken, or just doesn't cover all use-cases?  I don't think you'd find any disagreement that it doesn't cover all use cases.  But, that's one of those discussions we still need to have about having multiple ways to distribute keys.  I don't think this is an argument against treating all trust anchors as potential 5011 targets.</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>
Also, vendors already have static keys or OS updates. We update the system<br>
store for CA certificates and DNSSEC root keys with that. We don't see<br>
this as a big problem (granted, we don't look beyond EOL which you might<br>
want to)<br></blockquote><div><br></div><div>Again, I don't think this is an argument against treating all trust anchors as being potentially 5011-managed.  Just because a trust anchor in DNS software is configured to be updated by 5011, nothing stops you from manually replacing it.  In fact, your comment about EOL is, I think, another argument in favour of this.</div><div><br></div></div></div>