Comment by agwa
1 day ago
The downside is that to get the size optimization, TLS servers will get moderately more complicated (they'll need to have multiple MTC certificates configured and select the right one depending on the client's state), and TLS clients will get considerably more complicated (they'll need to continuously download landmarks for each CA out-of-band from a trusted source).
I expect many non-browser TLS clients won't support the small landmark-relative certificates, because there isn't a clear party to operate the landmark distribution service (Chrome has Google, and Firefox has Mozilla, but who does curl have?). I'm also worried that support will be lacking in open source TLS servers, though that's a more tractable problem. Consequentially, I expect the large standalone certificates to be quite common outside of connections between browsers and CDNs.
In a way it's just more of what we're already dealing with today.
The entire Linux ecosystem simply trusts Firefox's root CA store, and we're happy with distros repackaging and shipping it to us as-is every once in a while. OCSP has failed, so now Firefox is regularly shipping kilobyte-sized bloom filter updates to every browser to replace it with CRLite.
Doing the same for MTC landmark updates doesn't sound like too big of a change to me. The biggest challenge is going to be to get the wider ecosystem to adopt it: some kind of system-wide cron job to download the updates, or perhaps a "systemd-validate-mtc" helper.
The real challenge is going to be the embedded world. This kind of overhead is trivial for a desktop or a server, but a tiny embedded chip with only a few megs of ram and flash?
On Linux and similar systems, I'm hoping github.com/rustls/upki will handle landmark distribution, and that non-browser clients can use that. Of course Rustls will support their own project, but I'm hopeful other TLS stacks do too. Ubuntu announcing they're deploying it should help with that.
On other OSes (like Mac OS and Windows), there's also OS-level services which could support this.
It would be a shame if we end up with a bunch of copies of this data, so I think a shared OS service is the only reasonable approach.
The hardest part is going to be smaller embedded systems.