> 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. > > 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. 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. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
