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

--===============0229113564964946809==
Content-Type: multipart/alternative; boundary="000000000000332bb006579696fd"

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

On Mon, Jul 27, 2026 at 5:58=E2=80=AFAM Peter Thomassen <peter=3D
[email protected]> wrote:

> Hi Bas,
>
> What do you mean by downgrade-secure? That a signer can sign with PQC and
> a conventional algorithm, and when the validator doesn't support the
> former, it uses the latter, whereas when a validator supports it, it woul=
d
> rely on the PQC one only (such that invalid PQC sigs are rejected
> (SERVFAIL) instead of being overridden by the conventional ones)?
>
> If so, DNSSEC provides no solution for that today. It may be useful to
> find one, but it's orthogonal to this draft, so I'd propose to discuss it
> in a separate thread and maybe think about a draft.
>

Yes, indeed. The multi-alg rules draft, in this regard, does not really go
in the opposite direction of the current DNSSEC design. It merely restates
the rule in RFC 6840 (DNSSEC Clarifications) that validators should accept
any algorithm path, and not insist that all algorithm paths validate. This
rule enables the use cases that motivate our draft, hence of course, we did
not propose to modify it.

This is actually a common misconception about DNSSEC (that I actually
suffered from for a time too, as the security guarantees that DNSSEC
provides are not very clearly explained in any existing doc). DNSSEC has
never offered algorithm downgrade protection, only protection from being
downgraded to insecure. The validator rules proposed in the draft for
"formerly universal" algorithms are designed to deal with cases where
validators have disabled support for a formerly universal algorithm, so
that they can gracefully degrade such zones to unsigned without causing
SERVFAIL.

One question that comes to mind would be whether PQC-priority over
> conventional (if PQC is supported) should be a validator-side policy, or
> whethre that should be signaled somehow, for example in the DNSKEY rdata =
by
> prepending a list of algorithm number that this key overrides (that is,
> validators cannot accept RRSIGs with the listed algorithms if they suppor=
t
> PQC).
>

I agree that it is useful to discuss whether we need an algorithm downgrade
enhancement in DNSSEC, but yes, additional explicit signaling is likely
needed for that, and it would be a painful slog to get the long tail of
validators in the field upgraded to implement such an enhancement. It may
be better to bundle such a proposed enhancement in DELEG, where validators
would need to change anyway. In fact, in early DELEG discussions a number
of years ago, I had proposed (verbally) that DELEG should support signaling
of new zone level properties like algorithm downgrade protection. The use
case I had in mind was where a zone could dictate that both PQC and
Classical signatures need to validate successfully.

Shumon.

--000000000000332bb006579696fd
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 5:58=E2=80=AFAM P=
eter Thomassen &lt;peter=3D<a href=3D"mailto:[email protected]">40d=
[email protected]</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">Hi Bas,<=
br>
<br>
What do you mean by downgrade-secure? That a signer can sign with PQC and a=
 conventional algorithm, and when the validator doesn&#39;t support the for=
mer, it uses the latter, whereas when a validator supports it, it would rel=
y on the PQC one only (such that invalid PQC sigs are rejected (SERVFAIL) i=
nstead of being overridden by the conventional ones)?<br>
<br>
If so, DNSSEC provides no solution for that today. It may be useful to find=
 one, but it&#39;s orthogonal to this draft, so I&#39;d propose to discuss =
it in a separate thread and maybe think about a draft.<br></blockquote><div=
><br></div><div>Yes, indeed. The multi-alg rules draft, in this regard, doe=
s not really go in the opposite direction of the current DNSSEC design. It =
merely restates the rule in RFC 6840 (DNSSEC Clarifications) that validator=
s should accept any algorithm path, and not insist that all algorithm paths=
 validate. This rule enables the use cases that motivate our draft, hence o=
f course, we did not propose to modify it.</div><div><br></div><div>This is=
 actually a common misconception about DNSSEC (that I actually suffered fro=
m for a time too, as the security guarantees that DNSSEC provides are not v=
ery clearly explained in any existing doc). DNSSEC has never offered algori=
thm downgrade protection, only protection from being downgraded to insecure=
. The validator rules proposed in the draft for &quot;formerly universal&qu=
ot; algorithms are designed to deal with cases where validators have disabl=
ed support for a formerly universal algorithm, so that they can gracefully =
degrade such zones to unsigned without causing SERVFAIL.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
One question that comes to mind would be whether PQC-priority over conventi=
onal (if PQC is supported) should be a validator-side policy, or whethre th=
at should be signaled somehow, for example in the DNSKEY rdata by prependin=
g a list of algorithm number that this key overrides (that is, validators c=
annot accept RRSIGs with the listed algorithms if they support PQC).<br></b=
lockquote><div><br></div><div>I agree that it is useful to discuss whether =
we need an algorithm downgrade enhancement in DNSSEC, but yes, additional e=
xplicit signaling is likely needed for that, and it would be a painful slog=
 to get the long tail of validators in the field upgraded to implement such=
 an enhancement. It may be better to bundle such a proposed enhancement in =
DELEG, where validators would need to change anyway. In fact, in early DELE=
G discussions a number of years=C2=A0ago, I had proposed (verbally) that DE=
LEG should support signaling of new zone level properties like algorithm do=
wngrade protection. The use case I had in mind was where a zone could dicta=
te that both PQC and Classical signatures need to=C2=A0validate successfull=
y.</div><div><br></div><div>Shumon.</div><div><br></div></div></div>

--000000000000332bb006579696fd--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============0229113564964946809==--