[DNSOP] PQ DNSSEC downgrade protection (Was: Sanity tl;d r for Multi-algorithm DNSSEC Requirements)
Bas Westerbaan <[email protected]> Mon, 27 Jul 2026 12:12:30 +0200
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <CAMjbhoUiqDvLOaH9eZQAvHwDL0Lfh8M-vJwBprAe=b1CLXA-Eg@mail.gmail.com> |
--===============1266658788335509435== Content-Type: multipart/alternative; boundary="00000000000081efbb065794f6db" --00000000000081efbb065794f6db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, 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 would rely o= n > the PQC one only (such that invalid PQC sigs are rejected (SERVFAIL) > instead of being overridden by the conventional ones)? > Put more succinctly: if a validator supports PQC, and a zone has PQC signatures, a (quantum) attacker can't fool the validator, even if the zone also contains classical signatures for legacy validators. > 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. > Fair point (changed subject), but these are not completely orthogonal issues: the MUST accept any path is a problem. > 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). > The simplest approach to me seems for validators, when they add support for ML-DSA-44, to also change their logic to insist on a ML-DSA-44 if there is ML-DSA-44 DS for the zone. [1] Best, Bas [1] You could perhaps enshrine that in a PRIORITY validation support status in your draft. > > > On 7/27/26 11:49, Bas Westerbaan wrote: > > 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 t= he > ML-DSA signatures, and successfully downgrade such a lenient validator ev= en > 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, validato= rs > > 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. T= he > 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] <mailto:[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. > > > > _______________________________________________ > > DNSOP mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > Like our community service? =F0=9F=92=9B > Please consider donating at > > https://desec.io/ > > deSEC e.V. > M=C3=B6ckernstra=C3=9Fe 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > --00000000000081efbb065794f6db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Peter,</div><div dir=3D"ltr"><br></div><div class= =3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex">What do you mean by downgrade-secure? That a signer can sign = with PQC and a conventional algorithm, and when the validator doesn't s= upport the former, it uses the latter, whereas when a validator supports it= , it would rely on the PQC one only (such that invalid PQC sigs are rejecte= d (SERVFAIL) instead of being overridden by the conventional ones)?<br></bl= ockquote><div><br></div><div>Put more succinctly: if a validator supports P= QC, and a zone has PQC signatures, a (quantum) attacker can't fool the = validator, even if the zone also contains classical signatures for legacy v= alidators.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex"> 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.<br></blockquote><div= ><br></div><div>Fair point (changed subject), but these are not completely= =C2=A0orthogonal issues: the MUST accept any path is a problem.</div><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 a= lgorithm number that this key overrides (that is, validators cannot accept = RRSIGs with the listed algorithms if they support PQC).<br></blockquote><di= v><br></div><div>The simplest approach to me seems for validators, when the= y add support for ML-DSA-44, to also change their logic to insist on a ML-D= SA-44 if there is ML-DSA-44 DS for the zone. [1]</div><div><br></div><div>B= est,</div><div><br></div><div>=C2=A0Bas</div><div><br></div><div><br></div>= <div>[1] You could perhaps enshrine that in a PRIORITY validation support s= tatus in your draft.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"> <br> <br> On 7/27/26 11:49, Bas Westerbaan wrote:<br> > 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 d= raft: it only mentions experimentation with PQC. Also Johan is talking abou= t the future where we want to partially move from ML-DSA-44 to something sm= aller but less secure. Still, good to talk about what this means for ML-DSA= -44.<br> > <br> > <br> > 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 eve= n if it supports ML-DSA-44.<br> > <br> > To solve this PQ validators should insist on an ML-DSA-44 path, if it = sees an ML-DSA-44 DS.<br> > <br> > draft-huque-dnsop-multi-alg-rules-08 goes in the opposite direction. Q= uoting section 3.3<br> > <br> >=C2=A0 =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=A0 =C2=A0unsupported UNIVERSAL or FORMERLY-UNI= VERSAL algorithm, validators<br> >=C2=A0 =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=A0 =C2=A0anchor set lists another supported al= gorithm.<br> > <br> >=C2=A0 =C2=A0 =C2=A02.=C2=A0 Otherwise, validators MUST accept any vali= d path.<br> > <br> > As explained above 2 is not what we want for secure PQ deployment. Wha= t about 1?<br> > <br> > I am not sure whether "unsupported" is meant to apply to FOR= MERLY-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 caus= e validators to mark the zone as unsigned: not what I think we would want.<= br> > On Mon, Jul 27, 2026 at 7:55=E2=80=AFAM Joe Abley <jabley=3D<a href= =3D"mailto:[email protected]" target=3D"_blank">40strandkip.nl@= dmarc.ietf.org</a> <mailto:<a href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0Perhaps even just<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (RSASHA256, ML-DSA-44)<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (ECDSAP256SHA256, ML-DSA-44)<br> > <br> >=C2=A0 =C2=A0 =C2=A0would be enough.<br> > <br> > <br> > 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.<br> > <br> > Best,<br> > <br> >=C2=A0 =C2=A0Bas<br> > <br> > <br> > [1] That's how I interpret RFC6840 Section 5.11, but draft-huque-d= nsop-multi-alg-rules-08 reads it as a MUST. In any case, what's importa= nt is what we should change it in to.<br> > <br> > _______________________________________________<br> > DNSOP mailing list -- <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a><br> <br> -- <br> Like our community service? =F0=9F=92=9B<br> Please consider donating at<br> <br> <a href=3D"https://desec.io/" rel=3D"noreferrer" target=3D"_blank">https://= desec.io/</a><br> <br> deSEC e.V.<br> M=C3=B6ckernstra=C3=9Fe 74<br> 10965 Berlin<br> Germany<br> <br> Vorstandsvorsitz: Nils Wisiol<br> Registergericht: AG Berlin (Charlottenburg) VR 37525<br> <br> </blockquote></div></div> --00000000000081efbb065794f6db-- --===============1266658788335509435== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============1266658788335509435==--