[dns-operations] Review and implementation of draft-westerbaan-dnssec-mldsa-04

Tue Sep 29 13:32:16 UTC 2026

Hi Bas

On Tue, Sep 01, 2026 at 12:44:47PM +0200, Bas Westerbaan via dns-operations wrote:
> Date: Tue, 1 Sep 2026 12:44:47 +0200
> From: Bas Westerbaan <bas at cloudflare.com>
> To: dns-operations at lists.dns-oarc.net
> Subject: 1.1.1.1 supports ML-DSA-44 (alg 18)
> Message-ID: <CAMjbhoVxviN=shNKJUPwAZ6AYsxJBDa9N3ZbLEZcaZ=2kxJY4Q at mail.gmail.com>
>
> Hey all!
>
> Yesterday we rolled out support for ML-DSA-44 (alg 18) in 1.1.1.1 turned on
> by default. We also insist on alg 18 signatures if an alg 18 key is
> advertised in a DS (even if other algorithms are available) to prevent
> future downgrades.
>
> dig @1.1.1.1 +dnssec only.alg18.westerbaan.name
> dig @1.1.1.1 +dnssec downgrade.alg18.westerbaan.name
>
> This all of course doesn't make any difference today as there basically
> aren't any alg 18 signed zones yet except for the odd test zone.

Loop has implemented DNSSEC signer and resolver validator support for
MLDSA44 per the draft, using the OpenSSL library. It does not pass
OSSL_SIGNATURE_PARAM_DETERMINISTIC, so it's hedged ML-DSA-44 signing
currently. It also performs the requirements of FIPS 204 section
3.6.2. Loop also implements downgrade prevention per the draft's section
7.2 which is configurable, and enabled by default. My comments on the
draft:

The draft is well-written. It is succinct, contains rationale, an
example, and is how I'd like a draft to be. Well done.

> 7.2.  Downgrades
>
>    Section 5.11 of [RFC6840] recommends validators to accept any single
>    valid path.  Such lenient validators are vulnerable to a downgrade
>    attack: if a zone is signed by ML-DSA-44 and a quantum-vulnerable
>    algorithm, then a quantum attacker can strip the ML-DSA-44
>    signatures, and have the lenient validator accept the forged quantum-
>    vulnerable signature.
>
> Westerbaan & Schmieg    Expires 12 February 2027                [Page 6]
> Internet-Draft              ML-DSA for DNSSEC                August 2026
>
>    This does not apply if the lenient validator does not accept any
>    quantum-vulnerable algorithms or if the zone is only signed by ML-
>    DSA-44.  A validator that insists on the presence of a valid ML-
>    DSA-44 RRSIG when the availability is advertised in the zones DS,
>    also evades the downgrade.

s/the zones/the zone's/

There's also the case of multiple trust anchors with different
algorithms which may be specified as DNSKEYs. There's also the apex
DNSKEY RRset, an example of which is:

Parent:

example. DS ... 8 ...         ; points to RSA/SHA-256 KSK

Child apex:

example. DNSKEY 257 3 8  ...  ; KSK, RSASHA256
example. DNSKEY 256 3 18 ...  ; ZSK, MLDSA44

and the zone is signed with both algorithms. If 8 were broken, then it
wouldn't matter what's in the DNSKEY RRset, but I suggest that it's
mentioned.

MLDSA44's RRSIG size is 2420 octets and leads to truncation over UDP in
a lot of cases. This is quite noticeable and even feels sluggish in
practice.

There has been discussion in the TLS WG about hybrid algorithms. In the
case of the DNSSEC signature schemes, a problem might be that a secret
vulnerability in a new PQ signature algorithm may be known to few but
not public knowledge and a hybrid scheme may block that from being
exploited when classical algorithms are still unbroken. In the case of
DNSSEC, as it allows signatures from multiple algorithms to co-exist, a
validator may check signatures of multiple algorithms if available and
there need not be a separate hybrid algorithm. Use of multiple
algorithms together would further bloat the RRSIG RRsets.

[muks at p5 ~/src2/akira/system (wip)]$ sh ./run.sh pqvalidator
S:pqvalidator:Tue 29 Sep 10:21:46 +08 2026
T:pqvalidator:1:A
A:pqvalidator:System test pqvalidator
I:pqvalidator:PORTRANGE:5300 - 5399
I:checking default strict validator accepts classical-only zone (1)
I:checking default strict validator does not infer PQ KSK availability without a PQ DS (2)
I:checking default strict validator uses PQ DS/KSK link while accepting classical ZSK link (3)
I:checking default strict validator uses PQ ZSK RRSIG when advertised (4)
I:checking default strict validator validates PQ at both trust-chain links (5)
I:checking default strict validator rejects stripped PQ DNSKEY signature (6)
I:checking default strict validator rejects stripped PQ data signature (7)
I:checking default strict validator rejects DS/KSK downgrade when ZSK link remains PQ (8)
I:checking default strict validator rejects ZSK downgrade when DS/KSK link remains PQ (9)
I:checking lenient validator accepts classical-only zone (10)
I:checking lenient validator accepts unadvertised PQ KSK (11)
I:checking lenient validator accepts valid mixed DS zone (12)
I:checking lenient validator accepts valid mixed ZSK zone (13)
I:checking lenient validator accepts zone with PQ at both links (14)
I:checking lenient validator accepts classical fallback when PQ DNSKEY signature is stripped (15)
I:checking lenient validator accepts classical fallback when PQ data signature is stripped (16)
I:checking lenient validator accepts DS/KSK downgrade with PQ ZSK still present (17)
I:checking lenient validator accepts ZSK downgrade with PQ DS/KSK still present (18)
I:checking explicit strict view accepts classical-only zone (19)
I:checking explicit strict view keeps an unadvertised PQ KSK separate from the DS policy (20)
I:checking explicit strict view keeps DS/KSK and ZSK policy independent (21)
I:checking explicit strict view validates advertised PQ ZSK (22)
I:checking explicit strict view validates PQ at both links (23)
I:checking explicit strict view rejects DS/KSK downgrade (24)
I:checking explicit strict view rejects ZSK downgrade (25)
I:checking explicit strict view rejects combined-zone DS/KSK downgrade (26)
I:checking explicit strict view rejects combined-zone ZSK downgrade (27)
I:exit status: 0
R:pqvalidator:PASS
E:pqvalidator:Tue 29 Sep 10:21:51 +08 2026
[muks at p5 ~/src2/akira/system (wip)]$

For interop testing, mldsa44.frankenmodel.com is a sample public DNS
zone signed using Loop with alg 18.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20260929/1f766fbb/attachment.sig>