The entire idea behind STS protocols is to use continuity schemes to defeat downgrades. It's literally the only threat model.
These domains wouldn’t have MX or TLSA records unless they were doing email.
Even if a zone is pre-signed, an admin has to intentionally create DANE records, which they wouldn’t do unless they were hosting SMTP servers.
But it does show the statement that DNSSEC, DANE and TLSA aren’t used for secure email to be utterly untrue.
MTA-STS has other issues:
* Authenticates domain control via CA leap of faith
* Vulnerable to MiTM at cert bootstrap
* Vulnerable to weakest root CA, and unauthorized certs
* Open to downgrade on first (or irregular) contact
* Complex mix of HTTPS, unsigned DNS and SMTPI'm having a hard time articulating how silly it is to try to dunk on MTA-STS for being "vulnerable" to downgrade attacks; it's like trying to say that HSTS is vulnerable to SSL-stripping attacks. You have to not understand the idea behind the attack or the countermeasure to lead with that argument.
DNSSEC, DANE and TLSA are widely used to secure SMTP servers. From the web page showing the nearly 2 million domains with signed MX and DANE records [1]:
The following graph depicts the number of domains that have deployed DANE/SMTP. Specifically, their zone is signed, their MX records all point to hosts that have DANE TLSA records.
Regarding MTA-STS, it's a work-around for the large global email providers that can’t implement DNSSEC for a variety of reasons.
Again, MTA-STS has problems, the main one is being susceptible to downgrade attacks because MTA-STS doesn’t use DNSSEC. An attacker can MiTM a connection preventing a TLS connection.
The MTA-STS RFC [2] confirms this:
There’s no dispute about any of this, so it’s not clear why you continue to make false and misleading statements about these technologies, regardless of your opinions about them.You know the old saying: you’re entitled to your own opinion but not your own facts.
[1]: https://stats.dnssec-tools.org/#dnssec
[2]: https://tools.ietf.org/html/rfc8461#section-2
A more complete description I posted previously: https://news.ycombinator.com/item?id=22338742