[DNSOP] Re: PQ DNSSEC?

[Watson Ladd <[e-mail]>]

On Sun, Jul 19, 2026 at 4:17 AM Bas Westerbaan
<bas=[e-mail]> wrote:
>
> Hey all,
>
> With various new regulatory timelines for valuable systems to be PQ by 2031, we're getting questions what we're looking at with DNSSEC. Looking from afar (and please forgive me my ignorance) it doesn't look good. There's a lot of academic investigation and experimentation (great), IETF side-meetings, but no thrust or plans to any deployment; no adopted drafts or BoFs.
>
> If we care for PQ DNSSEC by 2031, what would be the most practical path? We can't be too ambitious.
>
> So what are we looking at? The only practical [1] signature scheme available on this timeframe is ML-DSA-44 with 2,420 byte signatures and 1,322 byte public keys. We can't have authoritatives include these by default: it'll break clients that can't fall back to TCP, or are buggy in other ways.
>
> Instead I suppose we have the client signal if it supports ML-DSA-44 [2], and only in that case return those large RRSIGs. This allows for gradual demployment, and only impacts those that care for PQ DNSSEC. While we wait for the root to sign with ML-DSA-44, resolver can anchor on TLDs ML-DSA-44 keys.
>
> In the right ballpark?

Since singing is designed to be offline, and verification doesn't
actually matter, and size does, SQISign is the obvious choice. We know
verification doesn't matter given people regularly turn it off rather
than fail closed when verification is failing.

Sincerely,
Watson
>
> Best,
>
>  Bas
>
>
> [1] https://blog.cloudflare.com/ml-dsa-will-have-to-do/
> [2] Should we repurpose draft-huque-dnssec-alg-nego?
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim