[DNSOP] Re: Sanity tl;dr for Multi-algorithm DNSSEC Requir ements

--===============6312487815074074046==
Content-Type: multipart/alternative; boundary="0000000000007604ac0657970fa0"

--0000000000007604ac0657970fa0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Shumon Huque <[email protected]> wro=
te:

> On Mon, Jul 27, 2026 at 8:16=E2=80=AFAM Bas Westerbaan <[email protected]=
m> wrote:
>
>>
>> On Mon, Jul 27, 2026 at 2:09=E2=80=AFPM 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 vario=
us
> things in the past), or in a DNSKEY flag. (If we wait for DELEG, which ma=
y
> be too late, then a purpose built DELEG parameter could be designed).
>
> Shumon.
>
>

--0000000000007604ac0657970fa0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Why do we need the signal: what goes wron=
g if some validators insist on ML-DSA-44 if they see a ML-DSA-44 DS?</div><=
div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote gmail_quote_contain=
er"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27, 2026 at 2:41=E2=
=80=AFPM Shumon Huque &lt;<a href=3D"mailto:[email protected]">shuque@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 27, 2026 at 8:16=E2=80=AFA=
M Bas Westerbaan &lt;<a href=3D"mailto:[email protected]" target=3D"_blank=
">[email protected]</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr=
"><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Jul 27, 2026 at 2:09=E2=80=AFPM Shumon Huque &lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
 dir=3D"ltr"><span style=3D"background-color:transparent">[...] additional =
explicit signaling is likely needed for that, and it would be a painful slo=
g to get the long tail of validators in the field upgraded to implement suc=
h an enhancement.</span></div></div></blockquote><div><br></div><div>What s=
ignalling would be=C2=A0required=C2=A0for the validator to insist on ML-DSA=
-44 if it sees a DS for it?</div></div></div></blockquote><div><br></div><d=
iv>We&#39;d have to come up with a design. Most likely the signal would hav=
e to be encoded in the DS RRset (see the various &quot;DS hack&quot; propos=
als for various things in the past), or in a DNSKEY flag. (If we wait for D=
ELEG,=C2=A0which=C2=A0may be too late, then a purpose built DELEG parameter=
 could be designed).</div><div><br></div><div>Shumon.</div><div><br></div><=
/div></div>
</blockquote></div></div>

--0000000000007604ac0657970fa0--


--===============6312487815074074046==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============6312487815074074046==--