On Mon, Jul 27, 2026 at 2:52 PM Shumon Huque <[email protected]> wrote:
> 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, > We can write a more general rule for sure [1], but why does the authoritative need to signal it (besides the existence of the DS itself)? If there is no clear use case, we shouldn't do it: if we keep it simpler it's easier to reason about the security. Best, Bas [1] A validator should insist on a signature with algorithm A if the availability of A is signalled by the existence of the corresponding DS and A has more confidence in the security of A than the other available algorithms. We can do the same if it's not one preferred, but a couple are equipreferable. > 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]
