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

--===============0647509494634998788==
Content-Type: multipart/alternative; boundary="000000000000e097730657981419"

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

And how should that signal be interpreted if only the classical signature
on it could be validated?

On Mon, Jul 27, 2026 at 3:51=E2=80=AFPM Shumon Huque <[email protected]> wro=
te:

> On Mon, Jul 27, 2026 at 9:07=E2=80=AFAM Paul Hoffman <paul.hoffman@icann.=
org>
> wrote:
>
>> On Jul 27, 2026, at 05:51, Shumon Huque <[email protected]> wrote:
>> >
>> > A new validator implementation could unilaterally impose that rule,
>> sure.
>>
>> And it might. That would require that the validator had such a knob in
>> its 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
>> {set of PQ algorithms} to {set of classical algorithms}, but a signal th=
at
>> says '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 created 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.
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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

<div dir=3D"ltr">And how should that signal be interpreted if only the clas=
sical signature on it could be validated?</div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul =
27, 2026 at 3:51=E2=80=AFPM Shumon Huque &lt;<a href=3D"mailto:shuque@gmail=
.com">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 27, 202=
6 at 9:07=E2=80=AFAM Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@icann.=
org" target=3D"_blank">[email protected]</a>&gt; wrote:</div><div clas=
s=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">On Jul =
27, 2026, at 05:51, Shumon Huque &lt;<a href=3D"mailto:[email protected]" ta=
rget=3D"_blank">[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>
_______________________________________________<br>
DNSOP mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">d=
[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar=
get=3D"_blank">[email protected]</a><br>
</blockquote></div>

--000000000000e097730657981419--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============0647509494634998788==--