We want to echo the sentiment Wes has expressed here as it aligns with some of our thinking as we have discussed through our MTL draft [draft-kaizer-dnsop-ml-dsa-mtl-dnssec]. We are under the assumption that more TCP traffic is coming due to increased key/signature sizes of today’s PQC algorithms. We also assume there is a desire to maintain as much UDP traffic as possible, so exploring options can be useful, even if it primarily applies to the “play nicely (most do)” crowd. For the play less nicely crowd, there is room to understand when/where existing resolver defenses still work versus where new ones may be needed. We think these conversations can proceed in parallel and provide options the community can consider as we figure out how to approach PQC DNSSEC.
-Swapneel On 7/7/26, 2:12 PM, "Wes Hardaker" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Ondřej Surý <[email protected] <mailto:[email protected]>> writes: > The malicious server can just say "nope, this is new". Agreed, it does not prevent someone in the middle from doing what we're already heading to: TCP always and all data always. That wasn't the point. 90% of the requests that would be transmitted over TCP every 5 minutes. If someone the middle really wanted that to continue, I agree you're stuck. But if most of the parties on the planet do play nicely (and most do) then we can greatly reduce the potential traffic levels. > I believe it is dangerous to say "it is ok to deploy PQC algorithms with > large signatures" because we have these optimizations. I don't think I ever said that. > The fact is that we either need a PQC algorithm that will be > size-suitable for DNS or we will have to brace for the impact of > completely switching to TCP. The top of my document lays out an argument that: 1. we better accept TCP is coming 2. but we may try to reduce the amount of traffic we do send to mitigate some of that impact. -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
