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