[ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll

[Hugo Salgado-Hernández]

On 17:06 02/01, Paul Hoffman wrote:
> Greetings in the new year. As announced on this list (and in many other places) a few weeks ago, the ICANN org wants to use this list to get input from the community on acceptable criteria for proceeding with the root KSK roll. When we made that announcement, we saw a good number of new subscriptions to the list, but the discussion didn't start on its own, so we want to get that going.
> 
> For reference, please see <https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project>. The relevant timing part from that article is:
> 
> > The ICANN org will monitor this mailing list and beginning on 15 January 2018, we will develop a draft plan for proceeding with the root KSK roll based on the input received and discussion on the mailing list. The plan will be published by 31 January 2018 and undergo a formal ICANN public comment process to gather further input.
> 
> We would really like to hear from you about the criteria you think would be relevant for us to observe/measure, if such criteria exist.
> 

I agreed with the suspension of rollover last september, 
but not so much for telemetry data, if not for this bug in Unbound:
http://unbound.net/pipermail/unbound-users/2017-August/004883.html

(For those who do not know, any new installation of Unbound
before version 1.6.5 (published August 21 2017, 40 days after the
add-hold is initiated for the new key) came with the new key in ADDPEND
status, with 30 days to go to VALID. I personally installed an Unbound 
resolver on CentOS 6.9 in September 20th, which had the bug. That
service would became bogus on October 11th).

After the patch was released, how long it takes to pass downstream
to common OS distros?

IMHO, any software that has such critical errors through the process
of rollover deserves reconsideration of deadlines, and wait a "as long
as possible".

At some point we have to say that we had a cautious time to allow
patches on distros, or operators manually upgrade the keys ... but
clearly on October 11 was too early.

At this point, 4 months later, can we assume that a competent
operator, with current OS with updated patches, is "safe from the
rollover"?

I wonder if ICANN in their research and direct contact with operators
have found evidence of any bug, outdated distros, incorrect manuals,
bad practices, etc., that demonstrate a "structural" problem with
rollover procedures.

Regards,

Hugo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180108/7b2194d7/signature.asc>