[DNSOP] Re: Sanity tl;dr for Multi-algorithm DNSSEC Requir ements
Bas Westerbaan <[email protected]> Mon, 27 Jul 2026 15:23:15 +0200
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CAMjbhoUgB7X=F0mKbaOkDif+CcivqFNVNWROM1dJgv_iZHYjHA@mail.gmail.com> |
--===============0946845684083013268== Content-Type: multipart/alternative; boundary="0000000000009c09c6065797a01d" --0000000000009c09c6065797a01d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2026 at 2:52=E2=80=AFPM Shumon Huque <[email protected]> wro= te: > 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=E2=80=AFAM Bas Westerbaan <[email protected]= m> 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]> = wrote: >> >>> On Mon, Jul 27, 2026 at 8:16=E2=80=AFAM Bas Westerbaan <bas@cloudflare.= com> >>> 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 fie= ld >>>>> 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 t= o >>> be encoded in the DS RRset (see the various "DS hack" proposals for var= ious >>> 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. >>> >>> --0000000000009c09c6065797a01d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27,= 2026 at 2:52=E2=80=AFPM Shumon Huque <<a href=3D"mailto:[email protected]= m">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"><div dir=3D"ltr"><div>A new validator implementation cou= ld unilaterally impose that rule, sure.</div><div><br></div><div>But ideall= y, there should be some general rule for algorithm downgrade resistance tha= t is signaled in the protocol,</div></div></blockquote><div><br></div><div>= We can write a more general rule for sure [1], but why does the authoritati= ve 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 e= asier to reason about the security.</div><div><br></div><div>Best,</div><di= v><br></div><div>=C2=A0Bas</div><div><br></div><div><br></div><div>[1]=C2= =A0 A validator should insist on a signature with algorithm A if the availa= bility 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 equipref= erable.<span style=3D"background-color:transparent"></span></div><div><span= style=3D"background-color:transparent"><br></span></div><div><span style= =3D"background-color:transparent">=C2=A0</span></div><blockquote class=3D"g= mail_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> rather than special casi= ng a rule only for a specific algorithm.</div><div><br></div><div>Shumon.</= div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On= Mon, Jul 27, 2026 at 8:42=E2=80=AFAM Bas Westerbaan <<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;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d= iv dir=3D"ltr">Why do we need the signal: what goes wrong if some validator= s 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"><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></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-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 h= ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&= gt; 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" class=3D"gmail_attr">On Mon, Jul 27, 2026 at= 2:09=E2=80=AFPM Shumon Huque <<a href=3D"mailto:[email protected]" targe= t=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(20= 4,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><span style= =3D"background-color:transparent">[...] additional explicit signaling is li= kely needed for that, and it would be a painful slog to get the long tail o= f validators in the field upgraded to implement such an enhancement.</span>= </div></div></blockquote><div><br></div><div>What signalling would be=C2=A0= required=C2=A0for the validator to insist on ML-DSA-44 if it sees a DS for = it?</div></div></div></blockquote><div><br></div><div>We'd have to come= up with a design. Most likely the signal would have to be encoded in the D= S RRset (see the various "DS hack" proposals for various things i= n the past), or in a DNSKEY flag. (If we wait for DELEG,=C2=A0which=C2=A0ma= y be too late, then a purpose built DELEG parameter could be designed).</di= v><div><br></div><div>Shumon.</div><div><br></div></div></div> </blockquote></div></div> </blockquote></div></div> </blockquote></div></div> --0000000000009c09c6065797a01d-- --===============0946845684083013268== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============0946845684083013268==--