[ksk-rollover] Future rollover planning opportunities

[Michael Richardson]

Tony Finch <dot at dotat.at> wrote:
    > Fred Baker <fred at isc.org> wrote:
    >>
    >> The key consideration is that key rollovers are a "usual" event, and as
    >> such the key(s) should be something learned from the root and the root
    >> servers, not something configured or compiled into the resolver
    >> software.

+1

    > I agree that rollovers need to be routine (I think annual makes sense) but
    > they have to be planned with software releases in mind. This might require
    > keys to be generated and promulgated out of band a long time before they
    > are published in the zone or used for signing. Then a vendor package can
    > include root keys covering the next couple of years, say.

I think that there is very little incremental cost to including a multitude
of keys in a software release.  i.e. rather than 1 or 3 for the next 3-4
years,  I'd like to around a dozen.  With a variety of algorithms, keysizes,
and with the private keys escrowed in a variety of ways.  Some will be
expired without ever been used... they are just in case, or in support of
as-yet-unknown contingencies.   (including fire-drills for such switches)
I'd like for this to include a hash-based signature system, but I'm not sure
we have the standards specifications for this nailed down sufficiently.

Yes, there is some non-trivial cost for the root-zone key holder to keep more
private keys safe.  It is my understanding that the ICANN software for this
is being revised to be significantly more flexible, and so I also see this as
a way to make sure it all really works.

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190220/27d146b2/signature.asc>