Hi,
The problem that the only “experimental use” DNSSEC algorithms are the multiplexed 253+254 code points that have unique constraints on how they can be used has been discussed repeatedly. And the problem simply doesn’t go away. Furthermore, the problem is becoming more acute, because we really need to start experimenting with various PQ-safe algorithms and without an allocated experimental range we will all do code point-squatting at random which certainly doesn’t help with experiments and testing. In addition to that there are a couple of other reasons why this is becoming important. One rather promising idea that has come out of the various PQ-DNSSEC experiments that we’re doing right now is using the algorithm number in the parent-side DS RRset as a signal (to the validator) that the DNSKEY RRset is likely to be large and that querying for the DNSKEY RRset over UDP should not even be attempted. Example: if the alg number in the DS represents ML-DSA-44 (~1300 byte public key + ~2.5 KB signature), then a validator that understands which algorithm numbers represent “large” DNSKEY RRsets can avoid the costly UDP roundtrip. And as queries for DNSKEYs are likely < 0.1% of all queries in most cases, the PQ packet size problem has suddenly shrunk. But it only works if we use distinct code points for different algorithms. 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). AFAIK no one is implementing tests and experiments with algorithms that do not have official IANA codepoints via the 253/254 special hacks. Everyone is doing random squatting instead -- at exactly the time when we should be making testing and experimentation as easy as possible, given the shrinking window we have to get PQ-safe. Hence this very short draft. Johan Stenstam
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
