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 would 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. 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). Probably the solution would look differently than this, but it seems independent of what this draft is trying to address. Best, Peter 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 <[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]
