Secure SMTP/TLS SRV Announcement

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 July 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

4. IANA Considerations

The author does not expect IANA to add a dedicated port for "Implicit TLS SMTP", given that it has registered according ones for other email protocols, for example POP3S, no sooner but 1999, a quarter of a century ago. The author nonetheless asks for assigning a dedicated port for Implicit TLS SMTP, and suggests port 26 (which, at the time of this writing, was already successfully used for that purpose) in the privileged port range. The author wants to point out that the contra arguments given in section 7 of [RFC2595] that created according POP3S and IMAPS assignments in 1999 are contradicted by operational reality in the internet, and here that includes the IETF by means of [RFC8314]. A dedicated port enabled administrators to apply strict policies, for example in firewalls.¶

5. Security Considerations

This specification avoids downgrade attacks on the opportunistic approach of STARTTLS, accomplished via the mechanism used for many other IETF standardized protocols, most notably [RFC2782] (IMAP, POP3, SUBMISSION). With its Implicit TLS capability it grants the SMTP protocol the same level of confidentiality through TLS[RFC8446] as is already standardized for the other email protocols; this is considered a value by itself, even for the possibly lesser sensitive MTA to MTA communication. Implicit TLS reduces the number of packet roundtrips, that at a protocol stage where the widely used "pipelining" (RFC 2920) performance improvement extension cannot be used; it must be said that today these roundtrips are anachronistic (also environmentally): for example the over four million known DANE for SMTP[RFC7672] enabled servers at the time of this writing alone, which MUST use TLS by standard definition, likely generate (several) billion(s) of useless sequential and blocking roundtrip packets each and every day. The security of DNS[RFC1035] is out of scope for this specification, but DNSSEC[RFC4033][RFC4034][RFC4035] and secure DNS transport[RFC7858][RFC8094][RFC8310][RFC9250] etc exists. Selection of the appropriate transport layer security protocol is out of scope for this specification, see for example TLS[RFC8446].¶

Appendix A. Rationale

Plenty of methods have been standardized by the IETF to perform service TLS capability discovery for SMTP. They have in common that they represent SMTP specific solutions to a problem that other protocols address via means this ocument thus reiterates for SMTP. They represent further development effort and error surfaces. They also impose increased permanent administration effort, and, due to this, are inaccessible to a large number, if not the majority, of private email server operators: either through additional costs, the impossibility to set up a dedicated name server, if so required, and, also as a superset of the former, restrictive web interfaces that support only a minimal set of DNS[RFC1035] resource record types. Regardless the fact that several of these extensions switch the SMTP protocol to a MUST usage of TLS, they still require the additional STARTTLS plus HELO roundtrips that for example [RFC8314] disregards; and even though that RFC explicitly refers to DANE for SMTP[RFC7672], giving no reason for why SMTP "requires a different approach", except for the TLS certificate discovery that could and should be hoped for as a general solution, including for clients for any sort of network protocol, DANE falls in this category, too: what this specification tries to achieve is therefore not counteracting [RFC7672], but accompanying it; the author wants to state again that according mechanisms already exist in active use, and that many SMTP client/server software implementations already support SRV RR lookups: activating this existing code base by standard means is only a consequence.¶

The other extension that [RFC8314] mentions, MTA-STS[RFC8461], requires SMTP operators to install and maintain an additional HTTP protocol server, accessible on the usual HTTP/S ports and the same domain as the email service. Dependent on the software this may require non-trivial and error prone path access policy server rules. It is a complicated to implement approach that brings the complexity of another network protocol in the SMTP path; given that several different HTTP protocols exist, which in turn base upon several different transport protocols, the complexity and protocol is alien to SMTP. The SVCB[RFC9460] DNS approach would not bring additional value to the problem in question, but on the other hand requires additional implementation efforts as email protocols do not make any use of it as of today.¶

Coming back to DANE for SMTP[RFC7672] it must be said that unfortunately DNSSEC[RFC4033][RFC4034][RFC4035] is still consciously unsupported by major players as of today. Furthermore provider web interfaces do often not allow users creation of the necessary DANE TLSA resource records; not always can the answer be "run your own name server", also letting aside the administrative effort of doing so. However, discovering an Implicit TLS enabled email service via the _smtps._tcp SRV record, thereafter checking for applicability of DNS-Based Authentication of Named Entities (DANE)[RFC6698], possibly even Using Raw Public Keys in Transport Layer Security (TLS)[RFC7250] would be a bright future that addresses possibly all of today's issues.¶

Appendix B. Acknowledgements

Thanks to Jan Ingvoldstad for remarks on the missing rationale. Thanks to Jeremy Harris for spending time and revealing the many problems of early draft variants, we well as comments on how to do it better; very special thanks to him for a kickstart implementation of this very draft in the widely used exim Open Source MTA. Jeremy Harris, Viktor Dukhovni and Wietse Venema commented on the initial odd usage of port 0 for the STARTTLS discovery case.¶

Author's Address