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:
The DNS-Based Authentication of a Named Entities (DANE)TLSA
record [RFC7672] is similar, in that DANE is also designed
to upgrade unauthenticated encryption or plaintext
transmission into authenticated, downgrade-resistant
encrypted transmission. DANE requires DNSSEC [RFC4033] for
authentication; the mechanism described here instead relies
on certification authorities (CAs) and does not require
DNSSEC, at a cost of risking malicious downgrades.
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
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.
Here's a short list of domains that are using DNSSEC, DANE and TLSA to protect their email. I also provide a transcript of a utility that connects to and verifies the SMTP server and the DANE/TLSA records for openssl.org and could have done so for every domain on this list but there's no reason to get carried away.
* geektimes.com
* gmx.com
* mail.com
* comcast.net
* dd24.net
* debian.org
* freebsd.org
* gentoo.org
* ietf.org
* isc.org
* netbsd.org
* openssl.org
* samba.org
* torproject.org
There's a DANE TLS SMTP server checking tool: https://www.huque.com/bin/danecheck-smtp
Here's what it does: This application checks a DANE SMTP Service. It queries the MX record set for the given domain, looks up DANE TLSA records at the MX targets, connects to the target servers, negotiates STARTTLS, and then attempts to verify the TLS server certificate against the TLSA records.
Lets test openssl.org:
Domain Name: openssl.org
MX host: 50 mta.openssl.org
#################################################################
### CHECKING MX HOST: mta.openssl.org
#################################################################
TLSA records found: 1
TLSA: 3 1 1 6cf12d78fbf242909d01b96ab5590812954058dc32f8415f048fff064291921e
Connecting to IPv6 address: 2001:608:c00:180::1:e6 port 25
recv: 220-mta.openssl.org ESMTP Postfix
recv: 220 mta.openssl.org ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-mta.openssl.org
recv: 250-PIPELINING
recv: 250-SIZE 36700160
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
1 Subject CN: Let's Encrypt Authority X3
Issuer CN: DST Root CA X3
SAN dNSName: mta.openssl.org
DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0
Validated Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
SAN dNSName: mta.openssl.org
Connecting to IPv4 address: 194.97.150.230 port 25
recv: 220-mta.openssl.org ESMTP Postfix
recv: 220 mta.openssl.org ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-mta.openssl.org
recv: 250-PIPELINING
recv: 250-SIZE 36700160
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
1 Subject CN: Let's Encrypt Authority X3
Issuer CN: DST Root CA X3
SAN dNSName: mta.openssl.org
DANE TLSA 3 1 1 [6cf12d78fbf2...] matched EE certificate at depth 0
Validated Certificate chain:
0 Subject CN: mta.openssl.org
Issuer CN: Let's Encrypt Authority X3
SAN dNSName: mta.openssl.org
[0] Authentication succeeded for all (2) peers.DNSSEC standardization began in NINETEEN NINETY FIVE. That's twenty five years ago. They got GENTOO.ORG. That's the win you're crowing over. Congratulations! As goes GENTOO.ORG, so too goes the Internet.
Breaking news: there are other applications on the internet other than browsers.
And some of them use TLSA records. It’s the de facto standard for for secure email, especially if you want guaranteed protection from downgrade attacks.