A new validator implementation could unilaterally impose that rule, sure. But ideally, there should be some general rule for algorithm downgrade resistance that is signaled in the protocol, rather than special casing a rule only for a specific algorithm.
Shumon. On Mon, Jul 27, 2026 at 8:42 AM Bas Westerbaan <[email protected]> wrote: > Why do we need the signal: what goes wrong if some validators insist on > ML-DSA-44 if they see a ML-DSA-44 DS? > > > On Mon, Jul 27, 2026 at 2:41 PM Shumon Huque <[email protected]> wrote: > >> On Mon, Jul 27, 2026 at 8:16 AM Bas Westerbaan <[email protected]> >> wrote: >> >>> >>> On Mon, Jul 27, 2026 at 2:09 PM Shumon Huque <[email protected]> wrote: >>> >>>> [...] additional explicit signaling is likely needed for that, and it >>>> would be a painful slog to get the long tail of validators in the field >>>> upgraded to implement such an enhancement. >>>> >>> >>> What signalling would be required for the validator to insist on >>> ML-DSA-44 if it sees a DS for it? >>> >> >> We'd have to come up with a design. Most likely the signal would have to >> be encoded in the DS RRset (see the various "DS hack" proposals for various >> things in the past), or in a DNSKEY flag. (If we wait for DELEG, which may >> be too late, then a purpose built DELEG parameter could be designed). >> >> Shumon. >> >>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
