ICANN board meeting result and the Current status of KSK-Rollover
I would like to check for the latest status on ICANN root KSK rollover. Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018? Does the root KSK rollover is now confirmed to be 11 Oct 2018? Thank you. Best regards, Ben
On Mon, Sep 17, 2018 at 04:26:39AM +0000, Ben Lee <ben.lee@hkirc.hk> wrote a message of 176 lines which said:
Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018?
You know more than I do. There is nothing on <https://www.icann.org/resources/pages/ksk-rollover> while we have less than four weeks. The communication part of the rollover is not handled seriously.
Stephane, Just for clarity, the Board approved moving forward with the revised KSK rollover plan less than 24 hours ago, on a Sunday. Normal process at ICANN is to not announce things until the resolutions are posted. For internal process reasons, it takes a bit of time to post the resolutions. Sorry we’re apparently not able to meet your standards for seriousness. Regards, -drc
On Sep 17, 2018, at 8:51 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Sep 17, 2018 at 04:26:39AM +0000, Ben Lee <ben.lee@hkirc.hk <mailto:ben.lee@hkirc.hk>> wrote a message of 176 lines which said:
Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018?
You know more than I do. There is nothing on <https://www.icann.org/resources/pages/ksk-rollover <https://www.icann.org/resources/pages/ksk-rollover>> while we have less than four weeks. The communication part of the rollover is not handled seriously. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
David, Do I sense some sarcasm in your answer? Even though I am of the opinion that operational matters shouldn't be a topic for the board at all, I respect that ICANN have come to another conclusion. I am afraid though, that you (ICANN) underestimate the attention put on this from a lot of people with interest in the dnssec, especially the key rollover. Only last week I gave three presentations about dnssec, what, how and why, two in Stockholm and one in Dublin, where the DNSSEC key ceremonies and especially the key rollover was an important part. On top of that I gave two interviews, one for Computer Sweden and one for the largest daily Swedish newspaper, Dagens Nyheter. IIS are working close together with Swedish authorities and ISP's to make sure they are up to date with the progress. By the end of this month the largest Swedish dairy provider (!) will tell the story about dnssec and the key on the milk boxes. In this context communication and transparency is important. You've been aware of when the decision should be made, messages could have been prepared in beforehand whether it would have been a yes, proceed or no, postpone, at least for the mailing lists. If the board consider it so important that they have a meeting on a Sunday, then the conclusion that people would like to have the result instantly is not very surprising, is it? Looking forward to further and more detailed information on the official web site, the twitter account and the mailing lists! Kind regards, Anne-Marie Eklund Löwinder Chief Information Security Officer The Swedish Internet Foundation, IIS https://www.iis.se
-----Ursprungligt meddelande----- Från: ksk-rollover <ksk-rollover-bounces@icann.org> För David Conrad Skickat: den 17 september 2018 10:45 Till: Stephane Bortzmeyer <bortzmeyer@nic.fr> Kopia: KSK Rollover <ksk-rollover@icann.org> Ämne: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
Stephane,
Just for clarity, the Board approved moving forward with the revised KSK rollover plan less than 24 hours ago, on a Sunday.
Normal process at ICANN is to not announce things until the resolutions are posted. For internal process reasons, it takes a bit of time to post the resolutions.
Sorry we’re apparently not able to meet your standards for seriousness.
Regards, -drc
On Sep 17, 2018, at 8:51 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr <mailto:bortzmeyer@nic.fr> > wrote:
On Mon, Sep 17, 2018 at 04:26:39AM +0000, Ben Lee <ben.lee@hkirc.hk <mailto:ben.lee@hkirc.hk> > wrote a message of 176 lines which said:
Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018?
You know more than I do. There is nothing on <https://www.icann.org/resources/pages/ksk-rollover> while we have less than four weeks. The communication part of the rollover is not handled seriously. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
Ben, The Board voted to approve the resolution for ICANN org to move forward with the revised KSK rollover plan. So barring unforeseen circumstances, the KSK-2017-signed ZSK will be used to sign the root zone on 11 October 2018. Regards, -drc
On Sep 17, 2018, at 6:26 AM, Ben Lee <ben.lee@hkirc.hk> wrote:
I would like to check for the latest status on ICANN root KSK rollover.
Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018? Does the root KSK rollover is now confirmed to be 11 Oct 2018?
Thank you.
Best regards, Ben _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Sep 17, 2018, at 1:38 AM, David Conrad <david.conrad@icann.org> wrote:
The Board voted to approve the resolution for ICANN org to move forward with the revised KSK rollover plan. So barring unforeseen circumstances, the KSK-2017-signed ZSK will be used to sign the root zone on 11 October 2018.
As a followup to this, and because someone asked offline what time the rollover will happen, the current, fairly-firm plan is for the rollover to happen at 1600 UTC on October 11 unless something stops the process before then. We'll send more detailed messages about this to this list in the future. --Paul Hoffman
In any case it would take a good communication plan with relays in different countries. This is very important to allow for better monitoring and bug tracking (if there is) Ramanou Le lun. 17 sept. 2018 à 16:05, Paul Hoffman <paul.hoffman@icann.org> a écrit :
The Board voted to approve the resolution for ICANN org to move forward with the revised KSK rollover plan. So barring unforeseen circumstances, the KSK-2017-signed ZSK will be used to sign the root zone on 11 October
On Sep 17, 2018, at 1:38 AM, David Conrad <david.conrad@icann.org> wrote: 2018.
As a followup to this, and because someone asked offline what time the rollover will happen, the current, fairly-firm plan is for the rollover to happen at 1600 UTC on October 11 unless something stops the process before then. We'll send more detailed messages about this to this list in the future.
--Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- *--BIAOU Ramanou**--* --www.biaou.net--
On Sep 17, 2018, at 7:11 AM, Ramanou S. BIAOU <ramanou@biaou.net> wrote:
In any case it would take a good communication plan with relays in different countries.
Of course. Now that the Board has approve the rollover, our communications team will start implementing the plans they have had in place for months. --Paul Hoffman
It's good to know. The details of this plan will be known? How does it apply at the local level of different countries? ISOC chapters or local NOGs are used to better pass the information? Ramanou Le lun. 17 sept. 2018 à 16:16, Paul Hoffman <paul.hoffman@icann.org> a écrit :
On Sep 17, 2018, at 7:11 AM, Ramanou S. BIAOU <ramanou@biaou.net> wrote:
In any case it would take a good communication plan with relays in
different countries.
Of course. Now that the Board has approve the rollover, our communications team will start implementing the plans they have had in place for months.
--Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- *--BIAOU Ramanou**--* --www.biaou.net--
On Mon, Sep 17, 2018 at 04:23:53PM +0200, Ramanou S. BIAOU <ramanou@biaou.net> wrote a message of 105 lines which said:
How does it apply at the local level of different countries? ISOC chapters or local NOGs are used to better pass the information?
I assume it will be our work (by, "our", I mean the people on this list and their friends and colleagues) to outreach and to distribute information as efficiently as posisble, depending on the local context. (For instance, I keep FRnOG, the french network operators group, up to date.) This takes time (and fight against skepticims such as "don't worry, they will cancel it at the last minute"). That's why it is important to have stable and firm information in advance, and that's why it is not serious that, a few weeks before the event, the ICANN board is still discussing the date.
Stephane, As you may have seen, the announcement for the board resolution has been posted (https://www.icann.org/resources/press-material/release-2018-09-18-en) and is referenced off the icann.org home page.
On Sep 18, 2018, at 11:31 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Sep 17, 2018 at 04:23:53PM +0200, Ramanou S. BIAOU <ramanou@biaou.net <mailto:ramanou@biaou.net>> wrote a message of 105 lines which said:
How does it apply at the local level of different countries? ISOC chapters or local NOGs are used to better pass the information?
I assume it will be our work (by, "our", I mean the people on this list and their friends and colleagues) to outreach and to distribute information as efficiently as posisble, depending on the local context. (For instance, I keep FRnOG, the french network operators group, up to date.)
In all honesty, thank you for your efforts.
This takes time (and fight against skepticims such as "don't worry, they will cancel it at the last minute"). That's why it is important to have stable and firm information in advance, and that's why it is not serious that, a few weeks before the event, the ICANN board is still discussing the date.
Just for clarity, below is a list of some of the efforts ICANN has taken put together for the Board by ICANN’s communications team (and it does not include the “KSK preparedness survey” we sent to the contacts of 11,500+ ASes from which we received RFC 8145 data) . The fact that the Board made their decision when they did has in no way impacted our (and others') efforts at outreach and has to do more with the timing of Board activities than anything else. The only thing the Board decision has impacted in ICANN’s outreach efforts was was the use of the word “provisional”. Regards, -drc P.S. Apologies if the below gets mangled: cut and paste from a Word doc run through ICANN mail servers. 1. Media publications As of this writing, 152 news stories about the KSK rollover, from all global regions, have been published. Some recent examples include: · ICANN CTO: no reason to delay KSK rollover <http://domainincite.com/23320-icann-cto-no-reason-to-delay-ksk-rollover> (English, Domain Incite, USA) - August 2018 · ICANN Issues Guide on What to Expect During Root KSK Rollover <https://gallery.mailchimp.com/818d573897ed5ea25ee71ebc1/files/1f20693f-8e68-...> (English, Washington Internet Daily, USA) - August 2018 · Global Internet Service Providers Should Be Ready: ICANN will complete key rotation <https://www.sohu.com/a/250814240_118392> (English, Economic Daily, China) - August 2018 <>2. Other communications efforts Eleven blogs/announcements were published, since May 2016, relating to the root KSK rollover and each was accompanied by social media pushes. 22 August 2018 - ICANN Publishes Comprehensive Guide on What to Expect During the Root KSK Rollover <https://www.icann.org/news/announcement-2018-08-22-en> 18 July 2018- Minimal User Impact Expected From Root Zone Key Signing Key (KSK) Rollover <https://www.icann.org/news/blog/minimal-user-impact-expected-from-root-zone-...> 1 February 2018 – <https://www.icann.org/news/blog/announcing-draft-plan-for-continuing-with-the-ksk-roll>Announcing Draft Plan For Continuing With The KSK Roll <https://www.icann.org/news/blog/announcing-draft-plan-for-continuing-with-th...> 18 December 2017 – <https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project>Update on the Root KSK Rollover Project <https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project> 4 October 2017 - The Story Behind ICANN’s Decision to Delay the KSK Rollover <https://www.icann.org/news/blog/the-story-behind-icann-s-decision-to-delay-t...> 7 September 2017 – <https://www.icann.org/news/blog/attention-network-operators-and-isps-determine-your-readiness-for-the-root-zone-ksk-rollover>Attention Network Operators and ISPs: Determine your readiness for the Root Zone KSK Rollover <https://www.icann.org/news/blog/attention-network-operators-and-isps-determine-your-readiness-for-the-root-zone-ksk-rollover>! <https://www.icann.org/news/blog/attention-network-operators-and-isps-determi...> 12 July 2017 – <https://www.icann.org/news/blog/a-key-milestone-in-protecting-the-dns>A “Key” Milestone in Protecting the DNS <https://www.icann.org/news/blog/a-key-milestone-in-protecting-the-dns> 13 March 2017 – <https://www.icann.org/resources/pages/ksk-rollover>ICANN Launches Testing Platform for the KSK Rollover <https://www.icann.org/resources/pages/ksk-rollover> 27 October 2016 – <https://www.icann.org/news/blog/ksk-rollover-operations-begin>KSK Rollover Operations Begin <https://www.icann.org/news/blog/ksk-rollover-operations-begin> 22 July 2016 – <https://www.icann.org/news/blog/dnssec-rolling-the-root-zone-key-signing-key>DNSSEC: Rolling the Root Zone Key Signing Key <https://www.icann.org/news/blog/dnssec-rolling-the-root-zone-key-signing-key> 9 May 2016 – <https://www.icann.org/news/blog/changing-the-keys-to-the-domain-name-system-dns-root-zone>Changing the Keys to the Domain Name System (DNS) Root <https://www.icann.org/news/blog/changing-the-keys-to-the-domain-name-system-...> ● In August 2018, ICANN org published a Guide <https://www.icann.org/en/system/files/files/ksk-rollover-expect-22aug18-en.p...> on what to expect during the root KSK rollover. This guide has been translated into all UN languages and Portuguese, Japanese, and Korean. Also in August 2018, a social media paid campaign was launch into all UN languages, pointing to the Guide “What To Expect During the Root KSK Rollover”. You can see the message shared in English here <https://twitter.com/ICANN/status/1034138056435986432>. Additionally, a banner was placed in the homepage of icann.org pointing to that Guide. ● In May 2018, the regional GSE teams sent a letter on behalf of David Conrad to Internet Exchange Points (IXP) administrators around the world. The letter was translated and is available <https://wecann.icann.org/groups/ksk/content>here <https://wecann.icann.org/groups/ksk/content> on weCANN (ICANN’s internal web site). ● In October 2017, a letter to all regulators and GAC representatives (that were contacted in June 2017 -see below) was <https://www.icann.org/en/system/files/correspondence/marby-to-internet-telecomm-regulators-06oct17-en.pdf>sent to announce the postponement <https://www.icann.org/en/system/files/correspondence/marby-to-internet-telec...> of the root KSK rollover. A letter was sent (via IANA functions) to contacts for all Top-Level Domains informing them of the KSK rollover activity, requesting help in spreading the message, emphasizing that the activity does not impact their authoritative DNS services. Göran Marby sent a letter to telecommunications regulators in over 150 countries notifying them of the root KSK roll and asking them to contact network operators in their countries. ● In April 2018, icann.org’s <https://www.icann.org/resources/pages/ksk-rolloverG>dedicated resource page <https://www.icann.org/resources/pages/ksk-rolloverG> was updated in 9 languages for the new phase of the key roll along with the updated resource “Quick Guide: Prepare Your Systems for the Root KSK Rollover”. ● Numerous pieces about the key roll were published in ICANN’s regional and meetings newsletters. ● A deck was provided for external engagement efforts on the root KSK rollover (available in all UN languages and Portuguese on WeCANN). 3. Public Presentations Since September 2016, the Global Stakeholder Engagement (GSE) and the Office of the Chief Technology Officer (OCTO) have been involved in 104 engagements that dealt with the KSK roll. Examples of presentations held in 2018 include: Aug-18 APrIGF, Republic of Vanuatu Aug-18 INNOG, India Aug-18 SANOG, Bangladesh Aug-18 FFGI in Ouagadougou, Burkina Faso (Yaovi Atahoun) Aug-18 iweek, Capetown, South Africa (Bob Ochieng) Aug-18 South American LAC-i-Roadshow, Montevideo, Uruguay (Daniel Fink) Aug-18 4ta Jornada de Tecnología y Seguridad DNS, Bogota, Colombia (Daniel Fink) Jul-18 IX Fórum Regional do NIC.br, Goiânia, Brazil (Daniel Fink) Jun-18 ENOG 15, Russia (Ed Lewis) May-18 LACNIC 29, Panama (Andres Pavez) May-18 EE Cert (Ed Lewis) May-18 CENTR (Ed Lewis) Apr-18 I2c webinar (Matt Larson) Mar-18 DNS-OARC 28, Puerto Rico (Matt Larson) Mar-18 ICANN 61 DNSSEC Workshop, Puerto Rico (Matt Larson) Mar-18 ICANN 61 KSK Rollover Update, Puerto Rico (Matt Larson) Mar-18 IETF, London (David Conrad) Mar-18 U.S. Council for International Business, USA (Matt Larson)
On Sep 17, 2018, at 7:11 AM, Ramanou S. BIAOU <ramanou@biaou.net> wrote:
This is very important to allow for better monitoring and bug tracking (if there is)
Thank you for bringing this up. ICANN will certainly be monitoring and tracking reports of problems, and we hope that other organizations do so as well. This mailing list is a great place to coordinate such activities. If enough organizations are doing their own tracking in public, we can set up a public page to help coordinate. --Paul Hoffman
Also just to confirm that DNS-OARC will be co-ordinating another of its DITL collection exercises during the rollover, with PCAP query data being gathered from all the root operators for the 48-hour window spanning the rollover. While this is unlikely to flag up immediate operational issues as it happens, it will give the community an archive and baseline against previous similar events, and for in-depth analysis after the event. See https://www.dns-oarc.net/oarc/data/ksk1 for information on data gathered during the first phase of the Rollover in Sep 2017. Keith Mitchell DNS-OARC On 09/17/2018 10:17 AM, Paul Hoffman wrote:
On Sep 17, 2018, at 7:11 AM, Ramanou S. BIAOU <ramanou@biaou.net> wrote:
This is very important to allow for better monitoring and bug tracking (if there is)
Thank you for bringing this up. ICANN will certainly be monitoring and tracking reports of problems, and we hope that other organizations do so as well. This mailing list is a great place to coordinate such activities. If enough organizations are doing their own tracking in public, we can set up a public page to help coordinate.
--Paul Hoffman
On Tue, Sep 18, 2018 at 01:40:39PM +0200, Lars-Johan Liman <liman@netnod.se> wrote a message of 12 lines which said:
In any case it would take a good communication plan ...
... which relies as little as possible on the public DNS system, right?
Until 11 october, we can communicate, let's take advantage of that.
Le mar. 18 sept. 2018 à 13:45, Stephane Bortzmeyer <bortzmeyer@nic.fr> a écrit :
On Tue, Sep 18, 2018 at 01:40:39PM +0200, Lars-Johan Liman <liman@netnod.se> wrote a message of 12 lines which said:
In any case it would take a good communication plan ...
... which relies as little as possible on the public DNS system, right?
Until 11 october, we can communicate, let's take advantage of that.
Anyway, 11 October is in about 20 days. There is still time to do somethings
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- *--BIAOU Ramanou**--* --www.biaou.net--
At the risk of disturbing the snake in the woodpile - when is the *next* rollover? Or at least when will ICANN take up scheduling it? While this has been a painful process, repeating it at least a few times very soon so that we reinforce lessons learned seems only provident. I would suggest NET June 2019 and NLT May 2020. Later, Mike On 9/17/2018 4:38 AM, David Conrad wrote:
Ben,
The Board voted to approve the resolution for ICANN org to move forward with the revised KSK rollover plan. So barring unforeseen circumstances, the KSK-2017-signed ZSK will be used to sign the root zone on 11 October 2018.
Regards, -drc
On Sep 17, 2018, at 6:26 AM, Ben Lee <ben.lee@hkirc.hk <mailto:ben.lee@hkirc.hk>> wrote:
I would like to check for the latest status on ICANN root KSK rollover.
Is it right the ICANN Board has discussed and approved the current plan on 16 Sep 2018?
Does the root KSK rollover is now confirmed to be 11 Oct 2018?
Thank you.
Best regards,
Ben
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Mike, On Sep 17, 2018, at 3:51 PM, Michael StJohns <msj@nthpermutation.com<mailto:msj@nthpermutation.com>> wrote: At the risk of disturbing the snake in the woodpile - when is the *next* rollover? Or at least when will ICANN take up scheduling it? While this has been a painful process, repeating it at least a few times very soon so that we reinforce lessons learned seems only provident. I would suggest NET June 2019 and NLT May 2020. The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. The other comment I've made when this question comes up is that we will continue to listen to the community, just as we have at every point in the planning for the first rollover. Matt -- Matt Larson, VP of Research ICANN Office of the CTO
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit. Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 18 Sep 2018, at 01:44, Olaf Kolkman <kolkman@isoc.org> wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. Agree.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. Agree
I would really like to see that strategic position being explicit.
based on the statements above, i tend to support the idea of this strategic position be proposed and discussed once we are done with this current and 1st rollover. —Alain
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover> _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
I agree too. I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood. Cheers, /Liman kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
I agree with the sentiment that there should be a "regular" KSK Key roll-over - probably once every five years (though I roll my KSK's once a year). However, I would agree that it first makes sense for this roll-over to complete first - along with some research to understand any mishaps. Regarding people reaching out to their own communities - anyone got an outline of what such a communication would contain? In South Africa, up to 50% of lookups are via DNSSEC aware recursive resolvers according to https://stats.labs.apnic.net/dnssec - so this would seem like a worth while exercise. On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
I think the setting of this discussion is missing some key elements: the DNS Root KSK is a global root of trust. The extent to which we build on that is the extent to which software will need for this key to be well known, knowable, and learnable. As the frequency of its rollover increases, so too does the probability that software will have out of date keys (especially I the context of hyperlocal roots). If you factor DANE in, that root has even more importance to end-user perception. I think it needs to be a top priority to ensure that DNS Relying Party (RP) software knows how to maintain the current key, keep up with rollovers, and re-bootstrap when it loses the correct key (a failure mode that software absolutely will experience). As of now, I don’t think we have more than a few nascent ideas about how to handle this. Just my 0.02, Eric
On Sep 18, 2018, at 9:39 AM, Mark Elkins <mje@posix.co.za> wrote:
I agree with the sentiment that there should be a "regular" KSK Key roll-over - probably once every five years (though I roll my KSK's once a year).
However, I would agree that it first makes sense for this roll-over to complete first - along with some research to understand any mishaps.
Regarding people reaching out to their own communities - anyone got an outline of what such a communication would contain? In South Africa, up to 50% of lookups are via DNSSEC aware recursive resolvers according to https://stats.labs.apnic.net/dnssec - so this would seem like a worth while exercise.
On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 21 Sep 2018, at 11:05, Eric Osterweil wrote:
I think the setting of this discussion is missing some key elements: the DNS Root KSK is a global root of trust. The extent to which we build on that is the extent to which software will need for this key to be well known, knowable, and learnable. As the frequency of its rollover increases, so too does the probability that software will have out of date keys (especially I the context of hyperlocal roots). If you factor DANE in, that root has even more importance to end-user perception. I think it needs to be a top priority to ensure that DNS Relying Party (RP) software knows how to maintain the current key, keep up with rollovers, and re-bootstrap when it loses the correct key (a failure mode that software absolutely will experience). As of now, I don’t think we have more than a few nascent ideas about how to handle this.
right but: - people are lazy: until there are real events (KSK rollover), they will not care or prepare. Therefore, we must have rollover enough frequent so people do act. - there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases. - for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route. my 2c Marc.
Just my 0.02,
Eric
On Sep 18, 2018, at 9:39 AM, Mark Elkins <mje@posix.co.za> wrote:
I agree with the sentiment that there should be a "regular" KSK Key roll-over - probably once every five years (though I roll my KSK's once a year).
However, I would agree that it first makes sense for this roll-over to complete first - along with some research to understand any mishaps.
Regarding people reaching out to their own communities - anyone got an outline of what such a communication would contain? In South Africa, up to 50% of lookups are via DNSSEC aware recursive resolvers according to https://stats.labs.apnic.net/dnssec - so this would seem like a worth while exercise.
On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 21/09/2018 16:12, Marc Blanchet wrote:
right but: - people are lazy: until there are real events (KSK rollover), they will not care or prepare. Therefore, we must have rollover enough frequent so people do act. - there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases. - for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route.
What about the (hypothetical?) home CPE with a validating resolver that's been left on the shelf for a couple of years. RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for those is still an unsolved problem. Ray
On 21 Sep 2018, at 11:34, Ray Bellis wrote:
On 21/09/2018 16:12, Marc Blanchet wrote:
right but: - people are lazy: until there are real events (KSK rollover), they will not care or prepare. Therefore, we must have rollover enough frequent so people do act. - there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases. - for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route.
What about the (hypothetical?) home CPE with a validating resolver that's been left on the shelf for a couple of years.
RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for those is still an unsolved problem.
agreed. that one unresolved yet. (I was writing in the context of ISP resolvers which I understood was the underlying discussion context. ) Marc.
Ray
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ray> What about the (hypothetical?) home CPE with a validating resolver ray> that's been left on the shelf for a couple of years. ray> RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for ray> those is still an unsolved problem. If said CPE has 2 year old OS/firmware, DNSSEC validation is the least of the problems it causes if the vendor hasn't figured out how to do sane/clean updates automatically. Keeping it from being usefully connected to the internet might be considered a public service. ;)
On 9/21/2018 11:34 AM, Ray Bellis wrote:
What about the (hypothetical?) home CPE with a validating resolver that's been left on the shelf for a couple of years.
RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for those is still an unsolved problem.
I wish people would stop repeating this stupid canard. It's almost as stupid as "IOT devices need less security". Yes, there is no "standard" way of resolving this. However, it's pretty much solved. The first thing a CPE router should do upon awakening is check the time to find out how long its been asleep (e.g. NVRAM time stamp the last boot), then try and download an updated firmware version from the CPE manufacturer's servers with more recent trust anchors. The "its been on the shelf for years and it should just work" is a pretty much stupid model. Security rots bit by bit over time until at some point you need to get a human involved. I can't even plug in a TV these days without doing a bit of configuration - why wouldn't I have to configure (or at least push the button to auto-configure) this trust anchor update? Firmware signing keys are both problematic and time-limited. Problematic because you mostly have no way of reliably and securely updating the deployed devices (exceptions exist, but the cost/benefit for CPE is lacking) firmware public key. Time-limited because IT devices have a 3-7 year lifecycle - including especially home CPE routers, cable modems and WiFi installations. I mention this because while the problem is a DNSOP problem, it is not a DNSEXT problem. E.g. there's no protocol in the world that will fix this perceived problem. But guidance to the CPE vendors that they need to provide firmware updates for at least N years after manufacture and that those firmware updates may include new root public keys seems like a good document to write. Later, Mike
On 21 Sep 2018, at 13:02, Michael StJohns wrote:
On 9/21/2018 11:34 AM, Ray Bellis wrote:
What about the (hypothetical?) home CPE with a validating resolver that's been left on the shelf for a couple of years.
RFC 5011 doesn't help those. AFAIK, re-bootstrapping trust for those is still an unsolved problem.
I wish people would stop repeating this stupid canard. It's almost as stupid as "IOT devices need less security".
Yes, there is no "standard" way of resolving this. However, it's pretty much solved. The first thing a CPE router should do upon awakening is check the time to find out how long its been asleep (e.g. NVRAM time stamp the last boot), then try and download an updated firmware version from the CPE manufacturer's servers with more recent trust anchors.
The "its been on the shelf for years and it should just work" is a pretty much stupid model. Security rots bit by bit over time until at some point you need to get a human involved. I can't even plug in a TV these days without doing a bit of configuration - why wouldn't I have to configure (or at least push the button to auto-configure) this trust anchor update?
Firmware signing keys are both problematic and time-limited. Problematic because you mostly have no way of reliably and securely updating the deployed devices (exceptions exist, but the cost/benefit for CPE is lacking) firmware public key. Time-limited because IT devices have a 3-7 year lifecycle - including especially home CPE routers, cable modems and WiFi installations. I mention this because while the problem is a DNSOP problem, it is not a DNSEXT problem. E.g. there's no protocol in the world that will fix this perceived problem. But guidance to the CPE vendors that they need to provide firmware updates for at least N years after manufacture and that those firmware updates may include new root public keys seems like a good document to write.
you are right, but what we can see in the field is not that. firmwares are rarely updated (on purpose, so you instead by a new CPE… and send them more money, they like it…). Marc.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 21/09/2018 18:02, Michael StJohns wrote:
I wish people would stop repeating this stupid canard. It's almost as stupid as "IOT devices need less security".
I should clarify. It's *technically* a problem with a solution, as you've outlined. Getting such a solution *commercially deployed* in low cost CPE seems somewhat harder.
But guidance to the CPE vendors that they need to provide firmware updates for at least N years after manufacture and that those firmware updates may include new root public keys seems like a good document to write.
I don't think IETF guidance alone will suffice. It may require legislative mandate. Ray
I don't think IETF guidance alone will suffice. It may require legislative mandate.
In the U.S., Senator Edward Markey and Representative Ted Lieu have introduced legislation called the Cybershield Act. The intention is to create a product labelling system for IoT devices, in hopes consumers are made more aware of these issues and hopefully buy products that are certified. https://www.markey.senate.gov/imo/media/doc/CyberShield%20bill.pdf “The Cyber Shield Act will establish an advisory committee of cybersecurity experts from academia, industry, consumer advocates, and the public to create cybersecurity benchmarks for IoT devices, such as baby monitors, cameras, cellphones, laptops, and tablets. IoT manufacturers can voluntarily certify that their product meets those cybersecurity and data security benchmarks, and display this certification to the public.” https://www.markey.senate.gov/news/press-releases/senator-markey-and-rep-lie...
On Fri, Sep 21, 2018 at 1:21 PM Ray Bellis <ray@isc.org> wrote:
On 21/09/2018 18:02, Michael StJohns wrote:
I wish people would stop repeating this stupid canard. It's almost as stupid as "IOT devices need less security".
I should clarify.
It's *technically* a problem with a solution, as you've outlined.
Getting such a solution *commercially deployed* in low cost CPE seems somewhat harder.
But guidance to the CPE vendors that they need to provide firmware updates for at least N years after manufacture and that those firmware updates may include new root public keys seems like a good document to write.
I don't think IETF guidance alone will suffice. It may require legislative mandate.
Wes Hardaker and I have a proto-draft called "Ball and Chain" - it basically provides a chain of KSKs from the current, to the next, to the next, to... A resolver which has been sitting for many years can enter at whatever KSK it knows about, and walk its way up the chain (never down) until it reaches the current one. The keys can be annotated to provide info like "this was a normal rollover, keep going" or "this rollover occured because of compromise, abort, and revoke if you have already seen it". This is not perfect - a resolver which was sleeping, and *first* awakes behind a malicious attacker who has a copy of the private key from a compromised KSK could be lead astray -- but, this is one of those "you need to discuss the threat model" cases. Obviously, this can and should be used in conjunction with things like TLS checks, etc. I cannot remember if we actually published the draft, or were sufficiently despondent after the last few meetings that we didn't bother.... I can find it if people are interested.... W
Ray _______________________________________________ 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
Hi Marc, Sorry, jumping back to this (even though there have been a few follow on emails)
On Sep 21, 2018, at 11:12 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
On 21 Sep 2018, at 11:05, Eric Osterweil wrote:
I think the setting of this discussion is missing some key elements: the DNS Root KSK is a global root of trust. The extent to which we build on that is the extent to which software will need for this key to be well known, knowable, and learnable. As the frequency of its rollover increases, so too does the probability that software will have out of date keys (especially I the context of hyperlocal roots). If you factor DANE in, that root has even more importance to end-user perception. I think it needs to be a top priority to ensure that DNS Relying Party (RP) software knows how to maintain the current key, keep up with rollovers, and re-bootstrap when it loses the correct key (a failure mode that software absolutely will experience). As of now, I don’t think we have more than a few nascent ideas about how to handle this.
right but: - people are lazy: until there are real events (KSK rollover), they will not care or prepare. Therefore, we must have rollover enough frequent so people do act.
I would argue that we can (and should) do some more (tooling, analysis, etc.) to give them the ability to keep not caring without having to turn DNSSEC off altogether because it gives them a bad day. I strongly fear that those serious operators who opt to turn DNSSEC off will decide not to turn it back on again. All of this is in the context of comments above that DNSSEC is being used for, and able to be extended, for a lot of security protections beyond just DNSSEC itself.
- there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases.
Happy to have a discussion about this (here or elsewhere), but I worry that the 5011 mechanism might need more evaluation against threat models, and subsequent enhancements. As Ray brought up in a later comment on this, 5011 doesn't handle re-bootstrapping.
- for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route.
I definitely don’t think that’s sufficient. For real security concerns, I don’t think we can leave things at laissez faire. Eric
my 2c
Marc.
Just my 0.02,
Eric
On Sep 18, 2018, at 9:39 AM, Mark Elkins <mje@posix.co.za> wrote:
I agree with the sentiment that there should be a "regular" KSK Key roll-over - probably once every five years (though I roll my KSK's once a year).
However, I would agree that it first makes sense for this roll-over to complete first - along with some research to understand any mishaps.
Regarding people reaching out to their own communities - anyone got an outline of what such a communication would contain? In South Africa, up to 50% of lookups are via DNSSEC aware recursive resolvers according to https://stats.labs.apnic.net/dnssec - so this would seem like a worth while exercise.
On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
On 21 Sep 2018, at 12:16, Eric Osterweil wrote:
Hi Marc,
Sorry, jumping back to this (even though there have been a few follow on emails)
On Sep 21, 2018, at 11:12 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
On 21 Sep 2018, at 11:05, Eric Osterweil wrote:
I think the setting of this discussion is missing some key elements: the DNS Root KSK is a global root of trust. The extent to which we build on that is the extent to which software will need for this key to be well known, knowable, and learnable. As the frequency of its rollover increases, so too does the probability that software will have out of date keys (especially I the context of hyperlocal roots). If you factor DANE in, that root has even more importance to end-user perception. I think it needs to be a top priority to ensure that DNS Relying Party (RP) software knows how to maintain the current key, keep up with rollovers, and re-bootstrap when it loses the correct key (a failure mode that software absolutely will experience). As of now, I don’t think we have more than a few nascent ideas about how to handle this.
right but: - people are lazy: until there are real events (KSK rollover), they will not care or prepare. Therefore, we must have rollover enough frequent so people do act.
I would argue that we can (and should) do some more (tooling, analysis, etc.) to give them the ability to keep not caring without having to turn DNSSEC off altogether because it gives them a bad day. I strongly fear that those serious operators who opt to turn DNSSEC off will decide not to turn it back on again. All of this is in the context of comments above that DNSSEC is being used for, and able to be extended, for a lot of security protections beyond just DNSSEC itself.
yeap. agree. people are lazy. so some of them will just turn it off (and other priorities come by and never take time to put it back). I’ve managed provider networks and I can see that. sadly.
- there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases.
Happy to have a discussion about this (here or elsewhere), but I worry that the 5011 mechanism might need more evaluation against threat models, and subsequent enhancements.
sure. but to me « good enough » for a lot of use cases.
As Ray brought up in a later comment on this, 5011 doesn't handle re-bootstrapping.
- for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route.
I definitely don’t think that’s sufficient. For real security concerns, I don’t think we can leave things at laissez faire.
laissez faire is not what I wrote. Some people prefer (for a lot of reasons, including security assessments and risks) to do manual. I’m just saying this is the reality and in that context, they have to take the responsability to do it « right ». Marc.
Eric
my 2c
Marc.
Just my 0.02,
Eric
On Sep 18, 2018, at 9:39 AM, Mark Elkins <mje@posix.co.za> wrote:
I agree with the sentiment that there should be a "regular" KSK Key roll-over - probably once every five years (though I roll my KSK's once a year).
However, I would agree that it first makes sense for this roll-over to complete first - along with some research to understand any mishaps.
Regarding people reaching out to their own communities - anyone got an outline of what such a communication would contain? In South Africa, up to 50% of lookups are via DNSSEC aware recursive resolvers according to https://stats.labs.apnic.net/dnssec - so this would seem like a worth while exercise.
On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote: > The answer I've given when people ask this question is that we > need to > get through the first rollover and analyze how it goes before we > can > discuss subsequent rollovers. One can imagine that how the first > rollover goes could have a material effect on the timing of the > next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
On Sep 21, 2018, at 12:21 PM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
On 21 Sep 2018, at 12:16, Eric Osterweil wrote:
<snip>
- there are mechanisms to help/automate rollover, such as RFC5011, which shall fit with most use cases.
Happy to have a discussion about this (here or elsewhere), but I worry that the 5011 mechanism might need more evaluation against threat models, and subsequent enhancements.
sure. but to me « good enough » for a lot of use cases.
I guess I just don’t think that sounds like a very safe/secure way to manage operational security concerns, especially when there is this much at stake. Consider DANE’s already_ large usage footprint. Those systems’ security will suffer from a compromise here too. This isn’t all gloom and doom. Rigorous discussions and publications about on-path/off-path/topology/etc. considerations do exist (even in the context of DNSSEC). I just really think that before we get too far down the road of rolling, then rolling again, then rolling again, we would be well served by considering the needs for resilient/secure key learning for our global Root.
As Ray brought up in a later comment on this, 5011 doesn't handle re-bootstrapping.
- for the use cases/reasons people not use RFC5011, then it is like any manual configuration management: you take the responsability to put whatever process in your org to handle that case, since you are aware that you are taking the manual route.
I definitely don’t think that’s sufficient. For real security concerns, I don’t think we can leave things at laissez faire.
laissez faire is not what I wrote. Some people prefer (for a lot of reasons, including security assessments and risks) to do manual. I’m just saying this is the reality and in that context, they have to take the responsability to do it « right ».
Fair point, those were my words (not trying to impute them to you), and if I missed your point: I’m doubly sorry. I was just saying that there are a lot of ways this can bite us, and if we don’t make it clear how important Root KSK mgmt is, and what the height requirements are, we might pay for that later. Eric
My original(historical) question was - why not each Ceremony? Do we really still need spliting KSK/ZSK? I remember a lot historical arguments against from Shinkuro people - but I still think that they are artificial. Dima On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
Cheers, /Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit.
Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one. This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Tue, 18 Sep 2018, Dmitry Burkov wrote:
Do we really still need spliting KSK/ZSK?
Yes we do. The number of KSK private key access should be kept at a minimum and all of them audited. If you remove the split, any operations person can create secret ZSKs to be used in targeted attacks. It might be very unlikely but I think we need the insurance.
On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
I agree doing this annually would prevent hardcoding in software. I think that is a great discussion to start a week after this roll :) Paul
+1 to both of Paul’s points. 1- splitting the keys is good 2- rolling (semi)anually seems a good thing too, prevents people from becoming complacent On 18 Sep 2018, at 11:22, Paul Wouters wrote:
On Tue, 18 Sep 2018, Dmitry Burkov wrote:
Do we really still need spliting KSK/ZSK?
Yes we do. The number of KSK private key access should be kept at a minimum and all of them audited. If you remove the split, any operations person can create secret ZSKs to be used in targeted attacks. It might be very unlikely but I think we need the insurance.
On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
I agree doing this annually would prevent hardcoding in software. I think that is a great discussion to start a week after this roll :)
Paul _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Paul, not sure that I understood you. I told about the case when we will have one key - but you again mentioned KSK and ZSK Or - please - correct the terminology for this case Dima On 9/18/18 5:22 PM, Paul Wouters wrote:
On Tue, 18 Sep 2018, Dmitry Burkov wrote:
Do we really still need spliting KSK/ZSK?
Yes we do. The number of KSK private key access should be kept at a minimum and all of them audited. If you remove the split, any operations person can create secret ZSKs to be used in targeted attacks. It might be very unlikely but I think we need the insurance.
On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
I agree doing this annually would prevent hardcoding in software. I think that is a great discussion to start a week after this roll :)
Paul
Sorry you are right. Reread it as “minimize people with access to the most top level key as much as possible”. Sent from my phone
On Sep 18, 2018, at 11:18, Dmitry Burkov <dvburk@gmail.com> wrote:
Paul,
not sure that I understood you.
I told about the case when we will have one key - but you again mentioned KSK and ZSK
Or - please - correct the terminology for this case
Dima
On 9/18/18 5:22 PM, Paul Wouters wrote:
On Tue, 18 Sep 2018, Dmitry Burkov wrote:
Do we really still need spliting KSK/ZSK?
Yes we do. The number of KSK private key access should be kept at a minimum and all of them audited. If you remove the split, any operations person can create secret ZSKs to be used in targeted attacks. It might be very unlikely but I think we need the insurance.
On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood.
I agree doing this annually would prevent hardcoding in software. I think that is a great discussion to start a week after this roll :)
Paul
I absolutely agree with you On 9/18/18 6:37 PM, Paul Wouters wrote:
Sorry you are right.
Reread it as “minimize people with access to the most top level key as much as possible”.
Sent from my phone
On Sep 18, 2018, at 11:18, Dmitry Burkov <dvburk@gmail.com> wrote:
Paul,
not sure that I understood you.
I told about the case when we will have one key - but you again mentioned KSK and ZSK
Or - please - correct the terminology for this case
Dima
On 9/18/18 5:22 PM, Paul Wouters wrote:
On Tue, 18 Sep 2018, Dmitry Burkov wrote:
Do we really still need spliting KSK/ZSK? Yes we do. The number of KSK private key access should be kept at a minimum and all of them audited. If you remove the split, any operations person can create secret ZSKs to be used in targeted attacks. It might be very unlikely but I think we need the insurance.
On 9/18/18 3:46 PM, Lars-Johan Liman wrote:
I think we should set an "intense" schedule (twice per year? once per year?) _beforehand_, to send the message that "there is no relief after this, there is only more pain ahead ... unless you automate!" to the DNS software community. There must be no way to hardcode the KSK in code. This will continue to be this painful until that message is received and understood. I agree doing this annually would prevent hardcoding in software. I think that is a great discussion to start a week after this roll :)
Paul
Hi, We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)). As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023. However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous. The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned). Regards, -drc On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org<mailto:kolkman@isoc.org>> wrote: I agree with Michael, albeit I would phrase it slightly differently: Rolling the key regularly is a strategic choise and makes a keyroll an operational reality. How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings. I would really like to see that strategic position being explicit. Olaf. ---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org<mailto:ksk-rollover-bounces@icann.org>> on behalf of Michael StJohns <msj@nthpermutation.com<mailto:msj@nthpermutation.com>> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key. So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar. Later, Mike _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
David , Olaf, I understand both of your points of view, I think we need a bigger conversation about Algorithm roll, i.e. if that is a good idea and what algorithm to roll to But this conversation can take place in after October 13'th Olafur On Tue, Sep 18, 2018 at 8:29 AM, David Conrad <david.conrad@icann.org> wrote:
Hi,
We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)).
As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023.
However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous.
The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned).
Regards, -drc
On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org> wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ------------------------------ *From:* ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> *Sent:* Tuesday, September 18, 2018 5:04:31 AM *To:* Matt Larson *Cc:* ksk-rollover@icann.org *Subject:* Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Ólafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com
Moin!
On 18. Sep 2018, at 19:13, Ólafur Guðmundsson via ksk-rollover <ksk-rollover@icann.org> wrote:
David , Olaf, I understand both of your points of view, I think we need a bigger conversation about Algorithm roll, i.e. if that is a good idea and what algorithm to roll to
But this conversation can take place in after October 13'th What about starting this conversation at October 13/14 at the DNS-OARC meeting?
I assume a lot of the relevant people will be there and I’m pretty sure we will get some time for it. So long Ralf Sent from my iPhone
Olafur
On Tue, Sep 18, 2018 at 8:29 AM, David Conrad <david.conrad@icann.org> wrote: Hi,
We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)).
As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023.
However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous.
The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned).
Regards, -drc
On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org> wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- Ólafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Ralf Weber writes:
What about starting this conversation at October 13/14 at the DNS-OARC meeting?
I assume a lot of the relevant people will be there and I m pretty sure we will get some time for it.
I definitely expect that we could make time for it. Personally I'm in favour of roughly once per year as the schedule.
On 09/21/2018 06:14 PM, Dave Lawrence wrote:
Ralf Weber writes:
What about starting this conversation at October 13/14 at the DNS-OARC meeting?
I assume a lot of the relevant people will be there and I m pretty sure we will get some time for it.
I definitely expect that we could make time for it.
The OARC Programme Committee has set aside the slot 15:30 to 16:00 CEST on Sat 13th Oct during the OARC29 main workshop in Amsterdam for post-keyroll open discussion. While it's entirely possible any such discussion may spill beyond that programmed (& webcast) slot, we'll do our best to facilitate additional time/space in Amsterdam should folks need that. Keith
Moin! On 25 Sep 2018, at 22:55, Keith Mitchell wrote:
On 09/21/2018 06:14 PM, Dave Lawrence wrote:
Ralf Weber writes:
What about starting this conversation at October 13/14 at the DNS-OARC meeting?
I assume a lot of the relevant people will be there and I m pretty sure we will get some time for it.
I definitely expect that we could make time for it.
The OARC Programme Committee has set aside the slot 15:30 to 16:00 CEST on Sat 13th Oct during the OARC29 main workshop in Amsterdam for post-keyroll open discussion. Thanks a lot for that. Looking forward to the discussion.
So long -Ralf —-- Ralf Weber
Hi, If ICANN would have followed the DPS the key roll had already taken place, in 2015, so it seems to be room for flexibility, and 20203 might not be the perfect time span. That said, it is important to discuss what frequency for rolling keys should be optimal. When .se used to be the trust anchor for dnssec for our part of the internet, we rolled once a year. Generation of a new KSK took place every year in mid December. The validity time for a KSK was two years. This meant that we had two keys that had a validity period that overlapped with one year. The frequency was chosen by the fact that it should not be carried out to often to put a burden on resolver operators and others in the community, but often enough to make sure that the operations team didn't forget how to do it. That was of course before RFC 5011. I agree that a "post mortem" report about the current key rollover will be a good starting point for such discussion. Kind regards, Anne-Marie Eklund Löwinder Chief Information Security Officer IIS (The Internet Infrastructure Foundation) Phone: +46 734 315 310 https://www.iis.se Visitors: Hammarby Kaj 10D Mail: Box 92073, 120 07 Stockholm
-----Ursprungligt meddelande----- Från: ksk-rollover <ksk-rollover-bounces@icann.org> För David Conrad Skickat: den 18 september 2018 17:30 Till: Olaf Kolkman <kolkman@isoc.org> Kopia: KSK Rollover <ksk-rollover@icann.org> Ämne: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
Hi,
We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)).
As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023.
However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous.
The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned).
Regards, -drc
On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org <mailto:kolkman@isoc.org> > wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________
From: ksk-rollover <ksk-rollover-bounces@icann.org <mailto:ksk-rollover-bounces@icann.org> > on behalf of Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com> > Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
All, Happy to save the scheduling discussion 'til after the event. I do like Ralph's idea to talk about it (and the key-roll in general) at OARC, even though I won't make it there myself. :-( (Others from Netnod will, though, and I'll try to participate remotely to some extent.) Cheers, /Liman
Thanks David, I agree… we need a process to change the DPS and agree on frequency - if folk agree that the frequency should increase from the 5year cycle, that is. Having that discussion is important, but not urgent, we should indeed first compile some learnings. —Olaf On 18 Sep 2018, at 23:29, David Conrad wrote:
Hi,
We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)).
As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023.
However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous.
The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned).
Regards, -drc
On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org<mailto:kolkman@isoc.org>> wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. ________________________________ From: ksk-rollover <ksk-rollover-bounces@icann.org<mailto:ksk-rollover-bounces@icann.org>> on behalf of Michael StJohns <msj@nthpermutation.com<mailto:msj@nthpermutation.com>> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
Hi David, Thanks, I strongly agree with your comment about looking toward (but not past) a post mortem (maybe calling it an "After Action Report, AAR," would sound a little less foreboding though). :) I think there will be a lot of moving parts and a lot to measure after the roll. I would, however, suggest that there will be much more to learn than what we see in the “seconds” after the roll (I lost track of where that comment came from, sorry). I think we need to look for measures that could be useful in ascertaining when the operational ecosystem has stabilized. For example, all of the outreach that ICANN org and others have done has taken time. That tells me that there are DNS consumers/stakeholders (including both those we have reached, and those we have not) who may have operational reactions to the roll: changing, turning off DNSSEC, keeping it on (steady state), etc. I think we need to factor these kinds of measurements into decisions about when we can assess the effect of the Root KSK roll. Just my 0.02, Eric
On Sep 18, 2018, at 11:29 AM, David Conrad <david.conrad@icann.org> wrote:
Hi,
We (ICANN org) don’t have an opinion (individual staff members with their ICANN hats off might :)).
As you’re probably aware, currently, the DPS states (paraphrasing) we should roll the KSK after 5 years from the point the KSK is put into use. As such, the next roll is anticipated to be after 11 Oct 2023.
However, as Matt said, we listen to the community. If the community would like us to roll more frequently, all that we in staff need to know is what that frequency is. There are, of course, operational costs associated with the roll, both at ICANN org as well as within the resolver operators community (at least for those folks who prefer to roll manually) that will vary depending on roll frequency, but presumably those costs won’t be too outrageous.
The next step would probably be to figure out how to get a consensus on what the frequency should be. I’d think that a 'post mortem' report about the current rollover would be helpful in informing that consensus. The Board has already task ICANN org with putting together such a post mortem (the analysis Matt mentioned).
Regards, -drc
On Sep 18, 2018, at 3:44 AM, Olaf Kolkman <kolkman@isoc.org <mailto:kolkman@isoc.org>> wrote:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no monthly or once half a decade is a tactic that takes into account some of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
---- Composed on mobile device, with clumsy thumbs and unpredictable autocorrect. From: ksk-rollover <ksk-rollover-bounces@icann.org <mailto:ksk-rollover-bounces@icann.org>> on behalf of Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> Sent: Tuesday, September 18, 2018 5:04:31 AM To: Matt Larson Cc: ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to get through the first rollover and analyze how it goes before we can discuss subsequent rollovers. One can imagine that how the first rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest and opportunity in the roll-over that could catalyze planning for a second roll. This does not - and should not - need to be single threaded. AFAICT, you're going to know most everything you need to know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll now. If your post analysis shows a problem - adapt and overcome and adjust the dates if you need to. It's hard to hit a target if you don't put it on calendar.
Later, Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover> _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
Eric, On Sep 23, 2018, at 1:12 PM, Eric Osterweil <lists@osterweil.net> wrote:
I would, however, suggest that there will be much more to learn than what we see in the “seconds” after the roll
Yes. While there is going to be a DITL collection by DNS-OARC around the KSK rollover, we will continue the ongoing data collection (at least at the root server operated by ICANN).
I think we need to look for measures that could be useful in ascertaining when the operational ecosystem has stabilized.
Part of this will be to establish what resolver behaviors are during the roll, both in terms of proper configuration and improper configuration, and seeing if we can see these signals at the vantage points we have (i.e., the root servers participating in the DITL collection). We’re in the process of identifying those behaviors in the lab for the resolvers we can get our hands on, however if others have already done this, we’d love to hear about it.
For example, all of the outreach that ICANN org and others have done has taken time. That tells me that there are DNS consumers/stakeholders (including both those we have reached, and those we have not) who may have operational reactions to the roll: changing, turning off DNSSEC, keeping it on (steady state), etc. I think we need to factor these kinds of measurements into decisions about when we can assess the effect of the Root KSK roll.
One thought would be to do an “After Action” survey similar to the KSK rollover preparedness survey we’ve already sent out to the contacts of around 16,000+ ASes. Or are you suggesting protocol-level data collection? Regards, -drc
On Sep 17 2018, Michael StJohns stirred the pot with:
At the risk of disturbing the snake in the woodpile - when is the *next* rollover? Or at least when will ICANN take up scheduling it?
Well I wasn't planning on this until 12 October, but if we are going to start talking about future root KSK rollovers now, I would like to ask about algorithm agility. A starter question: which signing algorithms are supported by the current HSMs? -- Chris Thompson Email: cet1@cam.ac.uk
participants (26)
-
ALAIN AINA -
Anne-Marie Eklund-Löwinder -
Ben Lee -
Carlos M. Martinez -
Chris Thompson -
Dave Lawrence -
David Conrad -
David Huberman -
Dmitry Burkov -
Eric Osterweil -
Keith Mitchell -
Lars-Johan Liman -
Marc Blanchet -
Mark Elkins -
Matt Larson -
Michael StJohns -
Olaf Kolkman -
Paul Ebersman -
Paul Hoffman -
Paul Wouters -
Ralf Weber -
Ramanou S. BIAOU -
Ray Bellis -
Stephane Bortzmeyer -
Warren Kumari -
Ólafur Guðmundsson