RFC 7672 Proposed Standard Transport security

SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)

This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
October 2015
Authors
V. Dukhovni, W. Hardaker
Read it
rfc-editor.org · errata · DOI

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 56 must, 17 should, 10 may.

1.1 Terminology

  • MUSTWhen name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID (or, if none are present, the [RFC6125] CN-ID) of the server certificate (see Section 3.2.3).

2.1.1 DNS Errors, "Bogus" Responses, and "Indeterminate" Responses

  • MUSTA security-aware resolver MUST be used for this specification.
  • MUSTAll "insecure" RRsets MUST be handled identically: in either case, non-validated data for the query domain is all that is and can be available, and authentication using the data is impossible.
  • MUSTAs noted in Section 4.3 of [RFC4035], a security-aware DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus", or "indeterminate".
  • MUSTIf a resolver does signal an [RFC4035] "indeterminate" security status, this MUST be treated by the SMTP client as though a "bogus" or error result had been returned.
  • MAYAn MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability, if available, to signal DNSSEC validation status based on information the stub resolver has learned from an upstream validating recursive resolver.
  • MUST NOTSecurity-oblivious stub resolvers [RFC4033] MUST NOT be used.
  • MUST NOTa security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.

2.1.2 DNS Error Handling

  • MUSTWhen a DNS lookup failure (an error, "bogus", or "indeterminate", as defined above) prevents an SMTP client from determining which SMTP server or servers it should connect to, message delivery MUST be delayed.
  • MUSTWhen a particular SMTP server is securely identified as the delivery destination, a set of DNS lookups (Section 2.2) MUST be performed to locate any related TLSA records.
  • MUSTclient MUST treat that server as unreachable and MUST NOT deliver the message via that server.
  • MUSTIf any DNS failure occurs, the SMTP client MUST behave as described in this section, by "skipping" the SMTP server or destination that is problematic.
  • MUST NOTQueries for candidate TLSA records are explicitly part of "all relevant DNS queries", and SMTP clients MUST NOT continue to connect to an SMTP server or destination whose TLSA record lookup fails.

2.1.3 Stub Resolver Considerations

  • MUSTIf at any stage of CNAME expansion an error is detected, the lookup of the original requested records MUST be considered to have failed.
  • MUSTWhether a chain of CNAME records was returned in a single stub resolver response or via explicit recursion by the SMTP client, if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure", regardless of whether or not any earlier CNAME records leading to the "insecure" record were "secure".

2.2 TLS Discovery

  • MUST NOTIn contrast, DNSSEC-validated TLSA records MUST NOT be published for servers that do not support TLS.
  • MUSTA "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document.
  • MUSTFailure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
  • MUSTA "secure" non-empty TLSA RRset where all the records are unusable: Any connection to the MTA MUST be made via TLS, but authentication is not required.
  • MUSTFailure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
  • SHOULDAn "insecure" TLSA RRset or DNSSEC-authenticated denial of existence of the TLSA records: A connection to the MTA SHOULD be made using (pre-DANE) opportunistic TLS; this includes using cleartext delivery when the remote SMTP server does not appear to support TLS.
  • MAYThe MTA MAY retry in cleartext when delivery via TLS fails during the handshake or even during data transfer.
  • MUSTAny lookup error: Lookup errors, including "bogus" and "indeterminate" as explained in Section 2.1.1, MUST result in falling back to the next SMTP server or delayed delivery.
  • MAYAn SMTP client MAY be configured to mandate DANE-verified delivery for some destinations.

2.2.1 MX Resolution

  • MUSTMX records MUST be sorted by preference; an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records.
  • MUSTIn other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel security considerations.
  • MUSTIf the MX RRset (or any CNAME leading to it) is "insecure" (see Section 2.1.1) and DANE TLS for the given destination is mandatory (Section 6), delivery MUST be delayed.
  • MAYSince the protocol in this memo is an Opportunistic Security protocol [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below), even with MX hosts obtained via an "insecure" MX RRset.
  • SHOULDSending MTAs SHOULD log unexpanded MX hostnames when these result from "insecure" MX lookups.
  • MUST NOTAny successful authentication via an insecurely determined MX host MUST NOT be misrepresented in the mail logs as secure delivery to the intended next-hop domain.
  • MUSTIn the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure", then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2.
  • MUSTTo avoid downgrade attacks, any errors during TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP server in question to be treated as unreachable.

2.2.2 Non-MX Destinations

  • SHOULDThese nameservers SHOULD provide "insecure" negative replies that indicate the nonexistence of the TLSA records, but instead they fail by not responding at all or by responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g., SERVFAIL or NOTIMP [RFC2136].
  • MUSTTo avoid problems delivering mail to domains whose SMTP servers are served by these problematic nameservers, the SMTP client MUST perform any A and/or AAAA queries for the destination before attempting to locate the associated TLSA records.
  • SHOULD NOTIf address records are found but the DNSSEC validation status of the first query response is "insecure" (see Section 2.1.3), the SMTP client SHOULD NOT proceed to search for any associated TLSA records.
  • MUSTAnd, as always, errors, "bogus" results, or "indeterminate" results for any query in the process MUST result in delaying or abandoning delivery.

2.2.3 TLSA Record Lookup

  • MUSTFor SMTP, the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator, in which case the SMTP client MUST use the appropriate number in the "_<port>" prefix in place of "_25".
  • SHOULDSuch shared end-entity TLSA records SHOULD be avoided unless the servers in question are functionally equivalent or employ mutually incompatible protocols (an active attacker gains nothing by diverting client traffic from one such server to another).
  • MUST NOTThe SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS.
  • MUSTAs noted previously (in Section 2.2.2), when no "secure" TLSA records are found at the fully CNAME-expanded name, the original unexpanded name MUST be tried instead.

