It works fine for mailservers. No on expects a mailserver cert to be from an authority, you can self sign and it works fine.
Like, just last week the browsers had to remove a certificate authority from their root cert programs because Kazakhstan was issuing certificates to MiTM traffic. A TOFU model would make it a lot harder to detect and remediate this sort of attack and lots of other relevant attack vectors.
We'd also need to re-solve a bunch of adjacent problems like revocation, renewal/rotation, and transparency, which would probably mean re-introducing the sorts of centralized architectural components and processes that I'm assuming you're trying to eliminate with TOFU.
Then however, we get to the political question who exactly that central authority should be and why.
> Like, just last week the browsers had to remove a certificate authority from their root cert programs because Kazakhstan was issuing certificates to MiTM traffic.
I may have misunderstood the incident, but wasn't it such that the CA was not even one of the built-ins, but a "custom" root CA that all users were required to install on their systems? As such, the block was more equivalent to block a specific to TOFU key.
Of course, blocking the MITM CA won't magically turn off the ISP's MITM proxy. It will simply make it so that kazhakh citizens can't access any web sites at all until the government hopefully caves and turns off the proxy.
I wouldn’t say the centralization of Web PKI is by design so much as it is (was?) by necessity. There’s a crypto conjecture called Zooko’s Triangle that says there are three desirable properties for a naming system: human-meaningful, secure, and decentralized. Zooko’s conjecture is that you can only have two. Web PKI picks secure & human-meaningful. Simple PKI (like TOFU) picks secure & decentralized (the names aren’t actually human-meaningful since you’re really trusting a public key which is a big random number, not a domain name). DNS picks human-meaningful and decentralized.
More recently, Aaron Schwartz realized you can “square the triangle” using blockchain. So it appears to be technically possible to have all three now, but there are other hurdles. In any case, simple public keys aren’t a silver bullet. Just a different set of compromises.
So most SSH users (who, on average, are way more technically competent than browser users) will automatically 1) panic and think they're being hacked, or 2) blindly trust the new key when a key change occurs with SSH. Both of these responses are dangerous. The result is that, unless you have fancy stuff for managing known hosts for all of your users on all of your endpoints, you're probably just avoiding this scenario by not rotating host keys at all for SSH. Which is also problematic.
By using a CA you're delegating the key binding to a trusted piece of infrastructure that can be locked down and monitored by experts. You can't do that easily with key-bindings written to files on a bunch of different endpoints. With a CA, end users shouldn't need to care about key changes. The fact that the CA can issue a new certificate for some entity is a benefit: it makes credential rotation easier. If you do want to know when credentials rotate there are ways to monitor that yourself (and Web PKI has ways like key pinning and cert transparency).
In my homelab? I guess I should also kerberize my NFS mounts, after I solve the SPOF problem for kerberos's dependent pieces. I might have a little time after doing all this for working on my homelab projects. How much time could this configuration, maintenance and monitoring possibly take? (Just between you and me I resolve that on January 1st I will again start reading all daily/weekly/monthly logs, and this year I WILL NOT FAIL. It's only dozen give or take few boxen.)
If the security infrastructure needs to designed, configured, monitored, and maintained by "experts" in an unfunded environment, the security infrastructure is doomed to fail. IOW, it's security theatre.
Yes, but that's A Bad Thing(TM) -- it means that MITM'ing a mail server also "works fine"!
Now, personally, I'm not a big fan of DNSSEC (especially considering how widespread 512- and 1024-bit keys were!) but I was hopeful that "DNS-based Authentication of Named Entities" (DANE) [0] would become widely supported once it was fully standardized. Unfortunately, that didn't happen -- especially in the browsers!
After the explosion in growth of "HTTPS everywhere", transport security for e-mail was the next big (unencrypted) problem that needed to be addressed in my opinion. Luckily, both Exim and Postfix (my MTA of choice) gained support for DANE so while progress was technically made, widespread adoption never really happened there either (mostly due to the dependency on DNSSEC, AFAICT).
In the meantime, though, "SMTP MTA Strict Transport Security (MTA-STS)" appeared on the scene and has since been formalized as RFC8461 [1]. In many ways, it's technically superior to DANE and, importantly, does not rely on DNSSEC. It does have the same reliance on the "WebPKI" as the browsers so it's certainly not perfect; it's still a huge improvement, though, and it's certainly better than opportunistic encryption which is trivial to MITM.
Anyways, as MTA-STS was designed by folks at Google, Microsoft, Comcast, and Oath, I'm hopeful, once again, that we'll eventually get to the point where (at least) the overwhelming majority of e-mail is encrypted in transit as it passes from MTA to MTA on its way to the recipient's mailbox.
One of the few good things about so much of the e-mail nowadays being handled by Google and Microsoft is the huge volume of mail that will suddenly just start being encrypted in transit, overnight, when just those two enable MTA-STS in their mail infrastructure.
I haven't kept up with progress on MTA-STS since leaving my previous job (which included responsibility for the mail infrastructure) about two years ago -- shortly after it became a standard -- but I'd love to find out that it's already been widely rolled out by the big players in the meantime! I suppose it's about time to catch up on the last two year's worth of messages sitting unread in the "mailops" folder in my mailbox!
--
[0]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
TLA cert authorities are bad enough. MTA-STS is would make running your own mailsever harder and leash you to one of a dozen cert authorities. If you don't think that's a problem then remember what happened to dot org, and think what will happen to these cert authorities given enough money and time.
I've run my own mailserver for a decade now and I am strongly against everything you suggest. But it doesn't matter what I care about. If everyone uses only one of a handful of email providers then they'll just slowly close off their walled gardens anyway. It's already happening no matter how many superfluous cargo-cult standards independent mailserver operators implement.