Hi Swapneel On Thu, Oct 01, 2026 at 12:31:15PM +0000, Sheth, Swapneel wrote: > Greetings all, > > With the upcoming post-quantum DNSSEC DNSOP interim, I wanted to > provide an update on the state of Merkle Tree Ladder (MTL) and how it > can help to enable a post-quantum transition for DNSSEC.
This is a clever construction. > As of today, we have two active drafts on MTL – a streamlined base [1] and > new extension draft [2]. The base draft defines MTL with ML-DSA-44 and has > each RRSIG response carry everything needed for validating a signature on an > RRset using the zone’s DNSKEY just like existing DNSSEC algorithms including > the ML-DSA draft [3]. These changes are geared towards implementation > simplicity while still enabling potential space savings benefits for > authoritative name server operators compared to non-MTL approaches as shown > in [4]. > > The new extension draft defines an EDNS(0) option to enable clients to > communicate their knowledge of an existing ML-DSA signature to a name server. > If the specified signature is still valid, the server can avoid > re-transmitting the potentially large PQ signature. The extension can provide > bandwidth and transport related benefits as well as space savings for > resolvers and clients who opt in to it. A few comments without a full review: * The MTL scheme appears generic enough that it need not mention or restrict itself to "Module-Lattice-Based Signatures" in the title (although that may be the quest that likely set you off to design this). It appears it could lead to CPU signing/validation savings with other DNSSEC algorithms too (including the current classical ones), with modest increase in RRSIG sizes (modest compared to where we are with ML-DSA). * This scheme adds considerable implementation complexity compared to previous algorithm implementations, or the sibling ML-DSA-44 draft by Bas Westerbaan. * It appears to me that the EDNS option in the second draft is critical to derive the benefit of the MTL approach when compared against just the base draft, so much so that it should become a part of the base draft. Without the EDNS option, I am not convinced that the base draft will make a significant difference from the point of view of resolvers or any others except large TLD signers (signer-heavy). With the EDNS option, it could make this approach perform better at the cost of far more increased validator and resolver complexity (last comment). For this, as an example, see Geoff Huston's APNIC blog article from a few months ago: https://blog.apnic.net/2026/05/28/centrality-in-the-internets-names/ In table 2 of that article, you can see the top authoritative providers, i.e., how often a resolver queries the providers (resolver -> auth query count). Although there's insufficient information there, it's likely that small zones dominate resolver <-> auth traffic. TLD zone cuts and and even popular 2nd level zone cuts get cached quickly after a resolver is started. The proposed EDNS option could reduce network traffic significantly for these majority of cases where one RRset has been queried and the ML-DSA-44 sig doesn't have to be retransmitted for other RRsets in the same ladder. This is the typical case for small zones. Without this EDNS option, I'm not convinced with current data I can find on the internet about traffic patterns, that the first draft will be useful except for signers that deal with large zones (such as TLDs), but not for most resolver validation activity. It's a clever construction and impressive. :) But I shudder at the added complexity of implementing this compared to the relative simplicity of Bas Westerbaan's draft. Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
