[DNSOP] Re: PQ DNSSEC?

Mukund Sivaraman <[email protected]> Mon, 20 Jul 2026 16:14:30 +0800
Newsgroups	gmane.ietf.dnsop
Message-ID	<al3Y5heOAGi7kJqz@p5>
On Mon, Jul 20, 2026 at 03:35:03AM -0400, Paul Wouters wrote:
> 
> 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.

Bas: By clients that can't fall back to TCP, do you mean clients that
don't implement TCP or can't use TCP in their network? Assuming this is
primarily a validating DNS client such as a validating resolver,
wouldn't it suffice to think that it ought to be able to use TCP?

If it's that answer + RRSIG RRsets ought to pass over UDP to a client
that's not a validating resolver which queries for it and it can't pass
over UDP, it'll get a response with TC=1 for DO=1 and won't be able to
query it over UDP. But can this not be considered negligible considering
the client can't do UDP and it's not going to be validating? RFC 6840
allows AD flag signal in the response if the query has AD=1 even if
DO=0, so a client that can only use UDP and wants just the answer but
also wants to know if it is authenticated can still get just that signal
in the AD bit without any of the RRSIGs, and the validation happens on a
resolver that's capable of TCP.

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

Many years ago, Shane and I came up with
<https://datatracker.ietf.org/doc/html/draft-muks-dns-message-fragments-00>
but it didn't go anywhere.

Thinking of this today and reading some of the other proposals, I am
less fond of introducing hacks in DNS protocol and prefer elegance
that's available (such as the TCP stream). As someone else pointed out,
one day it'll also be the DNS message's 64kiB size's time but perhaps
we're not there yet.

		Mukund

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 1.5 KB)