The risk of miscommunication
The Yeti test bed is currently trying a second KSK rollover <https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experim...> 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.
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@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/Experim...> 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@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
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@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@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/Experim...> 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@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
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@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@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@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/Experim...> 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@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@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
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@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@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/Experim...
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@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@icann.org <javascript:;> https://mm.icann.org/mailman/listinfo/ksk-rollover
"StJohns, Michael" <msj@nthpermutation.com> writes:
5011 is written to describe resolver behavior in the face of publisher activity.
FYI, our document pretty much says that as well. No fault of 5011 is implied anywhere. But, in a number of people (~6) we asked what they thought the minimum value was, no a single person picked a safe value. Hence the need for publishing this document as a piece of the missing companion document. -- Wes Hardaker Parsons
participants (5)
-
Geoff Huston -
Stephane Bortzmeyer -
StJohns, Michael -
Warren Kumari -
Wes Hardaker