We’re excited to announce that Gmail will become the first major email provider to follow the new SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 and SMTP TLS Reporting RFC 8460 internet standards. Those new email security standards are the result of three years of collaboration within IETF, with contributions from Google and other large email providers.
Google hopes other email services will also adopt these new security standards.
It seems to boil down to using publicly trusted (i.e., signed by a certificate authority) certificates for the TLS connection, and a policy that has to be published over HTTPS on a well-known URL: https://mta-sts.DOMAIN_TO_PROTECT/.well-known/mta-sts.txt .
(I think it’s rather ugly that the policy is to be retrieved over HTTPS, but I assume that is to make sure that a ubiquitously deployed authenticated protocol is used, as opposed to DNSSEC, which seems still not supported by all DNS providers.)
It seems that at least the developers of Exim have no intention of adding support for this:
https://lists.exim.org/lurker/message/20190205.235448.32406709.en.html
The mentioned arguments seem to be valid: Rather than having to trust all certificate authorities, it would be more logical to let the domain specify exactly what to trust using DANE (which requires DNSSEC to be useful, whose non-ubiquity I assume is the reason for MTA-STS to exist) Trust Anchor Assertion (DANE-TA) or Domain issued certificate (DANE-EE):
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage
Made me learn a bit more about security options for email, nice :-).
Have to say I’m also not happy with this.
This would mean: anyone who can deploy a webservice (possibly using Let’s Encrypt certificate) for a domain at mta-sts (or wildcard ?) can now control if email will be received.
This is an other ‘special name’ which can not be used by regular services: creating mta-sts.wordpress.com or mta-sts.blogspot.com, etc. thus need to be blocked.
Just like free e-mail servers can not allow people to create: [email protected], [email protected], etc.
Lennie,
I agree, it’s getting out of hand. This creates too many inter-dependencies between unrelated services. This kind of evolution in technology is adding tons of bloat and makes things more fragile, more complex, increases overhead, and increases the trusted needed between unrelated systems.
It won’t happen, but we could really use a “reboot” of many of the technologies underpinning the internet: from the 1500 byte ethernet packets to the ball of hacks that is smtp and friends.We’re running atop legacy platforms and standards that frankly were engineered for simpler times, we just keep adding kludges to work around limitations and insecurities. For most users, I suppose they don’t care about the technological state of disarray when it’s painted over with a nice facade, but for those of us who work in the industry the disorganization is a betrayal of good engineering principals.
> We’re running atop legacy platforms and standards that frankly were engineered for simpler times, we just keep adding kludges to work around limitations and insecurities.
Not that I disagree, but what would a reboot look like? In this case there’s a breakdown in the (nonexistent) trust model of SMTP, but fixing a lot of this seems to require a foundation of a trust infrastructure, which brings up all kinds of PKI politics. As I said, I agree in general, but if we could stop time and had infinite resources to rebuild everything from scratch, would we know what to build and would it really be all that different?
In other words, is there some fundamental change that’s needed but is completely incompatible with our current kludge-and-keep-moving system?
bartgrantham,
It would give us an opportunity to apply what we’ve learned to come up with better designs. All engineers make mistakes of course, whether it’s hardware, software, bridges, or sky scrapers, etc. But we learn from those mistakes so that we can do better “next time”. The problem is that when it comes to much of our internet technology, there hasn’t been a “next time”, it’s been a long continuous evolution from the beginning where we work around issues rather than fully solving them.to not have those problems.
While there are many things we can fix in the lab, the need to stay backwards compatible almost always compromises the engineering. Take SPF records, which is itself a bit of a hack for the lack of strong email sender authentication, these were meant to be stored as SPF DNS records. However many DNS providers never upgraded their DNS systems to support SPF records, consequently RFC 7208 discontinues the SPF records and recommends just dumping them into TXT records instead. Unfortunately more standards are now dumping data into TXT records, where they do not belong, for similar reasons. From an engineering perspective the fixes are quite trivial, such as revoking things like RFC 7208 that contribute to this mess, but in practice we’ve struggled to get away from this evolution baggage that makes technology worse.
Security (or lack thereof) is practically a universal shortcoming of early systems. We address it today with application level crypto, but it makes it impossible for administrators to roll out security policy across all connections. Each service requires it’s own security protocols and infrastructure. Each individual application needs to be updated to address security vulnerabilities (rather than system wide updates that could protect all communications). DNSSEC is an attempt to address some of this (in a way that’s superior to this MTA-STS standard), but once again it requires a global deployment by hosting and ISP services, which like SPF records, is not happening. I’m positive the engineers at google and microsoft thought “Hey, we know MTA-STS is a badly designed standard with spaghetti dependencies, but we’re going to promote it anyways because we’re skeptical of the world’s willingness to deploy better solutions.”
Look at ipv6. We are two decades into that transition, which everyone agrees is necessary to address the major limitations of the ipv4 internet, yet the network still lacks coverage and many ISPs & services remain exclusive to ipv4. 🙁 And the reason ipv4 remains so prominent now that there’s a better solution? Ipv6 is not backwards compatible.
I don’t think you can do wildcards with Let’s Encrypt.
So if you run your own email server, Gmail won’t deliver messages to your address unless you buy a certificate?
nicubunu,
SMTP can be delivered over TLS today, but there are a few problems with it 1) the sender doesn’t know ahead of time whether to the destination email domain (mx record) is using TLS or plaintext. 2) It’s standard practice for SMTP servers to use self-signed certificates, but the sender doesn’t know if a self-signed certificate presented by the server is a decoy.
DNSSEC/DANE were developed as a way to give domain owners a secure mechanism by which to validate TLS certificates used by services including SMTP.
https://tools.ietf.org/html/rfc7672
However ISPs and hosting providers have stubbornly dragged their feet in rolling out DNSSEC in a timely manor (rendering most of the benefits of DNSSEC mute). Consequently this new protocol was devices to work as follows:
Prior to establishing secure TLS communication to the destination SMTP server, the sending SMTP server does a DNS query for a TXT record as follows:
If this record is present, the sending SMTP server establishes an HTTPS connection, verifies the HTTPS certificate and requests the following file.
If mode==enforce, then the sending SMTP server establishes a secure TLS connection to the destination SMTP server and verifies the certificate authority. Otherwise the sending SMTP server establishes a normal TLS or plaintext connection to the destination SMTP server without verifying the certificate. The RFC goes on to cover corner cases and caching behavior. To answer your question: no, if you don’t buy a certificate nothing changes for you.
IMHO making secure SMTP TLS certificates depend on HTTPS servers is very hairy from an engineering standpoint. It adds inter-dependencies between unrelated servers & protocols. SMTP severs will need to implement an HTTPS client. It creates additional TCP sessions & traffic. Rolling this out increases complexity over installing single purpose demons like postfix/exim. Multiple certificates need to be purchased/renued to make this scheme work. Obviously there are more pieces that can go wrong. In any case, this convoluted solution is just to convey one single “mode:enforce” flag. It is so crappy that standards are evolving in this direction rather than DNSSEC & DANE, which was much better.
for certificate revocation information a HTTP client is needed, so a HTTPS client does not add much complexity.
Paulhekje,
Except there’s no reason for SMTP standards to require HTTP/HTTPS for anything. Many of us agree DNSSEC would be more appropriate…but alas I concede that may be wishful thinking since nobody’s deploying it 🙁
For what it’s worth, HTTPS certificate revocation lists have known scalability/reliability issues.
Certificate revocation lists scale very poorly well when large numbers of certificates need to be revoked. This debate came up during the heartbleed vulnerabilities where researchers succeeded in using the vulnerabilities to extract keys. So large numbers of certificates were potentially compromised.
Online certificate status protocol (OCSP) provides an alternative mechanism whereby clients can request the status of a certificate in real time, but that’s not fullproof because it does so by throwing away the properties of certificates that make them robust & scalable. If the client is configured to hard-fail (ie reject certificates when OCSP is unavailable), it makes legitimately signed certificates less robust and can result in denial of service. Consequently many browsers soft-fail instead (ie ignore OCSP unavailability), but it makes the revocations less robust.
https://news.ycombinator.com/item?id=7556909
https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox
https://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html
Ultimately the problem boils down to the non-scalable nature of certificate revocation as they’re used in HTTPS.
A better technical solution is short lived certificates (which ideally using DANE would be self-signed). You could use a new certificate every day or every week, which is more secure than what HTTPS servers typically offer through certificate authorities. Not only are short lived certificates more cryptographicly secure, but they’re more administratively secure when it comes to revocation, some browsers don’t even bother checking for certificate revocation on short lived certificates because the cons outweigh the pros.
Better standards are indeed feasible, but it’s a question of our wiliness to embrace and deploy them, IMHO it’s an engineering mistake to simply defer to HTTPS for new SMTP standards because it adds too much complexity and we can do better than that.
I implemented MTA-STA along with TLS-RPT on my workplace primary domain back in February. Started seeing TLS-RPT (RFC 8460) emails coming in from Gmail about two days ago. So they’ve started reporting. Nice compliment to DMARC reporting. However they had their MTA-STS stuff setup a couple months ago. Still have their policy set to ‘Testing’
https://mta-sts.gmail.com/.well-known/mta-sts.txt
https://www.hardenize.com/report/gmail.com/1554931211#email_mta_sts
Basically the reason why the likes of Google have gotten behind MTA-STS is that they don’t want to do DNSSEC and thus can’t use Dane. The problem still exists that someone could do a man in the middle attack on Gmail/Google name server infrastructure. One only has to look at the attack on AWS/Route53 last year which combined BGP and DNS hijacking.
Personally I believe in ‘Defence in Depth’ as result I’ve done the following:
1. DNSSEC on domain
2. Certification Authority Authorization (CAA – RFC 6844))
3. DANE records (TLSA) for both corporate website and corporate MX
4. SPF and DKIM setup
5. MTA-STS (to keep Gmail happy)
6. DMARC and TLS-RPT for reporting
At least with DNSSEC enabled I get free rrsig’s on the CAA/MTA-STS/SPF/DKIM/DMARC/TLS-RPT records.
Here’s an example of one of the TLS-RPT reports from Google:
—
This is an aggregate TLS report from google.com
–
{“organization-name”:”Google Inc.”,”date-range”:{“start-datetime”:”2019-04-11T00:00:00Z”,”end-datetime”:”2019-04-11T23:59:59Z”},”contact-info”:”[email protected]”,”report-id”:”2019-04-11T00:00:00Z_”,”policies”:[{“policy”:{“policy-type”:”no-policy-found”},”summary”:{“total-successful-session-count”:1}},{“policy”:{“policy-type”:”sts”,”policy-string”:[“version: STSv1″,”mode: testing”,”mx: ,”mx: “,”max_age: 86400″],”policy-domain”:””},”summary”:{“total-successful-session-count”:107}}]}
—
Dubhthach,
I am curious, are you merely publishing a MTA-STA policy (for others to lookup) or does your SMTP stack actually perform the HTTPS callouts, send log reports, and reject SSL connections as requested by the recipient’s policy?
If it does all the latter, what SMTP daemon are you using?
If you are looking for option which has active MTA-STS support with actual HTTPS callouts you probably should consider Postfix + postfix-mta-sts-resolver: https://github.com/Snawoot/postfix-mta-sts-resolver
Snawoot,
It was mostly out of curiosity. Personally I wouldn’t consider MTA-STS deployed without those callouts and CA enforcement since as it is designed they’re fundamental to the goal of increasing SMTP security.
Thanks for the thoughtful link. Personally I transitioned away from postfix to exim. Postfix’s numerous forking processes creates overhead, which probably doesn’t matter for small loads, but with large lists and/or small VMs it adds up quickly. So much so that I’ve opted to standardize on exim for my infrastructure. In any case I’m not in any kind of hurry to deploy MTA-STS, I’ll see how the industry evolves. I’m still cheering for DANE, although it’s possible that neither will actually gain much traction in the industry. We’ll see.