On Mar 27, 2025, at 08:56, Petr Špaček <pspa...@isc.org> wrote: > > On 3/21/25 12:41, Paul Hoffman wrote: >> On Mar 21, 2025, at 15:40, Paul Wouters <p...@nohats.ca> wrote: >>> This is a one octet registry. This specific registry was mentioned by me a >>> few times as one of the problem ones where a very lose registration policy >>> mifgt not well suited for allocation for early drafts or code points. >>> >>> DNS itself also has a very long tail (decade) so in the past, algorithms >>> have been controlled fairly strictly to avoid large amounts of mostly dead >>> code. >>> >>> It might make sense to instead update the registry to allocate 5 private >>> use code points and use those for the various experiments. >> The registry has over 200 unused code points. Even if we assume that a >> massive signature comparison effort happens every 20 years, we can easily >> afford to burn 20 per effort. RFC 6014 hinted at this. > > Well maybe. But there are also proposals to partially use algo-number as a > bit-field - e.g. for DRY RUN DNSSEC protocol extension.
Which do you feel is more important: testing lots of new signature algorithms, or dry run as is initially proposed? > See below for more flexible approach. > >> Please remember that, if we get anywhere close to running out of code points >> in this registry, it is trivial to extend the registry. 100 years from now, >> when we are all dead, someone can define a new signature algorithm whose >> first two bytes of the digest are codepoints in another registry that has a >> more sensible length than what we gave to this one. >> I propose that someone who is already working on testing many algorithms >> (such as Ondřej) create a short Internet Draft that is little more than a >> table whose columns are: >> - algorithm name >> - a number starting at 50 >> - stable reference to the algorithm >> Those interested in PQC algorithms bounce that draft around on the >> pq-dns...@ietf.org mailing list (not here on DNSOP) for a few months, then >> ask the ISE to publish it. Any algorithm that did not make the list in the >> draft can write its own draft for later RFC publication. > > FTR there's also possibility to use OID and DNS names as algorithm > identifier. See algo numbers 253, 254, RFC 4034 appendix A.1.1. Every time this mechanism comes up, it is dismissed as being too hard to implement. > It would be nice if we exercised this extensibility as it gives us > practically unlimited space. When we have fewer available, maybe. But for now, we have a huge number available and a real need to do research on which signature algorithms will be best for us. I propose that we use the code points the way they were supposed to be used: in the protocol. --Paul Hoffman _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
