On Tue, 2 Apr 2019, Matthew Pounsett wrote:
> 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;
Today this is simply impossible. All machines installed fresh within the
last 29 days of a KSK roll would die.
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.
> 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.
We've had this discussion a number of times over the years. You won't
get a different outcome now. 5011 is fundamentally broken and needs
another mechanism to support it or a mechanism to replace it.
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.
Also, vendors already have static keys or OS updates. We update the system
store for CA certificates and DNSSEC root keys with that. We don't see
this as a big problem (granted, we don't look beyond EOL which you might
want to)
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.