3.1.1 Certificate Usage DANE-EE(3)

  • MUSTThe server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.
  • MUSTThe expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature.
  • SHOULDTLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

3.1.2 Certificate Usage DANE-TA(2)

  • MAYThe server MAY employ SNI to select the appropriate certificate to present to the client.
  • MUSTSMTP servers that rely on certificate usage DANE-TA(2) TLSA records for TLS authentication MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message even when it is a self-signed root certificate.
  • MUSTSuch servers either MUST publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE-EE(3) TLSA records.
  • SHOULDSince the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records
  • SHOULDTLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0).
  • SHOULDIn particular, the SMTP client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints.

3.1.3 Certificate Usages PKIX-TA(0) and PKIX-EE(1)

  • SHOULD NOTTherefore, TLSA records for the port 25 SMTP service used by client MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1).
  • MAYAs with any other unsupported certificate usage, SMTP clients MAY treat such records as "unusable".

3.2 Certificate Matching

  • MUSTWhen at least one usable "secure" TLSA record is found, the SMTP client MUST use TLSA records to authenticate the SMTP server.
  • MUST NOTMessages MUST NOT be delivered via the SMTP server if authentication fails; otherwise, the SMTP client is vulnerable to MITM attacks.

3.2.1 DANE-EE(3) Name Checks

  • MUST NOTThe SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3) (Section 3.1.1).

3.2.2 DANE-TA(2) Name Checks

  • MUSTTo match a server via a TLSA record with certificate usage DANE-TA(2), the client MUST perform name checks to ensure that it has reached the correct server.
  • MUSTIn all DANE-TA(2) cases, the SMTP client MUST employ the TLSA base domain as the primary reference identifier for matching the server certificate.
  • MUSTTLSA records for MX hostnames: If the TLSA base domain was obtained indirectly via a "secure" MX lookup (including any CNAME-expanded name of an MX hostname), then the original next-hop domain used in the MX lookup MUST be included as a second reference identifier.
  • MUSTThe CNAME-expanded original next-hop domain MUST be included as a third reference identifier if different from the original next-hop domain.
  • MUSTTLSA records for non-MX hostnames: If MX records were not used (e.g., if none exist) and the TLSA base domain is the CNAME-expanded original next-hop domain, then the original next-hop domain MUST be included as a second reference identifier.
  • MUSTCertificate name checks for delivery of mail to exchange.example.org via any of the associated SMTP servers MUST accept at least the names "exchange.example.org" and "example.com", which are, respectively, the original and fully expanded next-hop domain.
  • MUSTWhen the SMTP server is mx10.example.com, name checks MUST accept the TLSA base domain "mx10.example.com".
  • MUSTIf, despite the fact that MX hostnames are required to not be aliases, the MTA supports delivery via "mx15.example.com" or "mx20.example.com", then name checks MUST accept the respective TLSA base domains "mx15.example.com" and "mxbackup.example.net".

3.2.3 Reference Identifier Matching

  • MUSTSMTP clients MUST support wildcards that match the first label of the reference identifier, with the remaining labels matching verbatim.
  • MAYSMTP clients MAY, subject to local policy, allow wildcards to match multiple reference identifier labels, but servers cannot expect broad support for such a policy.
  • SHOULDTherefore, any wildcards in server certificates SHOULD match exactly one label in either the TLSA base domain or the next-hop domain.

4 Server Key Management

  • MUSTTwo TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and the other matching the new key scheduled to replace it.
  • SHOULDIf a particular server's key is compromised, its TLSA CNAME SHOULD be replaced with a DANE-EE(3) association until the certificate for the compromised key expires, at which point it can return to using a CNAME record.

5 Digest Algorithm Agility

  • SHOULDWhen stronger algorithms are an option, deprecated algorithms SHOULD be avoided.
  • MUSTSMTP clients and servers that implement this specification MUST comply with the requirements outlined in Section 9 of [RFC7671].

8.1 SNI Support

  • MUSTTo ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain.
  • MUSTEach SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records.
  • MAYThe server MAY rely on SNI to determine which certificate chain to present to the client.
  • MUST NOTServers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server.
  • MUSTIf the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice.

8.2 Anonymous TLS Cipher Suites

  • SHOULDSince many SMTP servers either do not support or do not enable any anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD offer to negotiate a typical set of non-anonymous cipher suites required for interoperability with such servers.
  • MAYAn SMTP client employing pre-DANE opportunistic TLS MAY also include one or more anonymous TLS cipher suites in its TLS HELLO.
  • SHOULDSMTP servers that need to interoperate with opportunistic TLS clients SHOULD be prepared to interoperate with such clients by either always selecting a mutually supported non-anonymous cipher suite or correctly handling client connections that negotiate anonymous cipher suites.

9.1 Client Operational Considerations

  • MAYSome implementations MAY support DANE TLS in an "audit only" mode in which failure to achieve the requisite security level is logged as a warning and delivery proceeds at a reduced security level.
  • MUST NOTclient MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server.

9.2 Publisher Operational Considerations

  • MUST NOTServer operators MUST NOT implement selective STARTTLS if they also want to support DANE TLSA.
  • MUSTTLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].
  • SHOULDTLSA Publishers SHOULD follow the TLSA publication size guidance found in Section 10.1 of [RFC7671].
  • SHOULDTLSA Publishers SHOULD follow the TLSA record TTL and signature lifetime recommendations found in Section 13 of [RFC7671].

Every current email RFC