> On 12 Nov 2025, at 19:12, Philip Homburg <[email protected]> wrote: > > In your letter dated Tue, 11 Nov 2025 19:21:17 +0000 you wrote: >> And, if there are two DS records for the same key, one with each of the old >> and new hash code points, then an older validator would use the old hash >> format, and behave exactly as it does now. Meaning, if the validator has no >> PRIVATE* support, it would fail to recognize the DNSKEY algorithm 253 >> or 254, so that delegation would also be treated as insecure. >> >> The only tricky case is a validator that knows about PRIVATE* but >> doesn't know the new hash code points. > > I don't think this solves the problem that this draft tries to solve (unless > the draft adds some extra text). > > 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 doesn’t happen. e.g. pre-publishing DS records and error conditions. It isn’t whether you support the algorithm or not. It’s not being able to identify the algorithm. The current draft has: It is RECOMMENDED that only DS records with DS digest types that embed the private DNSSEC algorithm are used with private DNSSEC algorithms as allows for publishing of DS records without the corresponding DNSKEY record being published. We could add words to say that DS types that do not embed the private algorithm identifier MUST NOT be used with PRIVATEDNS or PRIVATEOID DNSKEYs and MUST be ignored if present. However none of this is relevant to whether or not to adopt the draft. There is also the setting of MAY/RECOMMENDED/MUST/MUST NOT to fill out the table here for the new code points. https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 IANA wants more guidance. My suggestion is to mirror the recommendations for types they are augmenting. Mark > So the draft would have to say that any validator that supports > SHA-256-PRIVATE > has to treat DS records that use SHA-256 and algorithm PRIVATE* as insecure. > Possible, but is that going to make anybody happy? > > _______________________________________________ > 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]
