Simple Mail Transfer Protocol (SMTP) Transport Layer Security Reporting (TLS-RPT for short) is a new standard (RFC 8460) that enables reporting of TLS connectivity problems experienced by applications that send email.
Hardenize—a free tool for comprehensive network and security configuration assessment—has been extended to look for and test TLS-RPT policies in all assessments.
Figure 1 — The network and security configuration assessment tool, Hardenize, now has SMTP TLS-RPT testing capabilities.
TLS-RPT is being released at a time when TLS and Public Key Infrastructure (PKI) have just about recovered from an onslaught of problems that began to circulate around 2008. It took ten years and dozens of issues, and it looked quite dire at times, but the ecosystem recovered.
In 2018, we are so much more knowledgeable than we were, most of the infrastructure is running TLS 1.2, TLS 1.3 has just been released, and we have Certificate Transparency to keep an eye on the PKI ecosystem.
Even though we’re encrypting more email than ever before, it’s arguable that SMTP security lags behind that of the web. At the core lies fear of losing valuable email messages.
As a result, sending servers can’t expect to see valid certificates and strong encryption; receiving servers enable a wide variety of encryption standards (including some weak and insecure ones), as well as accept plain text email. With the underlying DNS remaining insecure in most cases, it is trivial for active network attackers to intercept email delivery by responding with rogue MX servers.
As on the web, the answer is to opt-in to better security, for example using DANE or MTA-STS. However, one problem remains: what if the remote servers can’t connect for whatever reason? How are you going to find our that you’re losing email?
TLS-RPT aims to fill this gap and enable diagnostic reporting to support monitoring and troubleshooting of connectivity issues.
Enabling TLS-RPT
Technically, it’s trivial to start using TLS-RPT; you only need to add a TXT DNS record in the correct location, prepending the prefix _smtp._tls. to your domain name:
_smtp._tls.example.com. 300 IN TXT \
"v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
After this change, compliant Mail Transfer Agents (MTAs) will begin to send reports to the designated email address. The reports are expected to cover a period of one day and convey the [DANE and MTA-STS] policies observed by the senders, as well as traffic statistics and, optionally, failure information.
It practice, even though you can enable TLS-RPT, you’re not going to receive many reports at this point in time, because there isn’t currently much support on the sending side. Therefore, this is something you can do to feel that you’ve done your bit for supporting modern standards for now; we’ll have to wait until some time in the future to reap the benefits of the reporting.
Of course, once we reach that point, we’ll have another problem, which is how to process and analyze the many reports. For that we’ll need specialized tools, like the ones we currently have for Domain-based Message Authentication, Reporting and Conformance (DMARC).
Adapted from original post which appeared on the Hardenize Blog.
Ivan Ristić is the founder of Hardenize, which provides continuous monitoring of network and security configuration, certificates, and Certificate Transparency.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Best blog ever provide all the information about SMTP.