[ksk-rollover] The risk of miscommunication

Warren Kumari warren at kumari.net
Mon Aug 1 22:02:18 UTC 2016

I wanted to quickly draw people's attention to a draft which Wes
Hardaker and I recently wrote:
Security Considerations for RFC5011 Publishers

This discusses the minimum time which a TA publisher must wait before
they can assume that (online) resolvers have the new key.
Many people (e.g in the above) assume that it is 30 days, but it
actually significantly longer - 30 days + 3/2 sig + 2*TTL

Assuming everyone has the new key before this time is dangerous...


On Mon, Jul 25, 2016 at 6:50 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> The Yeti test bed is currently trying a second KSK rollover
> <https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experiment-KROLL.md>
> and there was a funny incident. A resolver admin, misinterpreting the
> instructions, updated manually his config with the new key, despite
> the fact it was still in AddPend state and not used for signing. Since
> people have a tendency to make mistakes, I suggest to pay extreme
> attention to the communication and documentation, when explaining
> sysadmins what to do.
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.

More information about the ksk-rollover mailing list