[DNSOP] Re: Sanity tl;dr for Multi-algorithm DNSSEC Requir ements
Shumon Huque <[email protected]> Mon, 27 Jul 2026 08:51:45 -0400
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CAHPuVdWBOSUJ_9pkqreQnFGcrUx+LfPr4UjOBqOLs1_QtYQ8Mg@mail.gmail.com> |
--===============8539209173753955150== Content-Type: multipart/alternative; boundary="0000000000001041eb065797308c" --0000000000001041eb065797308c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM 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=E2=80=AFPM Shumon Huque <[email protected]> w= rote: > >> On Mon, Jul 27, 2026 at 8:16=E2=80=AFAM Bas Westerbaan <[email protected]= om> >> 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 fiel= d >>>> 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 vari= ous >> things in the past), or in a DNSKEY flag. (If we wait for DELEG, which m= ay >> be too late, then a purpose built DELEG parameter could be designed). >> >> Shumon. >> >> --0000000000001041eb065797308c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>A new validator implementation could unilaterally imp= ose that rule, sure.</div><div><br></div><div>But ideally, there should be = some general rule for algorithm downgrade resistance that is signaled in th= e protocol, rather than special casing a rule only for a specific algorithm= .</div><div><br></div><div>Shumon.</div><br><div class=3D"gmail_quote gmail= _quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27, 202= 6 at 8:42=E2=80=AFAM Bas Westerbaan <<a href=3D"mailto:[email protected]= m">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Why do we need the s= ignal: what goes wrong 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_quot= e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27, 2026 at 2:41=E2=80= =AFPM Shumon Huque <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 27, 2026 at= 8:16=E2=80=AFAM Bas Westerbaan <<a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a>> wrote:</div><div class=3D"gmail= _quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px 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" clas= s=3D"gmail_attr">On Mon, Jul 27, 2026 at 2:09=E2=80=AFPM Shumon Huque <<= a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d= ir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transparent">[.= ..] additional explicit signaling is likely needed for that, and it would b= e a painful slog to get the long tail of validators in the field upgraded t= o implement such an enhancement.</span></div></div></blockquote><div><br></= div><div>What signalling would be=C2=A0required=C2=A0for the validator to i= nsist on ML-DSA-44 if it sees a DS for it?</div></div></div></blockquote><d= iv><br></div><div>We'd have to come up with a design. Most likely the s= ignal would have to be encoded in the DS RRset (see the various "DS ha= ck" proposals for various things in the past), or in a DNSKEY flag. (I= f we wait for DELEG,=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> </blockquote></div></div> --0000000000001041eb065797308c-- --===============8539209173753955150== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============8539209173753955150==--