[ksk-rollover] Proposal for Future Root Zone KSK Rollovers

[Michael Richardson]

Kim Davies <kim.davies at iana.org> wrote:
    > The three-year rollover strikes a responsible balance ensuring that
    > procedures and software remain sufficiently agile to adopt new keys as
    > they are commissioned, while not introducing too much operational
    > complexity through overly-frequent changes to the KSK.  The standby
    > period will allow a longer pre-publication and consequently allow for
    > the new KSK’s earlier use if there is a need to perform an emergency
    > rollover.

    > The public comment period is slated to close at the end of January. We
    > encourage you to submit your feedback so we may integrate it into the
    > final approach.

    > For those at the ICANN 66 meeting in Montreal this week, we will be
    > presenting the proposal to the DNSSEC session being held later today.

I read the document quickly.
I used the submit button, which then generated a mailto: URL, bring up in
gmail, which I didn't really want to use.  Couldn't you just tell me the email
address to use?  And gmail won't let me copy and paste the email address
easily... sigh: I guess it is: comments-proposal-future-rz-ksk-rollovers-01nov19 at icann.org

I have two comments:

1) In the D and E periods, you have a dashed line, which I think described as
   the RFC5011 hold-down period.  I suggest that you give these two periods a
   name/number/designation.  Maybe D_0 and E_0 or something like that.
   Maybe a completely new letter.

2) you write:
   doc> We also propose that each new KSK be generated well before it signs
   doc> the zone. This will allow a longer period of pre-publication, and
   doc> consequently allow for the new KSK’s earlier use if there is a need
   doc> to perform an emergency rollover. As a result, the overall lifespan
   doc> of future KSKs is anticipated to be about six years — two years of
   doc> which will be in a standby state (published, but not yet actively
   doc> used), three years in an
   doc> active state, and the final year being revoked and then deleted from
   doc> the key management facilities.

Some have expressed concern that the longer the public key is visible the
longer a (brute force?) adversary will have to attack the key.

I do not entirely concur with this view: if such an attack exists, it exists
regardless of when the key is published, and we need to roll the key more
often.  I'd like to see some discussion of this issue.

Still, if there were credible serious concerns here, it seems that there
could be a state B-prime, between B and C, or perhaps even from end of A to
beginning of C in which a hash of the public key is published, but not the
public key itself.  Again, I'm **skeptical** about this attack.

In particular, software distributions that might sit on the shelf (be burned
into CDroms) could embed the hash of the key (K+1) at year Q3 or year Y+3, a
full two and half years before the key is in use. (Maybe that would argue for
a shorter phase D, and longer state B-prime)

I would like to see some feedback (endorsement?) from the RedHat RHEL and
Canonical Server LTS managers (and Windows server) about the details of this
cycle.  I think that the three year KSK cycle with the 2+bit year intro may
fit VERY WELL into their release process.  The resuling being that, except in
emergencies, any LTS image installed within it's support lifespan of
typically 5 years, will be able to authenticate the root zone without any
additional parts.

--
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/20191106/ba1f7b0f/signature.asc>