We are responding to the proposal for requiring MTA-STS for securing E-Mail traffic within government networks. We have reviewed the proposal and request that the government reconsider the choice of MTA-STS as it is inferior to DANE-SMTP. The U.S. government is well positioned to deploy the superior DANE-SMTP since approximately 86% of federal .GOV domains are DNSSEC signed.
We believe that the U.S. Government’s selection of MTA-STS is driven by the desire to leverage cloud-hosted E-Mail solutions coupled with a perception that cloud E-Mail hosting providers can largely support only MTA-STS and not DANE-SMTP with DNSSEC.
In this response, we explain why DANE-SMTP is equally viable in the cloud, in government networks in general, provides better security than MTA-STS, avoids needless trust in potentially hostile nation-state CAs, is substantially more broadly deployed than MTA-STS and offers better interoperability with the broader Internet E-Mail ecosystem.
Two different IETF protocols are defined for protecting server to server (MTA-to-MTA) SMTP transport against active attacks. They each have different deployment and security properties, which is the basis for why two different solutions exist.
DANE-SMTP (RFC7672) uses DNSSEC to ensure:
The integrity of the MX records of the receiving domain, preventing DNS cache poisoning or other MiTM attacks from redirecting E-Mail to rogue servers.
Downgrade-resistant publication of DANE TLSA records that make it possible for SMTP clients to properly authenticate the TLS certificate of the MX hosts they are sending mail to, thereby ensuring that network-layer attacks (BGP hijacks, …) cannot hijack SMTP traffic. SMTP’s STARTTLS feature alone cannot prevent these attacks.
The design rationale of DANE-SMTP can be found in Section 1.3 of RFC 7672
MTA-STS (RFC8461) is a less secure E-Mail protection mechanism,per its own specification description, than DANE-SMTP. It is useful only for domains that are for some reason unable to deploy DNSSEC. Its weaknesses are also documented in its specification in Section 10 of RFC8461.
MTA-STS publishes policy via a combination of untrusted DNS TXT records that signal the expected presence of an MTA-STS policy at a well-known URL for the receiving domain. MTA-STS requires implementation of an additional Internet protocol – HTTPS – within the SMTP mail delivery process. MTA-STS also relies on senders maintaining long-term policy caches. The use of these caches fail to protect traffic to E-Mail service to domains that are not yet in or have expired from the policy cache. This amounts to accepting “trust on first use” as an acceptable security policy, unlike DANE-SMTP which always guarantees security.
MTA-STS, as RFC8461 itself acknowledges, is less secure than its DANE-SMTP counterpart. Specifically:
Discovery of MTA-STS policy relies on unprotected DNS TXT lookups, which can be blocked or forged by active attacks. When these lookups fail due to attacks or from operational issues, MTA-STS falls back to unauthenticated opportunistic STARTTLS which is vulnerable to active attacks.
Fallback to insecure SMTP delivery on an SMTP client’s failure to look up the MTA-STS TXT record happens even when a domain is protected by DNSSEC, and thus DNSSEC itself is not a sufficient solution to this problem. MTA-STS policy discovery is designed to effectively be “best-effort” by falling back to insecure delivery.
MTA-STS SMTP clients must unavoidably trust the full set of WebPKI public Certification Authorities when validating the SMTP server’s X.509 certificates they connect to. In order to ensure E-Mail delivery around the world, the list of trusted CAs necessarily includes CAs operated by nation states potentially hostile to the USG.
In contrast, DANE-SMTP trusts only the DNS keys leading from the root zone to the E-mail recipient’s domain and to the domain of the E-Mail hosting provider (if the domain’s SMTP server is not self-hosted). Unlike with WebPKI, the keys of unrelated TLDs and parent domains are not trusted when delivering to a given (e.g. a subdomain of .GOV) recipient domain.
The MTA-STS specification acknowledges these weaknesses in section 10 and section 2 which notes (last paragraph) that in order to avoid downgraded security MTA-STS success must not preempt DANE-SMTP policy failure.
In the past, DNSSEC, which is required for DANE-SMTP, was difficult to deploy and maintain. However, recent advances in authoritative server technologies have substantially addressed these concerns. For example, recent versions of BIND and Knot DNS have received high praise for their ability to automate management of DNSSEC signed zones with little burden on DNS operators.
Presently, there are over 16 million DNSSEC-signed domains and growing. An even more significant increase is expected shortly as GoDaddy, which controls 40% of the DNS registrar market space, starts rolling out DNSSEC support planned for hopefully Q4 2021. They have recently shared their technical plans to deploy DNSSEC to a substantial fraction of customer domains at recent DNS-OARC and ICANN DNS workshops .
DNS TXT record data collected by Rapid7’s Project Sonar combined with a poll of any associated MTA-STS HTTPS policy records identifies just over 3000 domains with an MTA-STS “enforce” policy. Most of these are SOHO domains, and only 16 are in the Tranco top 1 million list:
| Domain | Tranco Rank |
|---|---|
| mail.ru | 121 |
| gmail.com | 339 |
| wp.pl | 1313 |
| googlemail.com | 21216 |
| sudo.ws | 75948 |
| list.ru | 88540 |
| socketlabs.com | 96678 |
| servus.at | 141528 |
| cybre.space | 147271 |
| bk.ru | 239940 |
| twinhelix.com | 262763 |
| inbox.ru | 310966 |
| courtesan.com | 447401 |
| azulle.com | 505453 |
| testssl.sh | 621273 |
| incolumitas.com | 923382 |
Use of DANE to secure server-to-server SMTP traffic is growing steadily. Today, DANE-SMTP is deployed for over 2.8 million domains — roughly a thousand times more than the number of MTA-STS domains.
There are 3701 DANE-SMTP protected domains in the Tranco top 1 million list, and 280 have ranks above all but the top 4 MTA-STS domains. The top 32 Tranco DANE-SMTP domains and their ranks are:
| Domain | Tranco Rank |
|---|---|
| debian.org | 276 |
| ietf.org | 321 |
| xfinity.com | 695 |
| web.de | 806 |
| gmx.net | 942 |
| openssl.org | 974 |
| freebsd.org | 996 |
| army.mil | 1206 |
| bund.de | 1252 |
| navy.mil | 1336 |
| comcast.net | 1491 |
| isc.org | 1711 |
| mpg.de | 1789 |
| protonmail.com | 1894 |
| cwi.nl | 2023 |
| univie.ac.at | 2379 |
| xs4all.nl | 2640 |
| one.com | 2656 |
| habr.com | 2663 |
| torproject.org | 2748 |
| startpage.com | 3290 |
| uni-muenchen.de | 3529 |
| tum.de | 3766 |
| bayern.de | 3848 |
| rijksoverheid.nl | 4196 |
| govtrack.us | 4338 |
| mail.com | 4423 |
| uib.no | 4599 |
| utwente.nl | 4651 |
| thalesgroup.com | 4753 |
| bundesregierung.de | 4804 |
| cuni.cz | 4989 |
Support for DANE and DANE-SMTP is widely available in both commercial and open source toolkits.
The majority of the domains supporting DANE-SMTP protection are hosted by cloud service providers. Some of the better known providers are:
Enabling DANE-SMTP for a DNSSEC-signed customer domain whose email is hosted by a cloud SMTP service provider requires no additional effort on the customer’s part. They just need to publish MX records that reference the cloud provider’s designated DANE-SMTP-enabled SMTP servers.
The SMTP service provider can then enable DANE-SMTP across all such customer domains simply by ensuring that their SMTP servers are likewise in a signed DNS zone, and have published the associated DANE TLSA records.
Of the major US-based cloud E-Mail providers:
Google already has DNSSEC-signed MX hosts in the form of mx[1-4].smtp.goog. The Google SMTP server certificates list these hosts, and are signed by a dedicated Google-specific issuer CA. It would take negligible effort for Google to enable DANE-SMTP for these MX hosts.
Microsoft has commited to supporting DANE-SMTP, with outbound support slated for end CY 2021, and inbound for CY 2022.
E-mail service providers can freely choose to offer multiple sets of SMTP server names to clients in order to provide different logical names best suited to a given group of customers. Consequently, deploying DANE-SMTP at cloud providers like Google and Microsoft can be achieved without requiring that any of their existing domains support DNSSEC. If a provider does not yet have a suitable DNSSEC-signed domain for providing DANE support, they can easily register a new one. (Google already has smtp.goog, and Microsoft has near-term plans to provision a new signed domain.).
Customers that desire to deploy DANE-SMTP need only point their MX records to cloud-provider SMTP server names within the service providers DNSSEC-signed domains, like the smtp.goog names. For example, a number of Google customers have elected to use the DNSSEC-signed MX names in anticipation of future DANE support, and there are open support tickets requesting that Google enable DANE-SMTP.
Google and Microsoft are the dominant email hosting providers in the U.S. market, and we see no substantive barriers to DANE-SMTP deployment by these providers. If the USG wishes to make use of these SMTP service providers, we believe they would enable DANE-SMTP quickly and easily to comply.
DANE-SMTP is already employed by DoD on the mail.mil MX hosts, which are the sole MX hosts of:
There are an additional 46 DoD domains that have partially deployed DANE-SMTP.
In networks where DNSSEC is deployed, DANE-SMTP should always be the protection mechanism of choice.
The only time in which MTA-STS should be deployed is in networks where DNSSEC security is not yet available and will not be available soon (although this space is shrinking rapidly). Since 86% of .gov domains already have DNSSEC, DANE-SMTP should be selected as the preferred E-Mail security mechanism for government networks to maximally protect USG E-Mail transmissions.
As some sending systems of interest to the USG might only support MTA-STS, it may be appropriate for a cloud hosting provider to support both MTA-STS and DANE-SMTP. In this case the USG domain would have to also publish and maintain a suitable MTA-STS policy.