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]> 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]
