The key will be 40x larger. Not that bad for the certs. It'll be about 15kB extra. Will depend on your use case if that's bad. For video it's fine. But not all browsing is video. At Cloudflare half of the QUIC connections we see transfer less than 8kB from server -> client total. On average 3-4kB of that is already certificates today. That'll probably be quite noticeable. https://blog.cloudflare.com/pq-2025/#do-we-really-care-about...
But do those connections constitute a material amount of total bandwidth and thus resources? No, as the article points out the median is 8 KB, but the average is 583 KB. The extra 15 KB for each connection would only bump server-side bandwidth serving by ~2%.
But even that is beside my point. The impact of making certificates larger should be, largely, just the cost of making them larger which, on average, would not actually be that significant of a impact. That is not the real problem. The problem is actually that there is so much broken crap everywhere in networks and network stacks that would either break or dramatically balloon what should otherwise be manageable costs.
Everybody just wants to paper over that by blaming the larger certificates when what is actually happening is that the larger certificates are revealing the rot. That is not to say that the proposal which reduces the size of the certificates is bad, I think it is good to do so, but fixing the proximal cause so you can continue to ignore the root cause is a recipe that got us into this ossified, brittle networking mess.
Merkle Tree Certificates basically uses the same structure as Certificate Transparency today. Merkle Ladder uses a weird variation claimed to be useful to DNSSEC. I think it's rather just to seem novel ( https://datatracker.ietf.org/ipr/search/?submit=draft&id=dra... )
- Spartan implements the Sum-Check protocol with Multilinear Polynomial Commitments, which is hash-based like XMSS and SPHINCS+ (unlike Verkle trees which are built on KZG which relies on the "Discrete Logarithm Problem" (which Shor’s broke)).
Landmarks are generated every hour, but I expect clients to pull them perhaps once or twice per day. Servers will keep two signatureless MTCs around a few days apart, so even if your client didn't update in a few days you can still use the small signatureless cert. The biggest reason for needing the big MTCs is for when you need a new certificate quickly. Our intern Lena had a look how common that would be, and she estimates it'd be required for 0.1% at any given time. https://www.youtube.com/watch?si=72ClhykaYDHf0sND&v=f8unMB2Q...
The biggest blocker for DANE at the moment is that it doesn't have a transparency story. There is no good visibility into whether your TLD advertises a second pair of zone signing keys to few you don't control. We can add some transparency logs as with CT, but then we have a rate-limiting problem. You could have a mix of heavily rate-limited free DNSSEC logs and some paid DNSSEC logs. This is starting to look a lot like the current WebPKI then. I must say that this is an under explored area.
But you don't need the transparency!
The whole transparency thing was added because we have hundreds of Certificate Authorities all over the world who would otherwise have the power to secretly sign a cert for your website without anyone ever knowing.
And if you DO need the extra monitoring, all it takes is periodically retrieving the DNS record and send an alert if it changes. (There is no certificate that needs periodical rotation, you only need to renew the keypair if the server is compromised.)
That's a serious blocker, but the biggest blocker for it is that it can't reliably be deployed; too much of the Internet is on links that won't pass the records required to verify DANE, which means that browsers need fallback paths for DANE, which means DANE expands, rather than contracts, the threat surface area of the WebPKI.
