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

--===============2666493139596810567==
Content-Type: multipart/alternative; boundary="000000000000abc229065794a551"

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

The draft as-is goes in the wrong direction for a downgrade-secure PQ
DNSSEC deployment. To be fair, that is not one of the stated goals of the
draft: it only mentions experimentation with PQC. Also Johan is talking
about the future where we want to partially move from ML-DSA-44 to
something smaller but less secure. Still, good to talk about what this
means for ML-DSA-44.


Say we have a zone fully signed with both algorithm 13 and ML-DSA-44. Today
validators SHOULD [1] accept any path. Thus an attacker can strip the
ML-DSA signatures, and successfully downgrade such a lenient validator even
if it supports ML-DSA-44.

To solve this PQ validators should insist on an ML-DSA-44 path, if it sees
an ML-DSA-44 DS.

draft-huque-dnsop-multi-alg-rules-08 goes in the opposite direction.
Quoting section 3.3

   1.  When the DS RRset or trust anchor set for a zone includes an
       unsupported UNIVERSAL or FORMERLY-UNIVERSAL algorithm, validators
       MUST treat the zone as unsigned, even if the DS RRset or trust
       anchor set lists another supported algorithm.

   2.  Otherwise, validators MUST accept any valid path.

As explained above 2 is not what we want for secure PQ deployment. What
about 1?

I am not sure whether "unsupported" is meant to apply to
FORMERLY-UNIVERSAL. If it does, then a validator can just keep supporting
all algorithms and this clause is never triggered. So suppose it's not. The
intended example of FORMERLY-UNIVERSAL are algorithms 8 and 13 some point
in the future. Thus dual signing a zone with either and ML-DSA-44 will
cause validators to mark the zone as unsigned: not what I think we would
want.

On Mon, Jul 27, 2026 at 7:55=E2=80=AFAM Joe Abley <jabley=3D
[email protected]> wrote:

> Perhaps even just
>
>   (RSASHA256, ML-DSA-44)
>   (ECDSAP256SHA256, ML-DSA-44)
>
> would be enough.


I think Mark is talking about a PQ/PQ pair, where the DNSKEY and RRSIG only
contains one of the two, for the case where you want to sign part of a zone
with one PQ algorithm and another with another.

Best,

 Bas


[1] That's how I interpret RFC6840 Section 5.11, but
draft-huque-dnsop-multi-alg-rules-08 reads it as a MUST. In any case,
what's important is what we should change it in to.

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">The draft as-is goes in =
the wrong direction for a downgrade-secure PQ DNSSEC deployment. To be fair=
, that is not one of the stated goals of the draft: it only mentions experi=
mentation with PQC. Also Johan is talking about the future where we want to=
 partially move from ML-DSA-44 to something smaller but less secure. Still,=
 good to talk about what this means for ML-DSA-44.</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr"><br></div><div>Say we have a zone fully signed wit=
h both algorithm 13 and ML-DSA-44. Today validators SHOULD [1] accept any p=
ath. Thus an attacker can strip the ML-DSA signatures, and successfully dow=
ngrade such a lenient validator even if it supports ML-DSA-44.</div><div><b=
r></div><div>To solve this PQ validators should insist on an ML-DSA-44 path=
, if it sees an ML-DSA-44 DS.</div><div><br></div><div>draft-huque-dnsop-mu=
lti-alg-rules-08 goes in the opposite direction. Quoting section 3.3</div><=
div><br></div><div>=C2=A0 =C2=A01.=C2=A0 When the DS RRset or trust anchor =
set for a zone includes an<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0unsupported UNIVER=
SAL or FORMERLY-UNIVERSAL algorithm, validators<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0MUST treat the zone as unsigned, even if the DS RRset or trust<br>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0anchor set lists another supported algorithm.<br><br>=
=C2=A0 =C2=A02.=C2=A0 Otherwise, validators MUST accept any valid path.</di=
v><div><br></div><div>As explained above 2 is not what we want for secure P=
Q deployment. What about 1?</div><div><br></div><div>I am not sure whether =
&quot;unsupported&quot; is meant to apply to FORMERLY-UNIVERSAL. If it does=
, then a validator can just keep supporting all algorithms and this clause =
is never triggered. So suppose it&#39;s not. The intended example of FORMER=
LY-UNIVERSAL are algorithms 8 and 13 some point in the future. Thus dual si=
gning a zone with either and ML-DSA-44 will cause validators to mark the zo=
ne as unsigned: not what I think we would want.</div><div><span style=3D"ba=
ckground-color:transparent">=C2=A0</span></div><div><div dir=3D"ltr" class=
=3D"gmail_attr"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27, 2026 =
at 7:55=E2=80=AFAM Joe Abley &lt;jabley=3D<a href=3D"mailto:40strandkip.nl@=
dmarc.ietf.org">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Perhaps even just<br><br>=C2=
=A0 (RSASHA256, ML-DSA-44)<br>=C2=A0 (ECDSAP256SHA256, ML-DSA-44)<br><br>wo=
uld be enough.</blockquote></div></div><div><br></div><div>I think Mark is =
talking about a PQ/PQ pair, where the DNSKEY and RRSIG only contains one of=
 the two, for the case where you want to sign part of a zone with one PQ al=
gorithm and another with another.=C2=A0</div><div><br></div><div>Best,</div=
><div><br></div><div>=C2=A0Bas</div><div><br></div><div><br class=3D"gmail-=
Apple-interchange-newline">[1] That&#39;s how I interpret RFC6840 Section 5=
.11, but draft-huque-dnsop-multi-alg-rules-08 reads it as a MUST. In any ca=
se, what&#39;s important is what we should change it in to.</div></div></di=
v>

--000000000000abc229065794a551--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============2666493139596810567==--