[ksk-rollover] The risk of miscommunication

Warren Kumari warren at kumari.net
Mon Aug 1 22:59:51 UTC 2016


Yup.

" One important (temporary?) note about ICANN's upcoming KSK rolling
   plan for the root zone: the timing values, at the time of this
   writing, chosen for rolling the KSK in the root zone appear
   completely safe, and are not in any way affected by the timing
   concerns introduced by this draft"

We didn't want this document to cause any drama about the root KSK
roll, simply provide some operational advice to people doing testing,
others (if there are any :-)) with 5011 anchors, etc..

W


On Mon, Aug 1, 2016 at 3:49 PM, Geoff Huston <gih at apnic.net> wrote:
> Well its reassuring to observe that the 90 day key publication
> period in the proposed KSK rollover plan meets this criteria
> of being resistant to replay attacks.
>
> Geoff
>
>
>> On 2 Aug 2016, at 8:02 AM, 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> 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.
>>   ---maf
>> _______________________________________________
>> 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.
   ---maf


More information about the ksk-rollover mailing list