TLS Certificate Identity Verification Procedure for SMTP MTA to MTA Connections

The TLS security protocol is typically used to encapsulate application protocols to provide privacy, data integrity and server identity verification between two application servers which would otherwise be conducting their communication in plain text over potentially insecure network links. There are two layers: The TLS Record protocol provides for private communication and message integrity using negotiated encryption and hashing algorithms. The TLS Handshake protocol provides for secure and reliable sharing of secrets used for encryption, together with identification and authentication of one or both peers. There are various RFCs, such as which describe TLS in the context of more general domain based applications, with the canonical example being a user-agent (e.g. browser) securely accessing content on a server (e.g. web server) . RFCs also describe TLS in the more specific context of SMTP, however these RFCs focus on a user-agent (e.g. mobile or PC mail client) submitting email to a mail server using the STARTTLS SMTP extension . No RFCs explicitly describe TLS in the context of SMTP communication between two MTAs in an email network. There exist sufficient differences in the MTA-to-MTA scenario, particularly with respect to server identification, which warrant an explicit set of recommendations. This document discusses various strategies that a sending MTA can use for the identification and authentication of a destination MTA when transferring a message within an email network. It should be noted that an email network could be defined with MTA to Message Delivery Agent (MDA) connections, in which case the same verification and authentication rules should apply to the MTA to MDA scenario.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Email Domain: @example.net, found in the domain section of the RCPT TO command forward path Email Server Hostname: mail.example.net Email Server IP Address: the IP address (or addresses) for the email server. MX Record: A type of DNS record that associates an email domain to one or more email server hostnames. @example.net --> mail1.example.net, mail2.example.net. MTA (Message Transfer Agent). An application that sends messages on behalf of one or more users to a destination email server over SMTP. The destination email server will also be an MTA or a Message Delivery Agent (MDA) though this document will discuss MTA to MTA connections as the difference between MTA to MTA and MTA to MDA connections is immaterial with regard to TLS verification and authentication. Self-Hosting: The owner of the email domain also owns and manages the email server. In this case, it’s common for the email server host name to be rooted to the email domain (e.g. @example.net --> mail.example.net), but it’s not required. Many organizations have multiple email domains (e.g. @example.net, @sales.example.net, @ejemplo.es) all self-hosted on a shared email server (e.g. mail.example.net). Delegated Hosting: The owner of the email domain does not own or manage the email server. Typically, a third-party owns and manages an email server for a multiplicity of Email Domain owners. Delegation is achieved through the MX record (e.g. @example.net --> mail.delegatedexample.net). Reference Identity: An instance of a reference identifier, constructed from a source domain and optionally a service type, used by the client for matching purposes when examining presented identifiers . Presented Identity: An instance of a presented identifier that is presented by a server to a client within a PKIX certificate when the client attempts to establish secure communication with the server; the certificate can include one or more presented identifiers of different types, and if the server hosts more than one domain then the certificate might present distinct identifiers for each domain .

Two fundamental aspects govern how an MTA validates the identity of an email server when establishing a TLS session: How the reference identity of the server is determined How the presented identity of the server is validated against the reference identity The destination MTA identity is verified through a process of ordered comparison of reference and presented identity pairs in conformance to the rules defined in .

In the case of an MTA, the reference identity of the destination email server is typically expressed via the MX record for the recipient email domain. A user addresses email to a recipient at a specific email domain (e.g. recipient@example.net) and the MTA then performs a DNS MX query using the domain section of the RCPT TO command forward path to determine the email server hostname (e.g. mail.example.net) for the recipient email domain. It is important to note that the email server name will not necessarily be a subdomain of the recipient email domain; this will never be the case with delegated email hosting.

The server presented identity SHOULD be a SubjectAltName (SAN) of type DNSName of a X.509 public key certificate. In keeping with , SAN entries SHOULD be used for the presented identity, but the CN entry of a X.509 public key certificate MAY be used for backwards compatibility with deployed infrastructure if no SAN entries exist in the certificate.

