[ksk-rollover] alternatives to 5110 for automating roll-over

Michael Richardson mcr+ietf at sandelman.ca
Sat Mar 30 16:22:36 UTC 2019


Michael StJohns <msj at nthpermutation.com> wrote:
    >> list-ksk-rollover at dragon.net:
    >>> Phased rollout and control of when things change.

    >> Aye.

    >> I agree that we shouldn't prescribe how people automate, or even that
    >> they do it at all. 5011 is _one_ way to do it, and I happen to like
    >> it, but that doesn't mean that it is good for $everybody.

    mcr>     In particular, it fails when the device is not on/connected during
    mcr> the period that the 5011 adds the new key, then it can not use 5011.

    > No - that's not correct.  It fails if it wasn't able to see the old key
    > signing the new key for the add hold down period.   If you're following
    > my recommendations in 5011, then the new key C is going to be signed by
    > A for a while, then B for a while, before it becomes the active key. 

Right. But, if the resolver has A as the trust anchor, and it's offline for
the entire B-hold-down-period, then it never moves to B, and therefore does
not trust B's signature on C.

    mcr>     As far as I understand 5011, the only reason we can't leave the
    mcr> entire chain of keys in at the trust point is because the RRset would
    mcr> get unreasonably large, causing other failures.

    msj> No.

*If* we can leave all the signatures in place, then we can use 5011 to roll forward?

    > Someone banned the use of the term "blockchain" in the discussion, but
    > something like that is probably the right approach.  

If by blockchain, you mean a merkle tree, then I agree...
Perhaps the right answer is to sign the RSA/ECDSA/EDDSA keys with a
hash-based signature scheme, which, while large, could be kept in a place
that has enough space for such a thing.

Would it have to reside, in a place reachable by numeric IP address only?
I'm not sure.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	
-------------- 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/20190330/d762b5ad/signature.asc>


More information about the ksk-rollover mailing list