[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Michael Richardson]

Yoshiro YONEYA <yoshiro.yoneya at jprs.co.jp> wrote:
    > During DNSSEC Workshop at ICANN64, there were discussion regarding
    > future KSK rollover.

    > https://64.schedule.icann.org/meetings/961939

    > This is followup what I said.

    > I support regular Root Zone KSK Rollover for operational maturity and
    > DNS software matulity.

    > The importance is doing regulary.  Frequency may be once per 2-3 years,
    > less than 5 years.

I also want regular rollover, and I'd like it to be frequent enough that it
gets tested.  I also want it infrequent enough to never be without an anchor.

So, I feel uncomfortable with this frequency.  I don't have much in the way
of facts, just gut instinct.  **It feels too long and yet too short**
I think it should be either every ten years, or every year.

I'd like to be able to take a Long-Term-Support (LTS) release DVD (kept in
physical media, and therefore known not to have been tampered with) of some
OS and install it during it's entirely securely, and have it apply it's
updates using DNSSEC.  I think it's reasonable that a live boot/install
device do RFC5110 to update itself before reaching out to update software,
but I don't think that we leave the chain of keys in place long enough for a
3-5 year LTS to be able to catch up.

That leaves the system turning off DNSSEC in order to get new software
with new trust anchors.  Yes, the new software might be signed with known
trust anchors, so that chain could be intact.  But, RFC5110 ought to let us
run the original software.  Maybe this desire is controversial.

(Why would a paranoid person one use such an old release?  There are a number
of reasons I can think about, some of them involving investigation of
potential other compromised software tool chains.  Is this enough
justification?  Maybe.)

I think that we need a broad software industry survey of software release
scheduling and patching to inform us about how to include keys.
Maybe someone has already done this?  This is as much social science as
anything else.

I wonder if the chain of root KSKs could get moved to another point so that
we'd have a record of forward signatures?

--
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/20190314/953823a2/signature.asc>