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 on > 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 support > 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 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 AM Joe Abley <jabley= > [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? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
