> 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
