Microsoft's TLS-RPT Implementation and Its Impact on Email Security
Email security is a critical concern for organizations worldwide, with protocols like DANE (DNS-based Authentication of Named Entities) and MTA-STS (SMTP Mail Transfer Agent Strict Transport Security) playing pivotal roles in safeguarding email communications. These protocols help enforce security measures that prevent man-in-the-middle attacks and ensure email transport is conducted over encrypted channels. However, the effectiveness of these security measures can be undermined by inadequate support and implementation of related technologies, such as TLS Reporting (TLS-RPT). A notable example of this issue involves Microsoft's handling of TLS-RPT, particularly concerning how it manages domains with multiple Aggregate Report URI (rua) endpoints.
What is TLS-RPT?
TLS-RPT is a mechanism (RFC8460) that allows domain owners to receive reports about TLS connectivity issues encountered by sending servers while delivering emails. These reports are vital for administrators to identify and rectify misconfigurations or potential security threats affecting email delivery and integrity.
Microsoft's Implementation issue
Last week, Nigel Pentland, a security specialist and URIports user, reported that Microsoft TLS-RPT reports were not being processed at URIports, while they were received at his email address. After a thorough investigation, it turns out that Microsoft sends reports only to the first specified rua endpoint in the DNS record, neglecting any subsequent addresses listed. This behavior leads to a significant gap in the reporting mechanism, where critical alerts may not reach all intended monitoring systems like URIports.
RFC Compliance
The TLS-RPT RFC section 3 states that the reporter MAY attempt to deliver to each of the specified rua destinations. So, although Microsoft's implementation technically adheres to this standard, it fails to provide redundancy.
Statistics
Currently, the largest providers of TLS-RPT reports, in order of volume, are Google, Microsoft, Comcast, Mail.ru, and Mimecast. By cross-referencing the domain's TLS-RPT records with the reports received, it became evident that domains with multiple rua endpoints that did not configure URIports as their first rua endpoint received significantly fewer reports from Microsoft than all other report providers. Although some reports from Microsoft were still received, they were not sent directly by Microsoft but were instead forwarded.
Organization | Max URI | Note |
---|---|---|
Google Inc. | 10 (+)? | 10 tested |
Microsoft Corporation | 1 | |
Comcast | ? | |
Mail.ru | 10 (+)? | 184 character limit |
Mimecast | 8 |
Consequences for DANE and MTA-STS
The impact of this implementation extends particularly to the domains that employ DANE and MTA-STS protocols. Both protocols rely heavily on properly implementing TLS-RPT to monitor and address potential security concerns in email transport. By not distributing TLS-RPT reports to all specified rua endpoints, Microsoft potentially hampers domain administrators' ability to gain a comprehensive view of their email security posture.
Looking Forward
Domain owners using TLS-RPT should be aware that reports might only be sent to the first specified address. To ensure all your monitoring solutions receive the report data, consider setting up a forwarding address at a different domain using a different MTA.