[DNSOP] Re: PQ DNSSEC?

Paul Wouters <[email protected]> Mon, 20 Jul 2026 03:35:03 -0400 (EDT)
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>
Bas wrote:

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

This assumes we are stuck with the current transport. The real question
is, should we fix the tranport so we then no longer care about size of
signaures, or should we limit the new PQ crypto based on the current
packet size issues. I feel it might be better to think of a DNS protocol
fragmentation support so that from a DNS protocol point of view, we can
just send huge packets.

Watson Ladd wrote:

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

The majority of DNSSEC uses online signing (for 2nd level domains).

Verification matters. People don't regularly "turn it off", they just
use providers that have it enabled.

Regular consumers do not know how to "turn off dnssec".
So I believe making choices based on this assumption is wrong.

Paul

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]