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

--===============4259672915369616917==
Content-Type: multipart/alternative; boundary="000000000000665bc80657982347"

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

On Mon, Jul 27, 2026 at 9:23=E2=80=AFAM Bas Westerbaan <[email protected]>=
 wrote:

>
>
> On Mon, Jul 27, 2026 at 2:52=E2=80=AFPM Shumon Huque <[email protected]> w=
rote:
>
>> 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 a=
nd
> 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 ar=
e
> equipreferable.
>

I think there is still an assumption in the DNSSEC specs that local
validator policy always wins. I sense your suggestion is along those lines.

To date, the general rules in the current DNSSEC specs are designed to
maximize interoperability and not rely on individual resolver operators to
make their own determinations about things like this. multi-alg-rules is
already skirting this by proposing universal algorithms.

Determining confidence in or strength of algorithms and acting selectively
on it is another topic, which has had some heated discussions in DNSSEC in
the past.

Shumon.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 27, 2026 at 9:23=E2=80=AFAM B=
as Westerbaan &lt;<a href=3D"mailto:[email protected]">[email protected]<=
/a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt=
r"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Jul 27, 2026 at 2:52=E2=80=AFPM Shumon Huque &lt;<a href=3D"=
mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div>A new validator implementation could unilaterally impose that rule, s=
ure.</div><div><br></div><div>But ideally, there should be some general rul=
e for algorithm downgrade resistance that is signaled in the protocol,</div=
></div></blockquote><div><br></div><div>We can write a more general rule fo=
r sure [1], but why does the authoritative need to signal it (besides the e=
xistence of the DS itself)? If there is no clear use case, we shouldn&#39;t=
 do it: if we keep it simpler it&#39;s easier to reason about the security.=
</div><div><br></div><div>Best,</div><div><br></div><div>=C2=A0Bas</div><di=
v><br></div><div><br></div><div>[1]=C2=A0 A validator should insist on a si=
gnature with algorithm A if the availability of A is signalled by the exist=
ence 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&#39;s not on=
e preferred, but a couple are equipreferable.</div></div></div></blockquote=
><div><br></div><div>I think there is still an assumption in the DNSSEC spe=
cs that local validator policy always wins. I sense your suggestion is alon=
g those lines.</div><div><br></div><div>To date, the general rules in the c=
urrent DNSSEC specs are designed to maximize interoperability and not rely =
on individual resolver operators to make their own determinations about thi=
ngs like this. multi-alg-rules is already skirting this by proposing univer=
sal algorithms.</div><div><br></div><div>Determining confidence in or stren=
gth of algorithms and acting selectively on it is another topic, which has =
had some heated discussions in DNSSEC in the past.</div><div><br></div><div=
>Shumon.</div><div><br></div></div></div>

--000000000000665bc80657982347--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============4259672915369616917==--