[org-algorithm-roll] Happy Friday, ORG enthusiasts!

Joe Abley jabley at pir.org
Fri May 29 22:14:01 UTC 2020


Hi all,

We've had lots of subscriptions to this list this week, since I scrambled to deliver those slides at the RIPE dns-wg virtual meeting on Tuesday. Many thanks for showing an interest there, and here.

Suz and I have been busy syncing up with our colleagues at Afilias this week, who in turn have been doing some qualifying lab testing to confirm that there are no obvious show-stoppers with ORG's production signing platform that constrain our options (beyond what we already know, which is that algorithm 13 seems like a target that is out of reach for practical/COVID reasons right now).

To recap some of the contents of the dns-wg talk, we're looking at making some changes to how DNSSEC is deployed in the ORG zone. We building a plan that will accommodate some or all of:

Eliminate SHA-1

- remove DS RRs with digest type 1 from the root zone

- algorithm roll from RSASHA1 (7) to RSASHA256 (8) or ECDSAP256SHA256 (13)

Reduce Response Sizes

- minimise pre-publication of incoming ZSKs

- suppress signature by ZSK over DNSKEY RRSet

- algorithm roll to ECDSAP256SHA256 (13)

Non-Existence Proof (for various reasons)

- transition from NSEC3 to NSEC

As I mentioned earlier in the week, for practical and operational reasons we think the programme for 2020 cannot achieve all of this, so we need to make some practical choices.

>From the comments I've heard already plus some of the testing PIR and Afilias have done, I'm leaning towards something like:

- minimise pre-publication of incoming ZSKs

- suppress signature by ZSK over DNSKEY RRSet

- remove DS RRs with digest type 1 from the root zone

because they are simple fixes, easy to test in advance, easy to roll back and highly unlikely to cause operational problems, and then

- algorithm roll from RSASHA1 (7) to RSASHA256 (8)

aspirationally before the end of 2020. This will leave us without any reliance on SHA-1, which seems like something we could all plausibly call an achievement. The remaining work:

- algorithm roll to ECDSAP256SHA256 (13)

- transition from NSEC3 to NSEC

(perhaps in that order, perhaps not) could follow.

We have a bunch of implementers, operators and researchers on this list already, and perhaps we can imagine that more will follow and will read the archives. Any experiences people can share to help shape this timeline, or research opportunities people can see around any of this, our ears are wide open.

For research opportunities in particular, if there are data collection exercises around this that we can help fund or coordinate, perhaps together with our friends at DNS-OARC, it would be good to hear whether there are parts of this that sound interesting from that perspective.

Lastly, in the continued theme of showing our working we will be talking about this work with familiar-but-updated slides at a couple of upcoming meetings:

- OARConline 32a, 9 June 2020

- vTechDay ICANN68, 22 June 2020

If it helps to talk about any of our work face-to-face, e.g. to whiteboard research ideas or to coordinate anything operational, we are also happy to coordinate some interim zoom meetings. We can surely follow the lead of our colleagues at OARC and in Nambiba and come up with names for such events that are at least as entertaining as theirs.

Regards,


Joe and Suz


More information about the org-algorithm-roll mailing list