[ksk-rollover] The risk of miscommunication

[StJohns, Michael]

Wes and I talked a bit about this at Berlin.  The hold down time is the
absolute minimum amount of time the publisher has to wait before he can
believe the first resolver has installed  the new trust anchor into the
trust anchor set, NOT the maximum time it takes for all possible resolvers
to accept the key.  This much should have been obvious based on DNSs built
in incoherence with respect to global state.

5011 is written to describe resolver behavior in the face of publisher
activity.  The actual uptake rate for resolvers may actually be slower than
the holddown time for lots of reasons, and a publisher needs to consider
all factors before deciding what the deployment completion point is.   My
own recommendation is to use 2x the holddown time as a minimum for the
publisher to declare success.  That probably gives you a 99.9% confidence
interval that live 5011-capable resolvers have installed the new anchor.

At the time 5011 was published, there was some discussion on publishing an
operational guidance document, but that fell by the wayside.

Mike




On Monday, August 1, 2016, Warren Kumari <warren at kumari.net> wrote:

> I wanted to quickly draw people's attention to a draft which Wes
> Hardaker and I recently wrote:
> Security Considerations for RFC5011 Publishers
> draft-hardaker-rfc5011-security-considerations-00
>
> 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...
>
> W
>
>
> On Mon, Jul 25, 2016 at 6:50 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr
> <javascript:;>> 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 <javascript:;>
> > 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.
>    ---maf
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org <javascript:;>
> https://mm.icann.org/mailman/listinfo/ksk-rollover
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20160801/acdd46c7/attachment.html>