No, it's bottom-up in that it's deployed at endpoints and does not require universal deployment, or root-to-branch continuity, in order to function. DNSSEC requires a global PKI, with cryptographically signed delegations from the DNS roots through TLDs run by governments all the way to every involved system; it's only been in the last 10 years that it has even been technologically possible to accomplish this (MTA-STS could have been deployed in 2005).
MTA-STS doesn't prevent non-TLS SMTP servers from functioning; all it does is ensure that if you have TLS, that attackers can't strip it.
If you have enough faith in ICANN to vest control of Internet trust in them, that's, well, you do you.
DANE doesn't require universal deployment of DNSSEC either. The sending mail server only needs DNS resolvers that are transparent to DNSSEC. Which is just about everything. And you can also run a modern recursive resolver on mail server itself if you are behind an old one.
DANE does not prevent non-DNSSEC or non-TLS SMTP servers from functioning. And of course, it actually prevents MITM attacks from stripping TLS.
Just about every 'government run' ccTLD is DNSSEC signed. There is nothing that prevents a site from using DNSSEC.
The gTLDs are not government run. There is no government involvement in google's TLD (.google). And because of ICANN rules, .google is actually DNSSEC signed.
So can we use DNSSEC for email today. Everything is in place and if you don't like governments, stick to gTLDs.
Ostensibly, you're saying, not all of the gTLDs are government run. Of course, the most important TLDs are in fact run by governments, in particular the FVEY SIGINT governments and China.
.GOOGLE is "actually DNSSEC signed", but, of course, GOOGLE.COM (and GMAIL.COM) --- the domains that actually matter --- aren't.
My purpose on this subthread isn't to litigate DNSSEC, but rather to back up the rather straightforward observation that MTA-STS is a bottom-up point solution that doesn't depend on the deployment of a global PKI, and that DANE is the opposite of that. The two aren't comparable. As I said, MTA-STS could have been deployed in 2005, or, for that matter, all the way back into the Netscape TLS days.
Since the purpose of MTA-STS is to avoid DNSSEC (that's not my observation, it's stated directly in the RFC), and the standard's foremost and first adopter is Google, which, like virtually every major tech company excepting Cloudflare (which sells DNSSEC services), does not use DNSSEC, I think we can safely predict that we will not be using DNSSEC for email today.
Maybe you can expand a bit on how the receiving MTA can have certificates (both for the HTTPS part and the SMTP-TLS part) that are signed by a CA trusted by the sender?
Currently we have only one system for doing that (at scale) and that is the current global PKI system. The situation would have been much worse 10 years ago because many organizations were not using HTTPS at the time, partly because obtaining certificates was expensive and a lot of work.
DNSSEC has a single root which is recognized by everybody doing DNSSEC.
In contrast, the collection of TLS CAs is only losely defined. For example, there is a java application that I use. The java libraries do not recognize the CA used by the Dutch government. So after each update of the libraries, things start failing again. We can expect the same for MTA-STS unless everybody sticks to the CAs that are trusted by common browsers.
Bottom-up security doesn't work on a global scale. It somewhat works for ssh, because that is mostly local. It completely fails to work at scale for pgp.
At this point I'm just happy to see we're on the same page about MTA-STS being a bottom-up mechanism. I don't really care whether you think it will work well. MTA-STS addresses a problem I myself don't much care about (I'm convinced email security is an oxymoron). I'm interested in it primarily for the signal it sends about major providers intentions with respect to DNSSEC.
MTA-STS doesn't prevent non-TLS SMTP servers from functioning; all it does is ensure that if you have TLS, that attackers can't strip it.
If you have enough faith in ICANN to vest control of Internet trust in them, that's, well, you do you.