> On Oct 30, 2018, at 8:27 PM, Mark Andrews <ma...@isc.org> wrote: > >> On 31 Oct 2018, at 11:16 am, Jim Reid <j...@rfc1035.com> wrote: >> >> On 30 Oct 2018, at 22:31, Mark Andrews <ma...@isc.org> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
