> On 14 Nov 2025, at 02:11, Philip Homburg <[email protected]> wrote:
> 
>>> If a validator that implements this draft encounters a DS RRset
>>> that use both SHA-256 and SHA-256-PRIVATE and it does not support the
>>> algorithm used in the DS records with SHA-256-PRIVATE then it will continue
>>> trying to validate using the DS record that uses SHA-256. And we are back
>>> to square one.
>> 
>> The problem that the draft is addressing is that the existing DS
>> records do not fully identify the DNSSEC algorithm in the DNSKEY.
>> If the matching DNSKEY is available this is not an issue as you
>> can match the tag, then check the hash and if that matches that
>> give you the algorithm by looking at the start of the DNSKEY.
>> Where the problem is where that doesnt happen.  e.g. pre-publishing
>> DS records and error conditions.
> 
> Maybe we have a completely different view on what the PRIVATE* algorithms
> are supposed to be used for.
> 
> For me the only sensible use of PRIVATE* is to experiment with PQC algorithms.
> Once we have found a few algorithms that would work well in production (i.e.,
> they are considered secure from a crypto perspective and they are fine from
> an operational point of view), those algorithms can get there own code
> points and PRIVATE* is no longer needed.
> 
> There is absolutely no need to pre-publish DS records for such an experiment.
> I would say the opposite, for a KSK such an experiment should focus on
> double signature KSK rolls because that results in larger DNSKEY RRsets.
> 
> Maybe you have a different use-case in mind?

I want private DNSSEC algorithms to work as well as any otherDNSSEC  algorithm.
It doesn’t matter what my use case is or even if I have one.  I want the code
points to work for anyone in the world that wants to use them for whatever use
case they have.  They did before DS was invented.  They currently do not do this
because we stuffed up when we designed the DS record.  I asked at the time if
the identifier needed to be embedded in the hash field and was told “no, its not
needed".  Obviously that was a mistake.

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

Reply via email to