Blog
Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
Update (23 April 2019): Gmail has become the first major email provider to support MTA-STS and TLSRPT, making it easier to justify deploying these new standards. More information is available in their blog post.
SMTP TLS Reporting (or TLS-RPT for short) is a new standard that enables reporting of TLS connectivity problems experienced by applications that send email. The standard is documented in RFC 8460, which was released in September 2018. We've extended Hardenize to look for and test TLS-RPT policies in all assessments.
TLS-RPT is being released at a time when TLS and PKI have just about recovered from an onslaught of problems that began to circulate at around 2008 or so. 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 plaintext email.
As on the Web, the answer is to opt into better security, for example using DANE or MTA-STS. However, one problem remains: what if the remote servers can’t connect for whatever reason? And so now we have TLS-RPT, which aims to fill this gap and enable diagnostic reporting to support monitoring and troubleshooting of connectivity issues.
Technically, it’s trivial to start using TLS-RPT; you only need to add a TXT DNS record in the
correct location, prepending _smtp._tls. to your domain name:
_smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
After this, compliant 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 traffic statistics and, optionally, failure information.
It practice, even though you can enable TLS-RPT, you’re not going to receive many reports, because there isn’t much support on the sending side at this time. So for now, this is something you can do to feel that you’ve done your bit for supporting modern standards, but 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 have for DMARC today.