On Jun 26, 2026, at 14:29, Johan Stenstam <[email protected]> wrote: > > Hi Paul, > >>> 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. >> >> Definitely agree. >> >>> Furthermore, the problem is becoming more acute, because we really need to >>> start experimenting with various PQ-safe algorithms >> >> Agree. >> >>> and without an allocated experimental range we will all do code >>> point-squatting at random which certainly doesn’t help with experiments and >>> testing. >> >> Fully disagree. We use 253 with a lead-in three bytes and an completely >> informal registry. > > Ok, fair enough. But that’s only because there *isn’t* an experimental range, > right?
Not only that, no. Given the problems that other groups have had well-documented problems with experimental ranges (code $experimental1 is used for FALCON testing, later FALCON is assigned code $real1, now developers have to guess how long to keep using $experimental1), we think that using 253-with-lead-in is actually better for the community. > >>> 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. >> >> That is one proposal for reducing a constant stream of UDP-whoops-TCP >> sessions. Another proposal that I have heard is resolvers keeping a cached >> list of UDP queries that went to TCP, and just starting on TCP the next >> times. That cache can be timed out every few hours. > > Sounds like we should do more experiments with both, doesn’t it? Yes, definitely. > >>> 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. >> >> True, but this is only valid for ML-DSA. There still seems to be a lot of >> interest in FALCON (897 byte public key, 666 byte signature), even though >> its eventual standardization status as FN-DSA is unclear. For FN-DSA, >> single-signature responses don't fall back to TCP, but NXDOMAIN responses >> that have three signatures do. > > I disagree that this is only valid for ML-DSA, but this is not the time for > debating one algorithm against another. Agree. FWIW, it's not only valid for ML-DSA: there are other signature algorithms that could have the same size properties but other properties that DNSSEC might like. We won't know until there is more grinding experimentation. >>> But it only works if we use distinct code points for different algorithms. >> >> This is true for deploying the real algorithm, but isn't necessary for >> testing. > > That really depends on what you’re testing. I'm not sure what you mean here; please say more. >>> 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. > > No offense, but that’s a kludge. Correct, and I apologize for not being clear. I should have said "Our registry requires a different type of kludgery that we believe is easier to implement now and causes less long-term problems for implementers." > >>> 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. >> >> Quite true. That's why waiting for a draft to be adopted by the DNSOP WG, >> passed through the process, and then getting IANA assignments will delay >> testing that we know is being done now. Our very informal registry is up and >> happening today. > > I agree with Joe’s assessment: this sounds like “the process is complex, > let’s avoid the process”. > > I happen to agree that the process is complex (in the sense of being very > time consuming), but my take is that we should instead then try to fix the > process. That delays the testing by a long time, possibly a year, and a lot of process effort by a lot of people. You might want to do that at the same time we are already doing the needed testing. > We have had repeated discussions about “fast-tracking” drafts that are > sufficiently simple (but relevant). I think this is a perfect example of such > a case: > > * there seem to be quite wide agreement that we need to facilitate more > experimentation with a whole bunch of PQC algorithms and that the current > mechanism (the 253/254 code points) are not sufficient We disagree with that. > > * there is a formal proposal that we allocate a range of DNSSEC algorithm > code points for this Yes. > If no one objects and we all agree that it is a bit urgent, then exactly what > is stopping WG adoption and then a WGLC soon thereafter? That's a question for the WG chairs, the ADs, and the IESG. > > If, on the other hand, this boils down into an endless discussion, then I was > wrong and will have to agree that the process is too complex. I hope you're wrong. I just want to be able to do useful testing while you find out. > > That said, here is a suggestion for a compromise: > > * Let’s start the formal process for allocation of an experimental range of > algorithm code points ASAP. > > * Meanwhile we create an informal registry (like the one Duane and you have > created) for *coordinated* code point squatting at the same range that the > proposal suggests. Please stop using the pejorative word "squatting". Our registry uses an existing code point in the way it was specified long ago. > > * The informal registry should also have a hard latest termination date and > be terminated at the earliest of (formal process complete, hard latest > termination date). We should certainly look at terminating the registry if the formal process completes and the experimental codepoints in that registry become useful. --Paul Hoffman _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
