On Jun 26, 2026, at 01:26, Joe Abley <[email protected]> wrote: > > On 26 Jun 2026, at 03:08, Paul Hoffman <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
