[DNSOP] Re: [Ext] An unofficial DNSSEC algorithm testing registry

[Tim Wicinski <[e-mail]>]

All


I am all for hacky ideas, and I think this one is oK.   I would suggest
putting a beginning date into the list and maybe later folks can say "is 18
months enough time for MAYO-512-MEOW ?"

Because you want to test them, and keep the ones that are liked and make
them into Real Code Points (tm).

I do agree with Joe on "If it's too hard to create a registry or to add
code-points to a registry we should find imaginative ways to solve those
problems"

But I think the problem with updating the IANA registry is removing it from
an IANA registry, even private/reserved things.


tim



On Fri, Jun 26, 2026 at 10:19 AM Paul Hoffman <[e-mail]>
wrote:

> On Jun 26, 2026, at 01:26, Joe Abley <[e-mail]> wrote:
> >
> > On 26 Jun 2026, at 03:08, Paul Hoffman <[e-mail]> wrote:
> >
> >>> \It is also one thing to experiment with a single new algorithm (and
> then use 253 or 254). But in the PQ space there are *many* algorithms. In
> our name servers we currently do testing with 15 different algorithms (4 *
> MAYO, 2 * FALCON, 3 * SNOVA, 3 * ML-DSA, SQISIGN, SLH-DSA-128s and one of
> the QR-UOV algs). The amount of kludgery that would need to be added to the
> code by not knowing what algorithm it is until the DNSKEY has been fetched,
> an identifier string has been extracted from the public key and mapped
> against the algorithms that the code even knows how to use is not
> reasonable. So we do code point squatting instead, which makes
> collaboration with others much more difficult (see above).
> >>
> >> Our registry requires no such kludgery. You look at the first three
> bytes of the DNSKEY or RRSIG: if the first byte is 0x01, and the third is
> 0x00, you know it might be in the unofficial registry.
> >
> > I need to look harder at both proposals, but what you write above just
> seems like a different kind of kludgery.
>
> Correct. Duane and I proposed a kludge that takes a lot less effort for
> DNSOP (and thus the rest of the IETF), one that we believe will cause less
> downstream damage (when the community picks a final algorithm and now it
> would have two codepoints), and that likely adds just one more if-tree to
> implementations that are being used for experimentation.
>
> > I am not against kludges, and I appreciate pragmatism in all its varied
> and admirable forms, but this does have the aroma of "the process is too
> hard, let's avoid the process".
>
> That is definitely a fair assessment, but we live in a world where the
> people in charge of the process are exceptionally conservative with code
> points.
>
> > There ought to be no reason why creating a new registry for a purpose
> that has a ticking countdown clock cannot be expedited.
>
> And yet here we are. But even if that new registry could be created, you
> will later be confronted with the issue of having at least two code points
> (the one in the experimental range, and the one in the real range). The
> IPsec community had a massive problem with this 30 years ago.
>
> > If it's too hard to create a registry or to add code-points to a
> registry we should find imaginative ways to solve those problems. I think
> using that energy to avoid the problems instead of solving them doesn't do
> much to help the next person\.
> >
> > Note again, I am not arguing about your specific proposal, here. This is
> a more general opinion.
>
> Duane and I chose an explicitly path that makes testing easy, and makes
> switching off of testing easy. Informal paths that cannot later turn into
> formal paths seem to work well.
>
> --Paul Hoffman
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>