[ksk-rollover] thoughts to the list as requested

[Matthew Pounsett]

On Tue, 2 Apr 2019 at 12:40, Paul Wouters <paul at nohats.ca> wrote:

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190402/3a1937e4/attachment.html>