[DNSOP] Re: An unofficial DNSSEC algorithm testing registry

[Johan Stenstam <[e-mail]>]

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?

>> 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?

>> 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.

>> 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.

>> 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.

>> 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.

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

* there is a formal proposal that we allocate a range of DNSSEC algorithm code points for this

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?

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.

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.

* 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).

Johan