On Sat, Nov 08, 2025 at 05:16:39PM +0100, Philip Homburg wrote:
> TLDR: it increases complexity for too little gain
>
> RFC 4034 reserves two algorithms for private use (253 and 254). I have no
> desire to support private algorithms, and I think most people agree because
> since the publication of RFC in March 2005, these features have seen
> hardly any use. It is telling that the draft to fix the DS issue comes
> 20 years later. The obvious thing to do is to mark this feature as
> deprecated and move on.
Well, a plausible reason we haven't seen much use of private algorithms
till now is that very little experimental cryptography has been relevant
to DNSSEC. (GOST aside) The noval algorithms investigated for inclusion
were already mainstream cryptography, and were clearly going to see some
mainstream adoption eventually.
- 8 and 10 (RSA with SHA-2)
- 13 and 14 (P256, P384)
- 15 and 16 (EdDSA and Ed448, though resolver support for the latter
is far from comprehensive).
What we're facing now is I think different in kind. The PQ algorithm
pipeline is giving us very "fresh" cryptography, that may not stand the
test of time, or may prove to be a poor fit for DNSSEC. Testing is
needed, including being able to test multiple algorithm codepoints in
the same stack. So having at most two private algorithms that a domain
can be signed with makes it harder to pilot these algorithms.
Those who prefer to not support private algorithms don't can simply
ignore the new records. It costs nothing. 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.
> There is however the issue of experimenting with PQC algorithms and assigning
> code points to those algorithms. Algorithms 253 and 254 seem in an ideal
> position to support those experiments. Note the word 'experiments'.
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.
> 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-private-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
> 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).
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.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
