[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