recommends deprecating support for SAN entries that include wildcards for two primary reasons: (1) the lack of clarity in existing specification as to the allowable locations of wildcard characters and (2) the fact that a wildcard SAN entries vouches for all servers in a domain, including possibly rogue or buggy servers. In the case of MTA to delegated email service connections, this document proposes continued support for DNSNames containing wildcards as wildcard DNSNames are needed to support some delegated email hosting scenarios. For delegated hosting, some third parties may use the same email server hostname(s) for all the domains that they host: @example1.net --> mail.delegatedexample.net @example2.net --> mail.delegatedexample.net Alternatively, a third party email service might use a unique hostname for each email domain: @example1.net --> example1net.mail.delegatedexample.net @example2.net --> example2net.mail.delegatedexample.net If unique hostnames are associated with each email domain, then there will be as many host names as email domains and it will not be possible to include all hostnames as SAN DNSName entries in a certificate. Wildcarded SAN entries would then be the only mechanism by which a single certificate may be used for all email server hostname reference identities. If all the email server hostnames are of the form [domainidentifier].[hostnameroot] (e.g. example1net.mail.delegatedexample.net), then the SAN SHOULD include a DNSName entry of the form *.[hostnameroot] (e.g. *.mail.delegatedexample.net). The email server certificate SHOULD NOT include a wildcard character in the presented identity in any position other than the left-most label.

Validation of the server identity entails a comparison of the reference identity to the identity presented in the server certificate. There are several approaches for validation, given the various reference identifiers that may be used and the fundamental difference between the self-hosted and delegated hosting models.

The reference identity for an email server SHOULD be determined using the following methods: 1. The domain section of the RCPT TO command forward path 2. The email server hostname explicitly configured in the MTA by an administrator. 3. The email server hostname derived via a DNS/MX query against the email domain name determined as the domain section of the RCPT TO command forward path.

An MTA SHOULD validate an email server identity when an exact match exists between the presented identity as a SAN DNSName entry in the email server's certificate and the email server's reference identity.

An MTA SHOULD validate an email server identity when a Section 6.4.3 compliant wildcard match exists between the presented identity as a SAN DNSName entry with wildcards in the email server's certificate and the email server's reference identity.

For backward compatibility, if no SAN DNSName entries exist in an email server's certificate but a CN entry exists then an MTA SHOULD validate an email server identity if an exact match exists between the CN and the email server's reference identity.

For backward compatibility, if no SAN DNSName entries exist in an email server's certificate but a CN entry exists then an MTA SHOULD validate an email server identity when a Section 6.4.3 compliant wildcard match exists between the presented identity as a CN entry with wildcards in the email server's certificate and the email server's reference identity.

The order of evaluation of the different methods for an MTA to validate and email server identity are important and an MTA SHOULD use the following ordering of matching tests:

If one or more SAN DNSName entries are present in the email server's certificate the following matching tests SHOULD be used in the order specified: 1. Exact match of SAN entry to domain section of the RCPT TO command forward path 2. Wildcard match of SAN entry to domain section of the RCPT TO command forward path 3. Exact match of SAN entry to email server hostname explicitly configured in the MTA by an administrator. 4. Wildcard match of SAN entry to email server hostname explicitly configured in the MTA by an administrator. 5. Exact match of SAN entry email server hostname derived via a DNS/MX query against the domain section of the RCPT TO command forward path. 6. Wildcard match of SAN entry email server hostname derived via a DNS/MX query against the domain section of the RCPT TO command forward path. If one or more SAN DNSName entries are present in the email server's certificate and none of the matching tests specified above pass, then the MTA will have failed to validate the email server's identity. and the MTA SHOULD log an error indicating that the validation process failed.

An MTA MUST NOT validate an email server identity against the CN entry of an email server's certificate if there exist one or more SAN DNSName entries in the certificate. If and only if no SAN DNSName entries exist in the email server certificate and a CN is present in the email server's certificate the same matching process detailed in 4.1.4.6.1 above MUST be used with the CN as the presented identity instead of the SAN.

This document addresses only the procedure by which an MTA should verify the identity of an email server with which it wishes to establish a TLS connection. The procedures described in this document do nothing to address or ameliorate the fundamental security risk associated with obtaining an email server name through an insecure MX query. In the abscence of DNSSEC there exist a large number of techniques whereby a false email server name could be returned to the MTA through an insecure MX query. It should be noted that in the absence of DNSSEC, the MX query is no more risk prone than a browser A lookup. Use of TLS eliminates risks of passive listening and imposes a requirement that an attacker to obtain a certificate that will be trusted by the sending MTA and actively participate in the session by terminating the TLS session requested by the sending MTA. Risks associated with insecure DNS MX lookups may be ameliorated by explicit association of the email server name to an email domain in the MTA configuration.

This document includes no request to IANA.

Thanks to Dan Wing for multiple reviews of this draft and valuable suggestions for improving it.