It's irritating (to say the least) that we have a distributed information service (DNS) that so botched its security implementation that logical things like storing public keys now require a web server, running http (!) and allowing a GET on /.well-known/blah
Is there no alternatives to DNSSEC that would have allowed the equivalent of DANE to be provided somehow?
I was told on the MTA-STS working group list that well-known URIs were chosen because the working group did not think email server administrators were smart enough to use DNSSEC.
I also asked why this is better than just standardizing on a port and using SMTP over TLS with existing certificate infrastructure, but they did not answer that question.
Even if you enforce SSL-only on inbound mail, you're still vulnerable to the downgrade attack (or rather: the "prevent upgrade to TLS attack") - someone can MITM, and the sender will be speaking non-SSL to the MITMer, who'll speak SSL to you. To you things would look fine.
Enter MTA-STS, with which the sending mail server can deduce that no, things are not OK.
Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.
MTA-STS is still vulnerable to MITM. If someone can tamper with DNS queries, it's useless. It's also apparently useless for the first message because the policy will not be in cache and only fetched afterwards.
We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.
That's a hard choice. Google reports that 2% of the email they send goes out unencrypted, it's too large a percent to ignore. If you are using Postfix, would you mind sharing which setting you use? They all have challenges.
Blog author here, great question. I think HTTPS was chosen because, as an industry, we have exceptional knowledge of how to securely serve static web content. Some folks are using GitHub Pages for their mta-sts subdomain, for example. It's quite painless to set up and easy to reason about the security it provides.
Using TLS provided by the mail server may have been possible, similar to how the HSTS header is sent over the HTTPS connection. But unfortunately the MTA-STS policy if for the receiving domain (@example.com) and the receiving mail server may be run on a completely different domain. We need a signal that cryptographicly relates to the receiving domain.
Blog author here. There's two parts to get it working on Postfix:
To enable MTA-STS for inbound email: Add DNS entries for the MTA-STS record and mta-sts.<domain>. Run a web server that serves the mta-sts.txt file (or use static hosting, like GitHub pages/Netlify/AWS S3/etc). Set up HTTPS on the web server. The repo in the post shows an NGINX approach with Let's Encrypt.
To enable MTA-STS for outbound email: you'll need to configure https://github.com/Snawoot/postfix-mta-sts-resolver. Be sure to read through the DANE related challenges in the README as there are some tradeoffs.
It's irritating (to say the least) that we have a distributed information service (DNS) that so botched its security implementation that logical things like storing public keys now require a web server, running http (!) and allowing a GET on /.well-known/blah
Is there no alternatives to DNSSEC that would have allowed the equivalent of DANE to be provided somehow?
I was told on the MTA-STS working group list that well-known URIs were chosen because the working group did not think email server administrators were smart enough to use DNSSEC.
I also asked why this is better than just standardizing on a port and using SMTP over TLS with existing certificate infrastructure, but they did not answer that question.
Defaulting to SSL only is the easiest way. I'm surprised the industry has not moved on yet ... my mail server enforces SSL only.
Even if you enforce SSL-only on inbound mail, you're still vulnerable to the downgrade attack (or rather: the "prevent upgrade to TLS attack") - someone can MITM, and the sender will be speaking non-SSL to the MITMer, who'll speak SSL to you. To you things would look fine. Enter MTA-STS, with which the sending mail server can deduce that no, things are not OK.
Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.
MTA-STS is still vulnerable to MITM. If someone can tamper with DNS queries, it's useless. It's also apparently useless for the first message because the policy will not be in cache and only fetched afterwards.
We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.
That's a hard choice. Google reports that 2% of the email they send goes out unencrypted, it's too large a percent to ignore. If you are using Postfix, would you mind sharing which setting you use? They all have challenges.
Blog author here, great question. I think HTTPS was chosen because, as an industry, we have exceptional knowledge of how to securely serve static web content. Some folks are using GitHub Pages for their mta-sts subdomain, for example. It's quite painless to set up and easy to reason about the security it provides.
Using TLS provided by the mail server may have been possible, similar to how the HSTS header is sent over the HTTPS connection. But unfortunately the MTA-STS policy if for the receiving domain (@example.com) and the receiving mail server may be run on a completely different domain. We need a signal that cryptographicly relates to the receiving domain.
Is there a recommended setting for Postfix users based on this article?
Blog author here. There's two parts to get it working on Postfix:
To enable MTA-STS for inbound email: Add DNS entries for the MTA-STS record and mta-sts.<domain>. Run a web server that serves the mta-sts.txt file (or use static hosting, like GitHub pages/Netlify/AWS S3/etc). Set up HTTPS on the web server. The repo in the post shows an NGINX approach with Let's Encrypt.
To enable MTA-STS for outbound email: you'll need to configure https://github.com/Snawoot/postfix-mta-sts-resolver. Be sure to read through the DANE related challenges in the README as there are some tradeoffs.