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
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
