> On 10 Nov 2025, at 07:10, Philip Homburg <[email protected]> wrote: > >> But those who want to >> put private algorithms to good use will need to be able to tell DS >> records for different private algorithms apart. So I think that >> Mark's proposal does make sense. > > You state this, but don't give an argument why, during an experiment, > this gives the experiment enough benefit that Mark's proposal is worth it. > > Or, if we look at it another way. If only bind9 would support Mark's > proposal, then it is likely that PQC experiments will just use the SHA-256 > hash and don't bother with this draft. > >> It seems we agree on the use-case, but if one wants to test multiple >> PQ algorithms side-by-side, lack of specificity in the DS RR does >> get in the way. > > It gets in the way if one DNSSEC validator that is used in a PQC experiment > tries to validate a zone signed with a different PQC experiment. > > I don't see how that gets in the way.
So you want all experimentation to be done on closed networks an algorithm at a time? >>> This draft changes all of that. Support for SHA-256-PRIVATE would require >>> generic DNSSEC code to understand algorithms 253 and 254 or hacks >>> in the adaptions layer. Neither of which are desirable for an experiment. >> >> I don't agree with the above inference. The draft notes that "hash" >> values for the new codepoints include private algorithm identifiers >> ONLY when the DNSSEC algorithm field is PRIVATEDNS or PRIVATEOID. >> >> https://datatracker.ietf.org/doc/html/draft-andrews-ds-support-for-privat >> e-algorithms-01#section-2 >> >> The digest field of CDS and DS records with digest types other >> than SHA-1 (1), SHA-256 (2), GOST R 34.11-94 (3), SHA-384 (4), >> GOST R 34.11-2012 (5) and SM3 (6) MUST now embed the private >> algorithm identifier before the digest data if the DS algorithm >> field is PRIVATEDNS or PRIVATEOID in the same manner as is done >> for the matching DNSKEY record. >> >> Therefore, implmentations of new codepoints are unaffected, provided >> the PRIVATEDNS and PRIVATEOID DNSSEC algorithms are not implemented. >> And the whole point is that implementations of these need the new >> payload to avoid confusion. So I don't see a problem or burden >> for non-experimental implementations > > There is no point using SHA-256-PRIVATE on the internet for 'normal' > algorithms. So there is absolutely no point in implementing it unless > one wants to use it for the PQC experiments. > > I don't understand what you are trying to say. My point is that this draft > adds too much complexity to participating in PQC experiments. It actually reduces the complexity of the validator. As things stand when you have DS rrset you have to defer the determination of whether you support the algorithm until you have a copy of the DNSKEY rrset. That may involve doing an additional fetch to retrieve the DNSKEY rrset if it is not already cached. Now the latest versions of named does this but this would not be necessary if the DS records contain the private algorithm identifiers. Additionally after retrieving the DNSKEY rrset if the DS refers to a DNSKEY that is NOT in the DNSKEY RRset one has to assume that the child zone is to be treated as “secure” because one cannot, cryptographically, determine that it should be treated as “insecure". This is the difference in behaviour I’m trying to address. Avoiding the fetch above is a bonus which can be done by saying DS for PRIVATE DNSKEYs MUST NOT use DS type that doesn’t support embedding the private key identifier. I’d love to rip out that extra code. Having implemented support of PRIVATE DNSKEYs I actually have an idea where the complexity lies. > If your argument is: please don't participate, leave that to bind9 then > fine. In the past plenty of people have used unbound in this way. And they > would be in for an unpleasant surprise if they find that they also have to > implement SHA-256-PRIVATE in a convoluted way. > >>> In short, this draft fixes real issues with the current specification >>> of DS for algorithms 253 and 254. However, if the main use of those >>> algorithms is expected to be experiments with PQC, then the occasional >>> DNSSEC validation error would not invalidate the experiment. >> >> Well, except that errors would not be "occasional", they'd be >> fundamental barrier to testing of multiple competing proposal that >> include actual validation (not just fake code points that simulate >> the message size, but with resolvers not bothering to validate, >> because only resource impact is under the microscope). > > There is nothing in the current specs that prevent validation. What the > current specs prevent is getting in insecure result when a validator supports > some experimental PQC algorithms but the zone is signed with a different > experimental PQC algoritm. > >> Bottom line, I don't see how this negatively affects implementations >> that are not interested in private codepoints. And it should I >> think help those that are. > > My argument was not about ignoring this draft. That is perfectly possible. > My argument is that this draft makes it harder to participate in PQC > experiments. Actually it makes it easier. You may not see it, but it does. The latest version of named actually has two PRIVATEOID algorithms (RSASHA256 1.2.840.113549.1.1.11 and RSASHA512 1.2.840.113549.1.1.13 (yes those are the OIDs for those algorithms)) which where used to test the implementation and to provide examples of how to implement private DNSKEYs. Mark > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
