Subject: Re: [DNSOP] KSK rollover choices

From: Russ Housley <[email-masked]>
Date: Thu, 1 Nov 2018 10:37:46 -0400

> On Oct 30, 2018, at 8:27 PM, Mark Andrews <[email-masked]> wrote:
> 
>> On 31 Oct 2018, at 11:16 am, Jim Reid <[email-masked]> wrote:
>> 
>> On 30 Oct 2018, at 22:31, Mark Andrews <[email-masked]> wrote:
>>> 
>>> Ultra frequent key rolls are not necessary.  It takes years the latest releases of name servers to make it into shipping OS’s.
>> 
>> So what? Key rollover policies cannot and should not be driven by vendor OS release schedules. Or the BIND/whatever version they choose to distribute. If key rollovers became dependent on these considerations, we’d never be able to roll the root’s KSK.
>> 
>> Software that had hard-wired the old key caused trouble for the recent rollover so we simply have to be in a much better place next time. I hope you don't want to perpetuate that legacy behaviour, albeit in a slightly different form.
>> 
>> If the (hypothetical) problem is DNS software gets shipped with the current KSK on the release date and that might lurk in vendor distributions long after the KSK has rolled, the solution is obvious. Don’t do that.
> 
> Bootstrap is still a issue.  Over fast TA rolling makes it more of a issue.
> 
> I think we would replace RFC 5011 with something else before we roll the root key next while using RFC 5011 timings for the roll for legacy implementations.  We really need a way to signal how long a TA is expected to be valid for.  This allows machines to safely fail to insecure if they have been off for too long.

It is a good time to do rfc5011-bis.  Real world experience from the KSK roll makes a lot os sense to me.

And, an operational considerations section can address the bootstrap issue.

Russ

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Nov 2018 12:14:50 -0700

> KSK roll makes a lot os sense to me.

I think step one would be to list the aspects of it that worked well,
and the aspects that didn't.  From that we can determine the need for a
replacement and what features would be needed in order to accommodate the
aspects that didn't work well.  I do believe it worked quite well over
all, but there are elements that were lacking and may be worth doing a
bis to address.  [but we really need a upsides-and-downsides list based
on experience first in order to evaluate the need to do a bis].
-- 
Wes Hardaker
USC/ISI

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Nov 2018 15:32:29 -0400

> on experience first in order to evaluate the need to do a bis].

I'm not sure that "5011bis" is a helpful way to phrase this.

5011 solves the area it is concerned with (conventionally long-lived devices that don't ship on the shelf for long periods) very nicely, as far as I can see. There have been some variable implementations that might suggest the need for improved clarity in the specification or better test suites or something, but I don't think our recent experience has provided clear signs that 5011 as a protocol is deficient or unsuitable.

I think the wider problem space might be better described as trust anchor publication and retrieval. Within that perimeter we can find scope for improvement in areas like emergency key rollover, pre-publication of trust anchors for standby keys, retrieval of trust anchor (bootstrapping) by ephemeral or unattended devices, etc, etc. The area that 5011 addresses is kind of the best part.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 02 Nov 2018 23:34:07 -0700

Joe Abley <[email-masked]> writes:

> I think the wider problem space might be better described as trust
> anchor publication and retrieval.

Couldn't have said it better myself (more specifically, I didn't).  The
problem space is much bigger than 5011, and 5011 is but one tool to
solve a piece of the whole space.
-- 
Wes Hardaker
USC/ISI