Seeing the monthly reminder of my mailing list membership. (mailman needed to randomize the chosen reminder date) Anyone done any experiments with signed root using some of the NIST candidates? RFC8806 keeps looking better and better to me. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
On Thu, 1 Sep 2022, Michael Richardson via ksk-rollover wrote:
Subject: [ksk-rollover] will there be another keyrollover?
It's complicated? (but I'm not icann/iana so can't say :)
Anyone done any experiments with signed root using some of the NIST candidates? RFC8806 keeps looking better and better to me.
How does 8806 relate to this? do you mean signed root as in KSK/ZSK? Or do you mean the signing of the local root zone transfer (eg ZONEMD?) This message is on the ksk-rollover, I assue you mean the first, but 8806 isn't about that? Paul
Paul Wouters via ksk-rollover <ksk-rollover@icann.org> wrote: >> Anyone done any experiments with signed root using some of the NIST >> candidates? RFC8806 keeps looking better and better to me. > How does 8806 relate to this? do you mean signed root as in KSK/ZSK? > Or do you mean the signing of the local root zone transfer (eg ZONEMD?) > This message is on the ksk-rollover, I assue you mean the first, but > 8806 isn't about that? I mean, if the signed zone is loaded from disk, and rarely actually transfered over the network, then maybe having huge-sized signatures (which some NIST candidates feature) isn't so much a problem. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
On Sep 1, 2022, at 21:10, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
I mean, if the signed zone is loaded from disk, and rarely actually transfered over the network, then maybe having huge-sized signatures (which some NIST candidates feature) isn't so much a problem.
You are talking post quantum algorithms ? The ones that aren’t chosen yet by NIST, aren’t specified in RFCs and aren’t implemented in any software and aren’t deployed anywhere in resolvers ? I think maybe the root should first roll to like algo 13 or something similar where there is operational experience. Paul
Paul Wouters <paul@nohats.ca> wrote: >> I mean, if the signed zone is loaded from disk, and rarely actually >> transfered over the network, then maybe having huge-sized signatures >> (which some NIST candidates feature) isn't so much a problem. > You are talking post quantum algorithms ? The ones that aren’t chosen > yet by NIST, aren’t specified in RFCs and aren’t implemented in any > software and aren’t deployed anywhere in resolvers ? Yes... has anyone done an *experiment* here? I am not suggesting we do it tomorrow, but rather that we know what might be involved. As I said: what if the root zone, being signed, no longer needed to do queries, because every recursive had a copy. > I think maybe the root should first roll to like algo 13 or something > similar where there is operational experience. That's also worth considering, and I said last time that doing it more often means more operational practice. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
On 9/1/2022 11:44 PM, Michael Richardson via ksk-rollover wrote:
Yes... has anyone done an *experiment* here? I am not suggesting we do it tomorrow, but rather that we know what might be involved. As I said: what if the root zone, being signed, no longer needed to do queries, because every recursive had a copy.
If we assume we're planning for 2032, then the above might be possible. I wouldn't assume this is a quick fix in any way shape or form. Of course, the quantum apocalypse might trigger a scramble to do just this. But that still begs the question of all of the subsidiary zones being QR signed along with the algorithms to do so. Later, Mike
Hi Michael, Hi all, In brief, we have two separate initiatives: 1. Performing a conventional rollover (i.e. no algorithm change), as we did in 2018. 2. Studying what is involved in doing an algorithm rollover Both initiatives we'd intended to kick off in 2020 but have been frozen due to the pandemic, which resulted in a mandate to limit operations to core essentials, and also gave us a lack of confidence we could get the right level of community participation. On the conventional rollover, since we've now been able to _mostly_ return to normal KSK operations in recent months we do think we are able to plan out the next rollover with more certainty. We are seeking full community participation for the next KSK rollover, particularly for the key generation ceremony which is relatively early in the process. That planning work is underway. For the algorithm rollover we are developing a project that will involve studying what is involved and coming up with a set of requirements that IANA would need to operationalize. It is expected this work will be conducted in a similar matter to the design team that created requirements for the original rollover. We are aiming to kick this project off at what is being dubbed the "IANA community day" adjacent to the ICANN DNS Symposium (see https://www.icann.org/ids) in mid-November. kim On 1/9/2022, 12:42 pm, "ksk-rollover on behalf of Michael Richardson via ksk-rollover" <ksk-rollover-bounces@icann.org on behalf of ksk-rollover@icann.org> wrote: Seeing the monthly reminder of my mailing list membership. (mailman needed to randomize the chosen reminder date) Anyone done any experiments with signed root using some of the NIST candidates? RFC8806 keeps looking better and better to me. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
participants (4)
-
Kim Davies -
Michael Richardson -
Michael StJohns -
Paul Wouters