[DNSOP] Re: [Ext] Re: Sanity tl;dr for Multi-algorit hm DNSSEC Requirements

--===============7384168828475459329==
Content-Type: multipart/alternative; boundary="0000000000009ba1cf065798034a"

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

On Mon, Jul 27, 2026 at 9:07=E2=80=AFAM Paul Hoffman <[email protected]=
g> wrote:

> On Jul 27, 2026, at 05:51, Shumon Huque <[email protected]> wrote:
> >
> > A new validator implementation could unilaterally impose that rule, sur=
e.
>
> And it might. That would require that the validator had such a knob in it=
s
> config, and would be implementation-specific.
>
> > 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.
>
> THERE BE DRAGONS!
>
> It is probably fine to have a signal that says "do not downgrade from {se=
t
> of PQ algorithms} to {set of classical algorithms}, but a signal that say=
s
> 'do not downgrade from {PQ alg 1} to {PQ alg 2} is inherently dangerous
> because if alg 1 becomes weakened by a later attack, you have just create=
d
> a signal that basically forces a downgrade.
>

Yes, I agree. I would not propose per algorithm rules. So, some options
might be: (1) All algorithm signatures must validate, (2) PQ algorithms
can't be downgraded, (3) both PQ and Classical algorithms must validate.

Shumon.

--0000000000009ba1cf065798034a
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:07=E2=80=AFAM P=
aul Hoffman &lt;<a href=3D"mailto:[email protected]">paul.hoffman@ican=
n.org</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">On Jul 27, 2026, at 05:51=
, Shumon Huque &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">sh=
[email protected]</a>&gt; wrote:<br>
&gt; <br>
&gt; A new validator implementation could unilaterally impose that rule, su=
re.<br>
<br>
And it might. That would require that the validator had such a knob in its =
config, and would be implementation-specific.<br>
<br>
&gt; 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.<br>
<br>
THERE BE DRAGONS!<br>
<br>
It is probably fine to have a signal that says &quot;do not downgrade from =
{set of PQ algorithms} to {set of classical algorithms}, but a signal that =
says &#39;do not downgrade from {PQ alg 1} to {PQ alg 2} is inherently dang=
erous because if alg 1 becomes weakened by a later attack, you have just cr=
eated a signal that basically forces a downgrade.<br></blockquote><div><br>=
</div><div>Yes, I agree. I would not propose per algorithm rules. So, some =
options might be: (1) All algorithm signatures must validate, (2) PQ algori=
thms can&#39;t be downgraded, (3) both PQ and Classical algorithms must val=
idate.</div><div><br></div><div>Shumon.</div><br></div></div>

--0000000000009ba1cf065798034a--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============7384168828475459329==--