< draft-ietf-dane-smtp-with-dane-04.txt   draft-ietf-dane-smtp-with-dane-05.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track W.H. Hardaker Intended status: Standards Track W. Hardaker
Expires: May 28, 2014 Parsons Expires: August 13, 2014 Parsons
November 24, 2013 February 9, 2014
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-04 draft-ietf-dane-smtp-with-dane-05
Abstract Abstract
This memo describes a protocol for opportunistic TLS security based This memo describes a downgrade-resistant protocol for SMTP transport
on the DANE TLSA DNS record. The protocol is downgrade resistant security between Mail Transfer Agents (MTAs) based on the DNS-Based
when the SMTP client supports DANE TLSA and the server domain Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
publishes TLSA records for its MX hosts. This enables an incremental this protocol enables an incremental transition of the Internet email
transition of the Internet email backbone (MTA to MTA SMTP traffic) backbone to one using encrypted and authenticated Transport Layer
to TLS encrypted and authenticated delivery. Security (TLS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 28, 2014. This Internet-Draft will expire on August 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 5
2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 5
2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 6
2.1.1. Non-MX destinations . . . . . . . . . . . . . . . . . 6 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7
2.1.2. MX resolution . . . . . . . . . . . . . . . . . . . . 7 1.3.4. Too many certificate authorities . . . . . . . . . . 7
2.1.3. TLSA record lookup . . . . . . . . . . . . . . . . . 9 2. Hardening (pre-DANE) Opportunistic TLS . . . . . . . . . . . 8
2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 11 2.1. DNS errors, bogus and indeterminate responses . . . . . . 8
2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 11 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13
2.2.3. Digest algorithm agility . . . . . . . . . . . . . . 14 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 14
3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 16 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 16
4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 17 2.3. DANE authentication . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 2.3.1. TLSA certificate usages . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 2.3.2. Certificate matching . . . . . . . . . . . . . . . . 20
7. Normative References . . . . . . . . . . . . . . . . . . . . 19 2.3.3. Digest algorithm agility . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 3. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 25
4. Operational Considerations . . . . . . . . . . . . . . . . . 25
4.1. Client Operational Considerations . . . . . . . . . . . . 25
4.2. Publisher Operational Considerations . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Lacking verified DNS and "Server Name Indication" (SNI), there has This memo specifies a new connection security model for Message
historically been no scalable way for SMTP server operators to deploy Transfer Agents (MTAs). This model is motivated by key features of
certificates with a client-trusted subject name. It's only with the inter-domain SMTP delivery, in particular the fact that the
deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX destination server is selected indirectly via DNS Mail Exchange (MX)
becomes possible between parties that have not already established an records and that with MTA to MTA SMTP the use of TLS is generally
identity convention out-of-band. opportunistic.
1.1. Background We note that the SMTP protocol is also used between Message User
Agents (MUAs) and Message Submission Agents (MSAs). In [RFC6186] a
protocol is specified that enables an MUA to dynamically locate the
MSA based on the user's email address. SMTP connection security
requirements for MUAs implementing [RFC6186] are largely analogous to
connection security requirements for MTAs, and this specification
could be applied largely verbatim with DNS MX records replaced by
corresponding DNS Service (SRV) records.
The Domain Name System Security Extensions (DNSSEC) add data origin However, until MUAs begin to adopt the dynamic configuration
authentication and data integrity to the Domain Name System. DNSSEC mechanisms of [RFC6186] they are adequately served by more
is defined in [RFC4033], [RFC4034] and [RFC4035]. traditional static TLS security policies. This document will not
discuss the MUA use case further, leaving specification of DANE TLS
for MUAs to future documents that focus specifically on SMTP security
between MUAs and MSAs. The rest of this memo will focus on securing
MTA to MTA SMTP connections.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
The following terms or concepts are used through the document:
secure, bogus, insecure, indeterminate: DNSSEC validation results,
as defined in Section 4.3 of [RFC4035].
Validating Security-Aware Stub Resolver and Non-Validating
Security-Aware Stub Resolver:
Capabilities of the stub resolver in use as defined in [RFC4033];
note that this specification requires the use of a Security-Aware
Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used.
opportunistic DANE TLS: Best-effort use of TLS, resistant to
downgrade attacks for destinations with DNSSEC-validated TLSA
records. When opportunistic DANE TLS is determined to be
unavailable, clients should fall back to opportunistic TLS below.
Opportunistic DANE TLS requires support for DNSSEC, DANE and
STARTTLS on the client side and STARTTLS plus a DNSSEC published
TLSA record on the server side.
(pre-DANE) opportunistic TLS: Best-effort use of TLS that is
generally vulnerable to DNS forgery and STARTTLS downgrade
attacks. When a TLS-encrypted communication channel is not
available, message transmission takes place in the clear. MX
record indirection generally precludes authentication even when
TLS is available.
MX hostname: The RRDATA of an MX record consists of a 16 bit
preference followed by a Mail Exchange domain name (see [RFC1035],
Section 3.3.9). We will use the term "MX hostname" to refer to
the latter, that is, the DNS domain name found after the
preference value in an MX record. Thus an "MX hostname" is
specifically a reference to a DNS domain name, rather than any
host that bears that name.
SMTP server: An SMTP server whose name appears in an MX record for a
particular domain. Used to refer specifically to the host and
SMTP service itself, not its DNS name.
delayed delivery: Email delivery is a multi-hop store & forward
process. When an MTA is unable forward a message that may become
deliverable later, the message is queued and delivery is retried
periodically. Some MTAs may be configured with a fallback next-
hop destination that handles messages that the MTA would otherwise
queue and retry. In these cases, messages that would otherwise
have to be delayed, may be sent to the fallback next-hop
destination instead. The fallback destination may itself be
subject to opportunistic or mandatory DANE TLS as though it were
the original message destination.
original next hop destination: The logical destination for mail
delivery. By default this is the domain portion of the recipient
address, but MTAs may be configured to forward mail for some or
all recipients via designated relays. The original next hop
destination is, respectively, either the recipient domain or the
associated configured relay.
MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
MUA: Message User Agent ([RFC5598], Section 4.2.1).
RR: A DNS Resource Record
RRset: A set of DNS Resource Records for a particular class, domain
and record type.
1.2. Background
The Domain Name System Security Extensions (DNSSEC) adds data origin
authentication, data integrity and data non-existence proofs to the
Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
and [RFC4035].
As described in the introduction of [RFC6698], TLS authentication via As described in the introduction of [RFC6698], TLS authentication via
the existing public Certificate Authority (CA) Public Key the existing public Certificate Authority (CA) PKI suffers from an
Infrastructure (PKI) suffers from an over-abundance of trusted over-abundance of trusted certificate authorities capable of issuing
certificate authorities capable of issuing certificates for any certificates for any domain of their choice. DANE leverages the
domain of their choice. DNS-Based Authentication of Named Entities DNSSEC infrastructure to publish trusted public keys and certificates
(DANE) leverages the DNSSEC infrastructure to publish trusted keys for use with the Transport Layer Security (TLS) [RFC5246] protocol
and certificates for use with TLS via a new TLSA record type. With via a new "TLSA" DNS record type. With DNSSEC each domain can only
DANE, the public CA PKI can be augmented or replaced by DNSSEC vouch for the keys of its directly delegated sub-domains.
validated TLSA records.
The Transport Layer Security (TLS [RFC5246]) protocol enables secure The TLS protocol enables secure TCP communication. In the context of
TCP communication. In the context of this memo, channel security is this memo, channel security is assumed to be provided by TLS. Used
assumed to be provided by TLS. Used without authentication, TLS without authentication, TLS provides only privacy protection against
protects only against eavesdropping. With authentication, TLS also eavesdropping attacks. With authentication, TLS also provides data
protects against man-in-the-middle (MITM) attacks. integrity protection to guard against man-in-the-middle (MITM)
attacks.
1.2. SMTP Channel Security 1.3. SMTP channel security
The Simple Mail Transfer Protocol (SMTP) ([RFC5321]) is multi-hop With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
store & forward, while TLS security is hop-by-hop. The number of issued by one of the many Certificate Authorities (CAs) bundled with
hops from the sender's Mail User Agent to the recipient mailbox is popular web browsers to allow users to authenticate their "secure"
rarely less than 2 and is often higher. Some hops may be TLS websites. Before we specify a new DANE TLS security model for SMTP,
protected, some may not. The same SMTP TCP endpoint can serve both we will explain why a new security model is needed. In the process,
TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS we will explain why the familiar HTTPS security model is is
command ([RFC3207]). DNS MX records abstract the next-hop transport inadequate to protect inter-domain SMTP traffic.
end-point. SMTP addresses are not transport addresses and are
security agnostic. Unlike HTTP, there is no URI scheme for email
addresses to designate whether the SMTP server should be contacted
with or without security.
A Mail Transport Agent (MTA) may need to forward a message to a The subsections below outline four key problems with applying
particular email recipient <user@example.com>. To deliver the traditional PKI to SMTP that are addressed by this specification.
message, the MTA needs to retrieve the MX hosts of example.com from Since SMTP channel security policy is not explicitly specified in
DNS, and then deliver the message to one of them. Absent DNSSEC, the either the recipient address or the MX record, a new signaling
MX lookup is vulnerable to man-in-the-middle and cache poisoning mechanism is required to indicate when channel security is possible
attacks. An active attacker can forge DNS replies with fake MX and should be used. The publication of TLSA records allows server
records, and can direct traffic to a server of his choice. operators to securely signal to SMTP clients that TLS is available
Therefore, secure verification of MX host certificates is not and should be used. DANE TLSA makes it possible to simultaneously
possible without DNSSEC. A man in the middle can also suppress the discover which destination domains support secure delivery via TLS
MX host's STARTTLS EHLO response, convincing the client that and how to verify the authenticity of the associated SMTP services
communication over TLS is unavailable. providing a path forward to ubiquitous SMTP channel security.
One might try to harden STARTTLS with SMTP against DNS attacks by 1.3.1. STARTTLS downgrade attack
requiring each MX host to posess an X.509 certificate for the
recipient domain that is obtained from the message envelope and is The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
not subject to DNS reply forgery. Unfortunately, this is protocol in a multi-hop store & forward email delivery process. SMTP
impractical, as email for many domains is handled by third parties, envelope recipient addresses are not transport addresses and are
which are not in a position to obtain certificates for all the security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and
domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is its corresponding secured version, HTTPS, there is no URI scheme for
no panacea, since SNI key management is operationally challenging email addresses to designate whether communication with the SMTP
except when the email service provider is also the domain's registrar server should be conducted via a cleartext or a TLS-encrypted
and its certificate issuer; this is rarely the case for email. channel. Indeed no such URI scheme could work well with SMTP since
TLS encryption of SMTP protects email traffic on a hop-by-hop basis
while email addresses could only express end-to-end policy.
With no mechanism available to signal transport security policy, SMTP
relays employ a best-effort "opportunistic" security model for TLS.
A single SMTP server TCP listening endpoint can serve both TLS and
non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
command ([RFC3207]). The server signals TLS support to the client
over a cleartext SMTP connection, and if the client also supports
TLS, it may negotiate a TLS encrypted channel to use for email
transmission. The server's indication of TLS support can be easily
suppressed by a man in the middle attacker. Thus pre-DANE SMTP TLS
security can be subverted by simply downgrading a connection to
cleartext. No TLS security feature, such as the use of PKIX, can
prevent this. The attacker can simply bypass TLS.
1.3.2. Insecure server name without DNSSEC
With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
transport endpoint and allow administrators to specify a set of
target servers to which SMTP traffic should be directed for a given
domain.
A PKIX TLS client is vulnerable to man in the middle (MITM) attacks
unless it verifies that the server's certificate binds its public key
to its name. However, with SMTP server names are obtained indirectly
via MX records. Without DNSSEC, the MX lookup is vulnerable MITM and
DNS cache poisoning attacks. Active attackers can forge DNS replies
with fake MX records, and can redirect email to servers with names of
their choice. Therefore, secure verification of SMTP TLS
certificates is not possible without DNSSEC.
One might try to harden the use of TLS with SMTP against DNS attacks
by requiring each SMTP server to possess a trusted certificate for
the envelope recipient domain rather than the MX hostname.
Unfortunately, this is impractical, as email for many domains is
handled by third parties that are not in a position to obtain
certificates for all the domains they serve. Deployment of the
Server Name Indication (SNI) extension to TLS (see [RFC6066]
Section 3) is no panacea, since SNI key management is operationally
challenging except when the email service provider is also the
domain's registrar and its certificate issuer; this is rarely the
case for email.
Since the recipient domain name cannot be used as the SMTP server Since the recipient domain name cannot be used as the SMTP server
authentication identity, and neither can the MX hostname without authentication identity, and neither can the MX hostname without
DNSSEC, large scale deployment of authenticated TLS for SMTP requires DNSSEC, large-scale deployment of authenticated TLS for SMTP requires
secure DNS. At this time, DNSSEC is not yet widely deployed and MTA that the DNS be secure.
to MTA traffic between Internet connected organizations rarely uses
TLS at all, or simply uses TLS opportunistically without
authentication and protects against only passive eavesdropping
attacks.
The exceptions are cases in which the sending MTA is statically Since SMTP security depends critically on DNSSEC, it is important to
configured to use TLS for mail sent to specific selected peer domains point out that consequently SMTP with DANE is the most conservative
and is configured with appropriate subject names (or content digests) possible trust model. It trusts only what must be trusted and no
to expect in the presented MX host certificates of those domains. more. Adding any other trusted actors to the mix can only reduce
Such statically configured SMTP secure channels are used rarely, SMTP security. A sender may choose to harden DNSSEC for selected
generally between domains that make bilateral arrangements with their high value receiving domains, by configuring explicit trust anchors
business partners. Internet email, on the other hand, requires for those domains instead of relying on the chain of trust from the
contacting many new domains for which security configurations can not root domain. In such a case there is not an "additional" trusted
be established in advance. authority, rather the root trust anchor is replaced with a more
specific trust anchor for each of the domains in question. Detailed
discussion of DNSSEC security practices is out of scope for this
document.
Note, the above does not apply to mail submission [RFC6409], where a 1.3.3. Sender policy does not scale
mail user agent is pre-configured to send all email to a fixed Mail
Submission Agent (MSA). Submission servers usually offer TLS and the
Mail User Agent (MUA) can be statically configured to require TLS
with its chosen MSA. The situation changes when submission servers
are configured dynamically via SRV records (see [RFC6186] Section 6).
Applications to submission via SRV records will be discussed later in
this memo.
With little opportunity to use TLS authentication, MX hosts that Sending systems are in some cases explicitly configured to use TLS
support STARTTLS often use self-signed or private CA issued X.509 for mail sent to specifically selected peer domains. This requires
certificates. Sending systems are rarely configured with a MTAs to be configured with appropriate subject names or certificate
comprehensive list of trusted CAs and do not check CRLs or implement content digests to expect in the presented host certificates.
OCSP. In essence, they don't and can't rely on the existing public Because of the heavy administrative burden, such statically
CA PKI. This is not a result of complacency on the part SMTP server configured SMTP secure channels are used rarely (generally only
administrators and MTA developers. Nor is it just a consequence of between domains that make bilateral arrangements with their business
the relative maturity of the SMTP infrastructure at the time that TLS partners). Internet email, on the other hand, requires regularly
was introduced. Rather, the abstraction of the SMTP transport contacting new domains for which security configurations cannot be
endpoint via DNS MX records, often across organization boundaries, established in advance.
limits the use of public CA PKI with SMTP to a small set of sender-
configured peer domains.
This does not mean, however, that the Internet email backbone cannot The abstraction of the SMTP transport endpoint via DNS MX records,
benefit from TLS. The fact that transport security is not explicitly often across organization boundaries, limits the use of public CA PKI
specified in either the recipient address or the MX record means that with SMTP to a small set of sender-configured peer domains. With
new protocols can furnish out-of-band information to SMTP, making it little opportunity to use TLS authentication, sending MTAs are rarely
possible to simultaneously discover both which peer domains support configured with a comprehensive list of trusted CAs. SMTP services
secure delivery via TLS and how to verify the authenticity of the that support STARTTLS often use X.509 certificates that are self-
associated MX hosts. The first such mechanism that can work an signed or issued by a private CA.
Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA
SMTP must be cognizant of the lack of any realistic role for the
existing public CA PKI.
1.3. Terminology 1.3.4. Too many certificate authorities
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Even if it were generally possible to determine a secure server name,
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this the SMTP client would still need to verify that the server's
document are to be interpreted as described in [RFC2119]. certificate chain is issued by a trusted certificate authority (a
trust anchor). MTAs are not interactive applications where a human
operator can make a decision (wisely or otherwise) to selectively
disable TLS security policy when certificate chain verification
fails. With no user to "click OK", the MTAs list of public CA trust
anchors would need to be comprehensive in order to avoid bouncing
mail sites to sites employing an unknown certificate authority.
2. Hardening Opportunistic TLS On the other hand, each trusted CA can issue certificates for any
domain. If even one of the configured CAs is compromised or operated
by an adversary, it can subvert TLS security for all destinations.
Any set of CAs is simultaneously both overly inclusive and not
inclusive enough.
This memo describes opportunistic SMTP over TLS security, where 2. Hardening (pre-DANE) Opportunistic TLS
traffic from DANE TLSA aware SMTP clients to domains that implement
DANE TLSA records in accordance with this memo is secure. Traffic to
other domains continues to be sent in the same manner as before
(either manually configured for security or unauthenticated and often
unencrypted). It is hoped that, over time, more domains will
implement DNSSEC and publish DANE TLSA records for their MX hosts.
This will enable an incremental transition of the email backbone to
authenticated TLS delivery.
Since email addresses and MX hostnames (or submission SRV records) Neither email addresses nor MX hostnames (or submission SRV records)
neither signal nor deny support for TLS by the receiving domain, it signal a requirement for either secure or cleartext transport.
is possible to use DANE TLSA records to securely signal TLS support Therefore, SMTP transport security is of necessity generally
and simultaneously to provide the means by which SMTP clients can opportunistic (barring manually configured exceptions).
successfully authenticate legitimate SMTP servers.
2.1. TLS discovery This specification uses the presence of DANE TLSA records to securely
signal TLS support and to publish the means by which SMTP clients can
successfully authenticate legitimate SMTP servers. This becomes
"opportunistic DANE TLS" and is resistant to downgrade and MITM
attacks, and enables an incremental transition of the email backbone
to authenticated TLS delivery, with increased global protection as
adoption increases.
As noted previously (Section 1.2), opportunistic TLS with SMTP With opportunistic DANE TLS, traffic from SMTP clients to domains
servers that advertise TLS support via STARTTLS is subject to a man that publish "usable" DANE TLSA records in accordance with this memo
in the middle downgrade attack. Some SMTP servers erroneously is authenticated and encrypted. Traffic from non-compliant clients
advertise STARTTLS in default configurations that are not, in fact, or to domains that do not publish TLSA records will continue to be
TLS capable, and clients need to be prepared to retry plaintext sent in the same manner as before, via manually configured security,
delivery after STARTTLS fails. This memo specifies a downgrade (pre-DANE) opportunistic TLS or just cleartext SMTP.
resistant mechanism that allows a server to advertise TLS support
based on DANE TLSA records. DNSSEC validated TLSA records are
unlikely to be accidentally published for servers that do not in fact
support TLS, and thus clients can safely interpret their presence as
a commitment by the server operator to implement STARTTLS.
SMTP is a store & forward protocol. An MTA that is not the final 2.1. DNS errors, bogus and indeterminate responses
destination for a message recipient forwards the message one hop
closer to the recipient's mailbox. To do so, it must determine the
appropriate next-hop destination, and locate one or more associated
SMTP servers. When DNSSEC validated TLSA records are available for a
given next-hop SMTP server, the TLS connection to that server will be
downgrade resistant. If the records in question are "usable"
([RFC6698], Section 4.1) to authenticate the server, the connection
will also be authenticated and thus immune to eavesdropping or
tampering (unless DNSSEC itself is compromised).
Typically, the next-hop destination will be the domain part of the An SMTP client that implements opportunistic DANE TLS per this
recipient address, which is then subject to MX resolution. The next- specification depends critically on the integrity of DNSSEC lookups,
hop destination may also be configured by the MTA administrator to be as discussed in Section 1.3. This section lists the DNS resolver
a next-hop destination host (explicitly exempt from MX resolution), requirements needed to avoid downgrade attacks when using
or a next-hop destination domain (subject to MX resolution) which opportunistic DANE TLS.
takes the place of the domain part of the recipient address.
The protocol in this memo is "opportunistic"; it should be used A DNS lookup may signal an error or return a definitive answer. A
whenever possible but communication should continue when it is not security-aware resolver must be used for this specification.
available. Absent "secure" (DNSSEC validated) TLSA records, mail Security-aware resolvers will indicate the security status of a DNS
delivery should fall back to pre-DANE opportunistic TLS. The SMTP RRset with one of four possible values defined in Section 4.3 of
client MAY be configured to require DANE verified delivery for some [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
or all destinations, in which case mail delivery will be deferred [RFC4035] the meaning of the "indeterminate" security status is:
when "secure" TLSA records are absent.
Below we explain how to determine for a given next-hop destination An RRset for which the resolver is not able to determine whether
the associated SMTP servers, the TLSA base domain and TLSA records. the RRset should be signed, as the resolver is not able to obtain
the necessary DNSSEC RRs. This can occur when the security-aware
resolver is not able to contact security-aware name servers for
the relevant zones.
2.1.1. Non-MX destinations Note, the "indeterminate" security status has a conflicting
definition in section 5 of [RFC4033].
As mentioned above, the next-hop destination domain may in some cases There is no trust anchor that would indicate that a specific
be exempt from MX lookups. In addition, MX lookups for the next-hop portion of the tree is secure.
domain may yield no results. In either case, the destination server
for such a domain is determined by looking up the corresponding A or
AAAA records.
When "bogus" records are encountered either during CNAME expansion, SMTP clients following this specification SHOULD NOT distinguish
or when retrieving the associated TLSA RRset, the SMTP client MUST between "insecure" and "indeterminate" in the [RFC4033] sense. Both
proceed as if the next-hop domain were unreachable. Delivery should "insecure" and RFC4033 "indeterminate" are handled identically: in
either be deferred or may be attempted via any fallback next-hop either case unvalidated data for the query domain is all that is and
configured by the SMTP client administrator. Fallback next-hop can be available, and authentication using the data is impossible.
destinations may also employ opportunistic DANE TLS. Proceeding with In what follows, when we say "insecure", we include also DNS results
the original next-hop despite "bogus" DNS responses would destroy for domains that lie in a portion of the DNS tree for which there is
protection against downgrade attacks. no applicable trust anchor. With the DNS root zone signed, we expect
that validating resolvers used by Internet-facing MTAs will be
configured with trust anchor data for the root zone. Therefore,
RFC4033-style "indeterminate" domains should be rare in practice.
From here on, when we say "indeterminate", it is exclusively in the
sense of [RFC4035].
Following [RFC5321] Section 5.1, if the A or AAAA lookup of the As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
initial name yields a CNAME, we replace it with the resulting name as MUST be able to determine whether a given non-error DNS response is
if it were the initial name and perform a lookup again using the new "secure", "insecure", "bogus" or "indeterminate". It is expected
name. This replacement is performed recursively, although MTAs that most security-aware stub resolvers will not signal an
typically support only limited recursion in CNAME expansion. We "indeterminate" security status the RFC4035-sense to the application,
consider the following cases: and will signal a "bogus" or error result instead. If 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.
Non-CNAME: The next-hop destination domain is not a CNAME alias. An MTA making use of a non-validating security-aware stub resolver
The lookup key for the DNSSEC validated TLSA records is obtained MAY use the stub resolver's ability, if available, to signal DNSSEC
by prepending service labels ("_<port-number>._tcp") to the validation status based on information the stub resolver has learned
initial next-hop destination domain. If associated "secure" TLSA from an upstream validating recursive resolver. In accordance with
records are found (see Section 2.1.3) the TLSA base domain is the section 4.9.3 of [RFC4035]:
next-hop domain. If no secure TLSA records are found,
opportunistic DANE TLS is not applicable and mail delivery
proceeds with pre-DANE opportunistic TLS.
Insecure CNAME: The next-hop destination domain is a CNAME alias, ... a security-aware stub resolver MUST NOT place any reliance on
but at least one of the CNAME RRs leading to the ultimate target signature validation allegedly performed on its behalf, except
of this alias (during recursive CNAME expansion) is "insecure". when the security-aware stub resolver obtained the data in question
We treat this case just like the non-CNAME case above. from a trusted security-aware recursive name server via a secure
channel.
Secure CNAME, no TLSA: The next-hop destination domain is a CNAME To avoid much repetition in the text below, we will pause to explain
alias, and all the CNAME RRs leading to the ultimate target of the handling of "bogus" or "indeterminate" DNSSEC query responses.
this alias (during recursive CNAME expansion) are "secure" (DNSSEC These are not necessarily the result of a malicious actor; they can,
validated), but no "secure" TLSA RRs are found after prefixing the for example, occur when network packets are corrupted or lost in
service labels to the CNAME-expanded next-hop domain. This case transit. Therefore, "bogus" or "indeterminate" replies are equated
is also treated just like the non-CNAME case. in this memo with lookup failure.
Secure CNAME, TLSA: The next-hop destination domain is a CNAME There is an important non-failure condition we need to highlight in
alias, all the CNAME RRs leading to the ultimate target of this addition to the obvious case of the DNS client obtaining a non-empty
alias (during recursive CNAME expansion) are "secure", and in "secure" or "insecure" RRset of the requested type. Namely, it is
addition "secure" TLSA RRs are found after prefixing the service not an error when either "secure" or "insecure" non-existence is
labels to the CNAME-expanded next-hop domain. In this case the determined for the requested data. When a DNSSEC response with a
CNAME-expanded next-hop domain is taken as the TLSA base domain. validation status that is either "secure" or "insecure" reports
The original next-hop domain is (see Section 2.2.2) used only as either no records of the requested type or non-existence of the query
an alternative name in certificate peername verification if domain, the response is not a DNS error condition. The DNS client
applicable. has not been left without an answer; it has learned that records of
the requested type do not exist.
In summary, if it is possible to securely obtain the full, CNAME- Security-aware stub resolvers will, of course, also signal DNS lookup
expanded, DNSSEC-validated address records for the non-MX next-hop errors in other cases, for example when processing a "ServFail"
domain then that name is the preferred TLSA base domain. If that is RCODE, which will not have an associated DNSSEC status. All lookup
not possible, then the original next-hop domain is used as the TLSA errors are treated the same way by this specification, regardless of
base domain. When no "secure" TLSA records are found at either the whether they are from a "bogus" or "indeterminate" DNSSEC status or
CNAME expanded or original next-hop domain, then opportunistic DANE from a more generic DNS error: the information that was requested can
TLS does not apply for mail delivery to the non-MX destination in not be obtained by the security-aware resolver at this time. A
question. lookup error is thus a failure to obtain the relevant RRset if it
exists, or to determine that no such RRset exists when it does not.
2.1.2. MX resolution In contrast to a "bogus" or an "indeterminate" response, an
In this section we consider next-hop domains that are subject to MX "insecure" DNSSEC response is not an error, rather it indicates that
resolution and have MX records. When DANE TLS is applicable, the the target DNS zone is either securely opted out of DNSSEC validation
TLSA base domain will be associated with the MX host selected for or is not connected with the DNSSEC trust anchors being used.
message delivery. Therefore, the MX host names must be determined Insecure results will leave the SMTP client with degraded channel
securely by performing a DNSSEC validated MX lookup to obtain the security, but do not stand in the way of message delivery. See
list of associated MX hosts. If the MX RRset is "insecure", DANE section Section 2.2 for further details.
TLSA does not apply and mail delivery proceeds with pre-DANE
opportunistic TLS (subject to its various MITM attacks and unecrypted
transmission when STARTTLS is not supported by the destination).
When "bogus" DNSSEC records are encountered during CNAME expansion of When a stub resolver receives a response containing a CNAME alias, it
the next-hop domain or when processing the actual MX RRset, delivery will generally restart the query at the target of the alias, and
MUST either be deferred, or MAY be attempted via any fallback next- should do so recursively up to some configured or implementation-
hop (which may also employ opportunistic DANE TLS) configured by the dependent recursion limit. If at any stage of recursive CNAME
SMTP client administrator. Proceeding with the original next-hop expansion a query fails, the stub resolver's lookup of the original
despite "bogus" DNS responses would destroy protection against requested records will result in a failure status being returned. If
downgrade attacks. When "bogus" DNSSEC records are encountered with at any stage of recursive expansion the response is "insecure", then
CNAME expansion or TLSA RRset lookup for a particular MX host, it and all subsequent results (in particular, the final result) MUST
delivery MUST proceed as if MX host in question were unreachable. be considered "insecure" regardless of whether the other responses
received were deemed "secure". If at any stage of recursive
expansion the validation status is "bogus" or "indeterminate" or
associated with another DNS lookup error, the resolution of the
requested records MUST be considered to have failed.
MX records MUST be sorted by preference; an MX host with a better When a DNS lookup failure (error or "bogus" or "indeterminate" as
preference and no TLSA records MUST NOT be preempted by a host with a defined above) prevents an SMTP client from determining which SMTP
worse MX preference but with TLSA records. In other words, avoiding server or servers it should connect to, message delivery MUST be
delivery loops by following MX preferences must take place even if it delayed. This naturally includes, for example, the case when a
means insecure delivery. "bogus" or "indeterminate" response is encountered during MX
resolution. When multiple MX hostnames are obtained from a
successful MX lookup, but a later DNS lookup failure prevents network
address resolution for a given MX hostname, delivery may proceed via
any remaining MX hosts.
In accordance with Section 5.1 of [RFC5321], if the MX lookup of the When a particular SMTP server is selected as the delivery
initial name yields a CNAME, we replace the initial name with the destination, a set of DNS lookups must be performed to discover any
resulting name and perform a new lookup with the new name. MTAs related TLSA records. If any DNS queries used to locate TLSA records
fail (be it due to "bogus" or "indeterminate" records, timeouts,
malformed replies, ServFails, etc.), then the SMTP client MUST treat
that server as unreachable and MUST NOT deliver the message via that
server. If no servers are reachable, delivery is delayed.
In what follows, we will only describe what happens when all relevant
DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
behave as described in this section, by skipping the problem SMTP
server, or the problem destination. Queries 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.2. TLS discovery
As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
servers that advertise TLS support via STARTTLS is subject to an MITM
downgrade attack. Also some SMTP servers that are not, in fact, TLS
capable erroneously advertise STARTTLS by default and clients need to
be prepared to retry cleartext delivery after STARTTLS fails. In
contrast, DNSSEC validated TLSA records MUST NOT be published for
servers that do not support TLS. Clients can safely interpret their
presence as a commitment by the server operator to implement TLS and
STARTTLS.
This memo defines four actions to be taken after the search for a
TLSA record returns secure usable results, secure unusable results,
insecure or no results or an error signal. The term "usable" in this
context is in the sense of Section 4.1 of [RFC6698]. Specifically,
if the DNS lookup for a TLSA record returns:
A secure TLSA RRset with at least one usable record: A connection to
the MTA MUST be made using authenticated and encrypted TLS, using
the techniques discussed in the rest of this document. Failure to
establish an authenticated TLS connection MUST result in falling
back to the next SMTP server or delayed delivery.
A Secure non-empty TLSA RRset where all the records are unusable: A
connection to the MTA MUST be made via TLS, but authentication is
not required. Failure to establish an encrypted TLS connection
MUST result in falling back to the next SMTP server or delayed
delivery.
An insecure TLSA RRset or DNSSEC validated proof-of-non-existent 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. The MTA may
optionally retry in cleartext when a TLS handshake fails.
Any lookup error: Lookup errors, including "bogus" and
"indeterminate", as explained in Section 2.1 MUST result in
falling back to the next SMTP server or delayed delivery.
An SMTP client MAY be configured to require DANE verified delivery
for some destinations. We will call such a configuration "mandatory
DANE TLS". With mandatory DANE TLS, delivery proceeds only when
"secure" TLSA records are used to establish an encrypted and
authenticated TLS channel with the SMTP server.
An operational error on the sending or receiving side that cannot be
corrected in a timely manner may, at times, lead to consistent
failure to deliver time-sensitive email. The sending MTA
administrator may have to choose between letting email queue until
the error is resolved and disabling opportunistic or mandatory DANE
TLS for one or more destinations. The choice to disable DANE TLS
security should not be made lightly. Every reasonable effort should
be made to determine that problems with mail delivery are the result
of an operational error, and not an attack. A fallback strategy may
be to configure explicit out-of-band TLS security settings if
supported by the sending MTA.
A note about DNAME aliases: a query for a domain name whose ancestor
domain is a DNAME alias returns the DNAME RR for the ancestor domain,
along with a CNAME that maps the query domain to the corresponding
sub-domain of the target domain of the DNAME alias. Therefore,
whenever we speak of CNAME aliases, we implicitly allow for the
possibility that the alias in question is the result of an ancestor
domain DNAME record. Consequently, no explicit support for DNAME
records is needed in SMTP software, it is sufficient to process the
resulting CNAME aliases. DNAME records only require special
processing in the validating stub-resolver library that checks the
integrity of the combined DNAME + CNAME reply. When DNSSEC
validation is handled by a local caching resolver, rather than the
MTA itself, even that part of the DNAME support logic is outside the
MTA.
When the original next-hop destination is an address literal, rather
than a DNS domain, DANE TLS does not apply. Delivery proceeds using
any relevant security policy configured by the MTA administrator.
Similarly, when an MX RRset incorrectly lists an network address in
lieu of an MX hostname, if the MTA chooses to connect to the network
address DANE TLSA does not apply for such a connection.
In the subsections that follow we explain how to locate the SMTP
servers and the associated TLSA records for a given next-hop
destination domain. We also explain which name or names are to be
used in identity checks of the SMTP server certificate.
2.2.1. MX resolution
In this section we consider next-hop domains that are subject to MX
resolution and have MX records. The TLSA records and the associated
base domain are derived separately for each MX hostname that is used
to attempt message delivery. Clearly, if DANE TLS security is to
apply to message delivery via any of the SMTP servers, the MX records
must be obtained securely via a DNSSEC validated MX lookup.
MX 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. In other words, prevention of delivery
loops by obeying MX preferences MUST take precedence over channel
security considerations. Even with two equal preference MX records,
an MTA is not obligated to choose the MX hostname that offers more
security. Domains that want secure inbound mail delivery need to
ensure that all their SMTP servers and MX records are configured
accordingly.
In the language of [RFC5321] Section 5.1, the original next-hop
domain is the "initial name". If the MX lookup of the initial name
results in a CNAME alias, the MTA replaces the initial name with the
resulting name and performs a new lookup with the new name. MTAs
typically support recursion in CNAME expansion, so this replacement typically support recursion in CNAME expansion, so this replacement
is performed repeatedly until the ultimate non-CNAME domain is found is performed repeatedly until the ultimate non-CNAME domain is found.
(or the limit on the number of CNAMEs to examine is reached). If at
any stage of CNAME expansion the DNS result is "bogus", MX resolution
fails with a temporary error. In that case, mail delivery MUST
either be deferred, or attempted via any alternative delivery channel
configured by the MTA administrator. We consider the following
cases:
Non-CNAME: The next-hop destination domain is not a CNAME alias, If the MX RRset (or any CNAME leading to it) is "insecure" (see
that is, it resolves directly to a set of DNSSEC validated Section 2.1), DANE TLS does not apply, and delivery proceeds via pre-
("secure") MX hosts. With each MX host, if MX host CNAME DANE opportunistic TLS. Otherwise (assuming no DNS errors or "bogus"
expansion is supported by the MTA, and the full CNAME expansion of /"indeterminate" responses), the MX RRset is "secure", and the SMTP
the MX host name is "secure", then the CNAME expanded MX host name client MUST treat each MX hostname as a separate non-MX destination
is the TLSA base domain provided secure TLSA records are found for opportunistic DANE TLS as described in Section 2.2.2. When, for
there after prefixing service labels ("_<port-number>._tcp"). a given MX hostname, no TLSA records are found, or only "insecure"
Otherwise, the initial MX host name is the TLSA base domain TLSA records are found, DANE TLSA is not applicable with the SMTP
provided secure TLSA records are found there after prefixing server in question and delivery proceeds to that host as with pre-
service labels. With the MX hostname (or its CNAME expansion) as DANE opportunistic TLS. To avoid downgrade attacks, any errors
the TLSA base domain, the original next-hop domain SHOULD be used during TLSA lookups MUST, as explained in Section 2.1, cause the SMTP
only in certificate name checks. If no "secure" TLSA RRs are server in question to be treated as unreachable.
found, and no "bogus" records encountered, DANE TLSA is not
applicable with the MX host in question and delivery proceeds as
with pre-DANE opportunistic TLS.
CNAME: The next-hop destination domain is a CNAME alias, and 2.2.2. Non-MX destinations
resolves via a chain of "secure" CNAME records to a final domain
with "secure" MX records. The TLSA base domain for each MX host
in this case is the same as in the "Non-CNAME" case above, but now
both the initial domain and its CNAME-expansion are candidate
names in certificate name checks. If the CNAME chain contains
"insecure" elements, DANE TLSA does not apply to the next-hop
domain, and delivery proceeds via pre-DANE opportunistic TLS.
Note: CNAMEs are not legal in the exchange field of MX records, thus This section describes the algorithm used to locate the TLSA records
MTAs are not obligated to perform MX exchange CNAME expansion. If an and associated TLSA base domain for an input domain not subject to MX
MTA does not perform CNAME expansion, there is potential risk, that resolution. Such domains include:
the MTA may fail to notice that it is one of the MX hosts for the
destination and that it must skip MX records with equal or worse
(numerically higher precedence). If an MTA does allow CNAMEs to be
used in MX records, it SHOULD process them recursively as described
above to determine the most appropriate TLSA RRset base domain.
2.1.3. TLSA record lookup o Each MX hostname used in a message delivery attempt for an
original next-hop destination domain subject to MX resolution.
Note, MTAs are not obligated to support CNAME expansion of MX
hostnames.
Each TLSA base domain obtained above (for a non-MX destination, or o Any administrator configured relay hostname, not subject to MX
for a particular MX host of an MX destination), when prefixed with resolution. This frequently involves configuration set by the MTA
appropriate service labels leads to associated "secure" TLSA RRs administrator to handle some or all mail.
(possibly via a chain of "secure" CNAME RRs). If, for example, the
base domain is "mail.example.com", the TLSA RRset is obtained via a o A next-hop destination domain subject to MX resolution that has no
DNSSEC query of the form: MX records. In this case the domain's name is implicitly also the
hostname of its sole SMTP server.
Note that DNS queries with type TLSA are mishandled by load balancing
nameservers that serve the MX hostnames of some large email
providers. The DNS zones served by these nameservers are not signed
and contain no TLSA records, but queries for TLSA records fail,
rather than returning the non-existence of the requested TLSA
records.
To avoid problems delivering mail to domains whose SMTP servers are
served by the problem nameservers the SMTP client MUST perform any A
and/or AAAA queries for the destination before attempting to locate
the associated TLSA records. This lookup is needed in any case to
determine whether the destination domain is reachable and the DNSSEC
validation status of each stage of the chain of CNAME queries
required to reach the final result.
If no address records are found, the destination is unreachable. If
address records are found, but the DNSSEC validation status of the
first query response is "insecure" (there may be additional queries
if the initial response is a CNAME alias), the SMTP client SHOULD NOT
proceed to search for any associated TLSA records. With the problem
domains, TLSA queries will lead to DNS lookup errors and cause
messages to be consistently delayed and ultimately returned to the
sender. We don't expect to find any "secure" TLSA records associated
with a TLSA base domain that lies in an unsigned DNS zone.
Therefore, skipping TLSA lookups in this case will also reduce
latency with no detrimental impact on security.
If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
replace it with the resulting name as if it were the initial name and
perform a lookup again using the new name. This replacement is
performed recursively.
We consider the following cases for handling a DNS response for an A
or AAAA DNS lookup:
Not found: When the DNS queries for A and/or AAAA records yield
neither a list of addresses nor a CNAME (or CNAME expansion is not
supported) the destination is unreachable.
Non-CNAME: The answer is not a CNAME alias. If the address RRset
is "secure", TLSA lookups are performed as described in
Section 2.2.3 with the initial name as the candidate TLSA base
domain. If no "secure" TLSA records are found, DANE TLS is not
applicable and mail delivery proceeds with pre-DANE opportunistic
TLS (which, being best-effort, degrades to cleartext delivery when
STARTTLS is not available or the TLS handshake fails).
Insecure CNAME: The input domain is a CNAME alias, but the ultimate
network address RRset is "insecure" (see Section 2.1). If the
initial CNAME response is also "insecure", DANE TLS does not
apply. Otherwise, this case is treated just like the non-CNAME
case above, where a search is performed for a TLSA record with the
original input domain as the candidate TLSA base domain.
Secure CNAME: The input domain is a CNAME alias, and the ultimate
network address RRset is "secure" (see Section 2.1). Two
candidate TLSA base domains are tried: the fully CNAME-expanded
initial name and, failing that, then the initial name itself.
In summary, if it is possible to securely obtain the full, CNAME-
expanded, DNSSEC-validated address records for the input domain, then
that name is the preferred TLSA base domain. Otherwise, the
unexpanded input-MX domain is the candidate TLSA base domain. When
no "secure" TLSA records are found at either the CNAME-expanded or
unexpanded domain, then DANE TLS does not apply for mail delivery via
the input domain in question. And, as always, errors, bogus or
indeterminate results for any query in the process MUST result in
delaying or abandoning delivery.
2.2.3. TLSA record lookup
Each candidate TLSA base domain (the original or fully CNAME-expanded
name of a non-MX destination or a particular MX hostname of an MX
destination) is in turn prefixed with service labels of the form
"_<port>._tcp". The resulting domain name is used to issue a DNSSEC
query with the query type set to TLSA ([RFC6698] Section 7.1).
For SMTP, the destination TCP port is typically 25, but this may be
different with custom routes specified by the MTA administrator. The
SMTP client MUST use the appropriate number in the "_<port>" prefix
in place of "_25". If, for example, the candidate base domain is
"mail.example.com", and the SMTP connection is to port 25, the TLSA
RRset is obtained via a DNSSEC query of the form:
_25._tcp.mail.example.com. IN TLSA ? _25._tcp.mail.example.com. IN TLSA ?
Typically, the destination TCP port is 25, but this may be different The query response may be a CNAME, or the actual TLSA RRset. If the
with custom routes specified by the MTA administrator or when an MUA response is a CNAME, the SMTP client (through the use of its
connects to a submission server on port 587. The SMTP client MUST security-aware stub resolver) restarts the TLSA query at the target
use the appropriate "_<port-number>" prefix in place of "_25" when domain, following CNAMEs as appropriate and keeping track of whether
the port number is not equal to 25. The query response may be a the entire chain is "secure". If any "insecure" records are
CNAME (or a DNAME + CNAME combination), or the TLSA RRset. If the encountered, or the TLSA records don't exist, the next candidate TLSA
record is a CNAME or DNAME, the SMTP client restarts the TLSA query base is tried instead.
at the target domain, following CNAMEs as appropriate.
CNAMEs encountered during TLSA record lookups can be used to share a If the ultimate response is a "secure" TLSA RRset, then the candidate
single TLSA RRset specifying a common certificate authority or a TLSA base domain will be the actual TLSA base domain and the TLSA
common leaf certificate for multiple TLS services. Such CNAME RRset will constitute the TLSA records for the destination. If none
expansion does not change the SMTP client's notion of the TLSA base of the candidate TLSA base domains yield "secure" TLSA records then
domain, thus when _25._tcp.mail.example.com is a CNAME the base delivery should proceed via pre-DANE opportunistic TLS.
domain remains mail.example.com and is still used in peer certificate
name checks. For example:
example.com. IN MX 0 mail.example.com. TLSA record publishers may leverage CNAMEs to reference a single
example.com. IN MX 0 mail2.example.com. authoritative TLSA RRset specifying a common certificate authority or
_25._tcp.mail.example.com. IN CNAME 2.1.1._dane.example.com. a common end entity certificate to be used with multiple TLS
_25._tcp.mail2.example.com. IN CNAME 2.1.1._dane.example.com. services. Such CNAME expansion does not change the SMTP client's
2.1.1._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14 notion of the TLSA base domain; thus, when _25._tcp.mail.example.com
9afbf4c8996fb924 is a CNAME, the base domain remains mail.example.com and is still the
27ae41e4649b934c name used in peer certificate name checks.
a495991b7852b855
Here, mail.example.com and mail2.example.com have certificates issued Note, shared end entity certificate associations expose the
under a common trust-anchor, but each MX host's TLSA base domain publishing domain to substitution attacks, where an MITM attacker can
remains its hostname and MUST match the subject name (or subject reroute traffic to a different server that shares the same end entity
alternative name) in its certificate. certificate. Such shared end entity records should be avoided unless
the servers in question are interchangeable.
If, after possible CNAME indirection, at least one "secure" TLSA For example, given the DNSSEC validated records below:
record is found (even if not usable because it is unsupported by the
implementation or administratively disabled) the next-hop host has
committed to TLS support. The SMTP client SHOULD NOT deliver mail
via such a next-hop host unless a TLS session is negotiated via
STARTTLS. This avoids man in the middle STARTTLS downgrade attacks.
As noted previously (Section 2.1.1, Section 2.1.2), when no TLSA example.com. IN MX 0 mail.example.com.
records are found at a CNAME-expanded name (due to an insecure example.com. IN MX 0 mail2.example.com.
response or a lack of TLSA records verified by DNSSEC's proof-of-non- _25._tcp.mail.example.com. IN CNAME tlsa211._dane.example.com.
existence), the unexpanded name MUST be tried instead. This supports _25._tcp.mail2.example.com. IN CNAME tlsa211._dane.example.com.
clients of hosting providers where the provider's zone is not DNSSEC tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14....
validated, but the client has shared appropriate key material with
the hosting provider to enable TLS via SNI.
SMTP clients may deploy opportunistic DANE TLS incrementally by The SMTP servers mail.example.com and mail2.example.com will be
enabling it only for selected sites, or may occasionally need to expected to have certificates issued under a common trust anchor, but
disable opportunistic DANE TLS for peers that fail to interoperate each MX hostname's TLSA base domain remains unchanged despite the
due to misconfiguration or software defects on either end. Unless above CNAME records. Each SMTP server's certificate subject name (or
local policy specifies that opportunistic DANE TLS is not to be used one of the subject alternative names) is expected to match either the
for a particular destination, client MUST NOT deliver mail via a corresponding MX hostname or else "example.com".
server whose certificate chain fails to match at least one TLSA
record when usable TLSA records are available.
SMTP clients employing opportunistic DANE TLS and TLSA record If, during TLSA resolution (including possible CNAME indirection), at
publishers for SMTP servers need to follow the guidance outlined in least one "secure" TLSA record is found (even if not usable because
[I-D.ietf-dane-ops]'s "Certificate Name Check Conventions", "Service it is unsupported by the implementation or support is
Provider and TLSA Publisher Synchronization" and "TLSA Base Domain administratively disabled), then the corresponding host has signaled
and CNAMEs" sections. its commitment to implement TLS. The SMTP client SHOULD NOT deliver
mail via the corresponding host unless a TLS session is negotiated
via STARTTLS. This is required to avoid MITM STARTTLS downgrade
attacks.
2.2. DANE authentication As noted previously (in Section 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. This supports customers of
hosting providers where the provider's zone cannot be validated with
DNSSEC, but the customer has shared appropriate key material with the
hosting provider to enable TLS via SNI. Intermediate names that
arise during CNAME expansion that are neither the original, nor the
final name, are never candidate TLSA base domains, even if "secure".
2.2.1. TLSA certificate usages 2.3. DANE authentication
TLSA Publishers should follow the TLSA publication size guidance This section describes which TLSA records are applicable to SMTP
found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". opportunistic DANE TLS and how to apply such records to authenticate
the SMTP server. With opportunistic DANE TLS, both the TLS support
implied by the presence of DANE TLSA records and the verification
parameters necessary to authenticate the TLS peer are obtained
together, therefore authentication via this protocol is expected to
be less prone to connection failure caused by incompatible
configuration of the client and server.
2.2.1.1. Certificate usage 3 2.3.1. TLSA certificate usages
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
via combinations of 3 numeric parameters. The numeric values of
these parameters were later given symbolic names in
[I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is
the "certificate association data field", which specifies the full or
digest value of a certificate or public key. The parameters are:
The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-
EE(3). There is an additional private-use value: PrivCert(255).
All other values are reserved for use by future specifications.
The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
Cert(0), SPKI(1). There is an additional private-use value:
PrivSel(255). All other values are reserved for use by future
specifications.
The matching type field: Section 2.1.3 of [RFC6698] specifies 3
values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
private-use value: PrivMatch(255). All other values are reserved
for use by future specifications.
We may think of TLSA Certificate Usage values 0 through 3 as a
combination of two one-bit flags. The low bit chooses between trust
anchor (TA) and end entity (EE) certificates. The high bit chooses
between public PKI issued and domain-issued certificates.
The selector field specifies whether the TLSA RR matches the whole
certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's
algorithm id, any parameters and the public key data.
The matching type field specifies how the TLSA RR Certificate
Association Data field is to be compared with the certificate or
public key. A value of Full(0) means an exact match: the full DER
encoding of the certificate or public key is given in the TLSA RR. A
value of SHA2-256(1) means that the association data matches the
SHA2-256 digest of the certificate or public key, and likewise
SHA2-512(2) means a SHA2-512 digest is used.
The certificate usage element of a TLSA record plays a critical role
in determining how the corresponding certificate association data
field is used to authenticate server's certificate chain. The next
two subsections explain the process for certificate usages DANE-EE(3)
and DANE-TA(2). The third subsection briefly explains why
certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
opportunistic DANE TLS.
2.3.1.1. Certificate usage DANE-EE(3)
Since opportunistic DANE TLS will be used by non-interactive MTAs, Since opportunistic DANE TLS will be used by non-interactive MTAs,
with no user to "press OK" when authentication fails, reliability of with no user to "press OK" when authentication fails, reliability of
peer authentication is paramount. TLSA records published for SMTP peer authentication is paramount.
servers SHOULD be "3 1 1" records to support opportunistic SMTP over
TLS with DANE. This record specifies the SHA-256 digest of the
server's public key. Since all DANE implementations are required to
support SHA-256, this record works for all clients and need not
change across certificate renewals with the same key.
Authentication via certificate usage "3" TLSA records involves simply Authentication via certificate usage DANE-EE(3) TLSA records involves
checking that the server's leaf certificate matches the TLSA record. simply checking that the server's leaf certificate matches the TLSA
Other than extracting the relevant certificate elements for record. Other than extracting the relevant certificate elements for
comparison, no other use is made of the certificate content. comparison, no other use is made of the certificate content.
Authentication via certificate usage "3" TLSA records involves no Authentication via certificate usage DANE-EE(3) TLSA records involves
certificate authority signature checks. It also involves no server no certificate authority signature checks. It also involves no
name checks, and thus does not impose any new requirements on the server name checks, and thus does not impose any new requirements on
names contained in the server certificate (SNI is not required when the names contained in the server certificate (SNI is not required
the TLSA record matches server's default certificate). when the TLSA record matches the server's default certificate).
Two TLSA records will need to be published before updating a server's Two TLSA records MUST be published before updating a server's public
public key, one matching the currently deployed key and the other key, one matching the currently deployed key and the other matching
matching the new key scheduled to replace it. Once sufficient time the new key scheduled to replace it. Once sufficient time has
has elapsed for all DNS caches to time out the previous TLSA RRset, elapsed for all DNS caches to expire the previous TLSA RRset and
which contains only the old key, the server may be reconfigured to related signature RRsets, the server may be reconfigured to use the
use the new private key and associated public key certificate. The new private key and associated public key certificate. Once the
amount of time a server should wait before using a new key that is server is using the new key, the TLSA RR that matches the retired key
referenced by new TLSA records should be at least twice the TTL of can be removed from DNS, leaving only the RR that matches the new
the previously published TLSA records. Once the server is using a key.
new key, the obsolete TLSA RR can be removed from DNS, leaving only
the RR that matches the new key.
2.2.1.2. Certificate usage 2 TLSA records published for SMTP servers SHOULD, in most cases, be
Some domains may prefer to reduce the operational complexity of "DANE-EE(3) DANE(SPKI) SHA2-256(1)" records. Since all DANE
implementations are required to support SHA2-256, this record works
for all clients and need not change across certificate renewals with
the same key.
2.3.1.2. Certificate usage DANE-TA(2)
Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing certificate authority to create certificates employs a common issuing Certificate Authority to create certificates
for multiple TLS services, it may be simpler to publish the issuing for multiple TLS services, it may be simpler to publish the issuing
authority's public key as a trust-anchor for the certificate chains authority as a trust anchor (TA) for the certificate chains of all
of all relevant services. The TLSA RRs for each service issued by relevant services. The TLSA query domain (TLSA base domain with port
the same TA may then be CNAMEs to a common TLSA RRset that matches and protocol prefix labels) for each service issued by the same TA
the TA. In this case, the certificate chain presented in the TLS may then be set to a CNAME alias that points to a common TLSA RRset
handshake of each service SHOULD include the TA certificate, as SMTP that matches the TA.
clients cannot generally be expected to have domain-issued trust-
anchor certificates in their trusted certificate store. TLSA
Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters,
which specify the SHA-256 digest of the trust-anchor public key or
certificate respectively. As with leaf certificate rollover
discussed in Section 2.2.1.1, two such TLSA RRs need to be published
to facilitate TA certificate rollover.
The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
assured. If server operators employing these RRs universally ensure for TLS authentication MUST include the TA certificate as part of the
that the corresponding TA certificate is included in the SMTP certificate chain presented in the TLS handshake server certificate
server's TLS handshake certificate chain, clients can safely enable message even when it is a self-signed root certificate. At this
support for these RRs. If sufficiently many server administrators time, many SMTP servers are not configured with a comprehensive list
negligently omit the TA certificate from the server's TLS certificate of trust anchors, nor are they expected to at any point in the
chain, SMTP clients will be hesitant to support usage "2" TLSA RRs, future. Some MTAs will ignore all locally trusted certificates when
since mail delivery will not work to many destination domains if they processing usage DANE-TA(2) TLSA records. Thus even when the TA
do. Server operators are encouraged to implement these RRs, if they happens to be a public Certificate Authority known to the SMTP
are operationally a better fit for their organization, provided they client, authentication is likely to fail unless the TA is included in
do so with care. It is critical to not forget to include trust- the TLS server certificate message.
anchor certificates in server trust chains. SMTP client
implementations SHOULD support these TLSA RRs, unless, despite the
above warning, a non-trivial fraction of server operators fail to
publish certificate chains that include the required TA certificate.
2.2.1.3. Certificate usages 0 and 1 TLSA Publishers should publish either "DANE-TA(2) SPKI(1) Full(0)" or
"DANE-TA(2) Cert(0) SHA2-256(1)" TLSA parameters. As with leaf
certificate rollover discussed in Section 2.3.1.1, two such TLSA RRs
need to be published to facilitate TA certificate rollover.
SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0" 2.3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
or "1". SMTP clients cannot be expected to be configured with a
suitably complete set of trusted public CAs. Even with a full set of
public CAs, SMTP clients cannot (without relying on DNSSEC for secure
MX records) perform [RFC6125] server identity verification.
SMTP client treatment of TLSA RRs with certificate usages "0" or "1" SMTP servers SHOULD NOT publish TLSA RRs with certificate usage
is undefined. For example, clients MAY (will likely) treat such TLSA "PKIX-TA(0)" or "PKIX-EE(1)". SMTP clients cannot be expected to be
records as unusable. configured with a suitably complete set of trusted public CAs. Even
with a full set of public CAs, SMTP clients cannot (without relying
on DNSSEC for secure MX records and DANE for STARTTLS support
signalling) perform [RFC6125] server identity verification or prevent
STARTTLS downgrade attacks. The use of trusted public CAs offers no
added security since an attacker capable of compromising DNSSEC is
free to replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with
records bearing any convenient non-PKIX certificate usage.
SMTP client treatment of TLSA RRs with certificate usages "PKIX-
TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will
likely) treat such TLSA records as unusable.
2.3.2. Certificate matching
2.2.2. Certificate matching
When at least one usable "secure" TLSA record is found, the SMTP When at least one usable "secure" TLSA record is found, the SMTP
client SHOULD use TLSA records to authenticate the next-hop host, client SHOULD use TLSA records to authenticate the SMTP server.
mail SHOULD not be delivered via this next-hop host if authentication Messages SHOULD NOT be delivered via the SMTP server if
fails, otherwise the SMTP client is vulnerable to TLS man in the authentication fails, otherwise the SMTP client is vulnerable to MITM
middle attacks. attacks.
To match a server via a TLSA record with certificate usage "2", the To match a server via a TLSA record with certificate usage DANE-
client MUST perform name checks to ensure that it has reached the TA(2), the client MUST perform name checks to ensure that it has
correct server. In all cases the SMTP client MUST accept the TLSA reached the correct server. In all cases the SMTP client MUST accept
base domain as a valid DNS name in the server certificate. the TLSA base domain as a valid DNS name in the server certificate.
MX: If the TLSA base domain was obtained indirectly via an MX lookup TLSA records for MX hostnames: If the TLSA base domain was obtained
(it is the name of an MX exchange that may be securely CNAME indirectly via an MX lookup (including any CNAME-expanded name of
expanded), then the initial query name used in the MX lookup an MX hostname), then the original next-hop domain used in the MX
SHOULD be accepted in the peer certificate. The CNAME-expanded lookup MUST be accepted in the peer certificate. The CNAME-
initial query name SHOULD also be accepted if different from the expanded original next-hop domain MUST also be accepted if
initial query name. different from the initial query name.
Non-MX: If no MX records were found and the TLSA base domain is the TLSA records for Non-MX hostnames: If MX records were not used
CNAME-expanded initial query name, then the initial query name (e.g., if none exist) and the TLSA base domain is the CNAME-
SHOULD also be accepted. expanded original next-hop domain, then the original next-hop
domain MUST also be accepted.
Accepting certificates with the next-hop domain in addition to the Accepting certificates with the original next-hop domain in addition
next-hop MX host allows a domain with multiple MX hosts to field a to the MX hostname allows a domain with multiple MX hostnames to
single certificate bearing the email domain name across all the MX field a single certificate bearing a single domain name (i.e., the
hosts, this is also compatible with pre-DANE SMTP clients that are email domain) across all the SMTP servers. This also aids inter-
configured to look for the email domain name in server certificates. operability with pre-DANE SMTP clients that are configured to look
for the email domain name in server certificates. For example, with
"secure" DNS records as below:
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
example.com. IN MX 15 mx15.example.com.
example.com. IN MX 20 mx20.example.com.
;
mx10.example.com. IN A 192.0.2.10
_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
;
mx15.example.com. IN CNAME mxbackup.example.com.
mxbackup.example.com. IN A 192.0.2.15
; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
;
mx20.example.com. IN CNAME mxbackup.example.net.
mxbackup.example.net. IN A 198.51.100.20
_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
Certificate 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. When the SMTP server is
mx10.example.com, name checks MUST accept the TLSA base domain
"mx10.example.com". If, 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".
The SMTP client MUST NOT perform certificate usage name checks with The SMTP client MUST NOT perform certificate usage name checks with
certificate usage "3", since with usage "3" the server is certificate usage DANE-EE(3), since with usage DANE-EE(3) the server
authenticated directly by matching the TLSA RRset to its certificate is authenticated directly by matching the TLSA RRset to its
or public key without resort to any issuing authority. The certificate or public key without resorting to any issuing authority.
certificate content is ignored except in so far as it is used to The certificate content is ignored except to match the certificate or
match the certificate or public key (ASN.1 object or its digest) with public key (ASN.1 DER encoding or its digest) with the TLSA RRset.
the TLSA RRset.
To ensure that the server sends the right certificate chain, the SMTP To ensure that the server sends the right certificate chain, the SMTP
client MUST send the TLS SNI extension containing the TLSA base client MUST send the TLS SNI extension containing the TLSA base
domain. This precludes the use of SSLv2-compatible SSL HELLO by the domain. This precludes the use of the backward compatible SSL 2.0
SMTP client. The minimum SSL/TLS version for SMTP clients performing compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
DANE authentication is SSLv3. HELLO version for SMTP clients performing DANE authentication is SSL
3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
1.0 and MUST include the SNI extension. Servers that don't make use
of SNI MAY negotiate SSL 3.0 if offered by the client.
Each SMTP server MUST present a certificate chain (see [RFC2246] Each SMTP server MUST present a certificate chain (see [RFC5246]
Section 7.4.2) that matches at least one of the TLSA records. The Section 7.4.2) that matches at least one of the TLSA records. The
server MAY rely on SNI to determine which certificate chain to server MAY rely on SNI to determine which certificate chain to
present to the client. Clients that don't send SNI information may present to the client. Clients that don't send SNI information may
not see the expected certificate chain. not see the expected certificate chain.
If the server's TLSA RRset includes records with a matching type If the server's TLSA RRset includes records with a matching type
indicating a digest record (i.e., a value other than "0"), the indicating a digest record (i.e., a value other than Full(0)), a TLSA
SHA-256 digest of any object SHOULD be provided along with any other record with a SHA2-256(1) matching type SHOULD be provided along with
digest published, since clients may support only SHA-256. Unless any other digest published, since some SMTP clients may support only
SHA-256 proves vulnerable to a "second preimage" attack, it should be SHA2-256(1).
the only digest algorithm used in TLSA records.
If the server's TLSA records match the server's default certificate If the server's TLSA records match the server's default certificate
chain, the server need not support SNI. The server need not include chain, the server need not support SNI. In either case, the server
the extension in its TLS HELLO, simply returning a matching need not include the SNI extension in its TLS HELLO as simply
certificate chain is sufficient. Servers MUST NOT enforce the use of returning a matching certificate chain is sufficient. Servers MUST
SNI by clients, if the client sends no SNI extension, or sends an SNI NOT enforce the use of SNI by clients, as the client may be using
extension for an unsupported domain the server MUST simply use its unauthenticated opportunistic TLS and may not expect any particular
default certificate chain. The client may be using unauthenticated certificate from the server. If the client sends no SNI extension,
opportunistic TLS and may not expect any particular certificate from or sends an SNI extension for an unsupported domain, the server MUST
the server. simply send its default certificate chain. The reason for not
enforcing strict matching of the requested SNI hostname is that DANE
The SMTP client MAY include anonymous TLS ciphersuites in its SSL TLS clients are typically willing to accept multiple server names,
HELO. MX hosts that receive email from the Internet MUST but can only send one name in the SNI extension. The server's
interoperate with opportunistic TLS SMTP clients. If they advertise default certificate may match a different name acceptable to the
support for STARTTLS in their SMTP EHLO response, they MUST NOT fail client, e.g., the original next-hop domain.
to complete the TLS handshake merely because the SMTP client offered
some ciphersuites that do not provide for server authentication.
While server operators are under no obligation to implement or enable An SMTP client employing pre-DANE opportunistic TLS MAY include some
anonymous ciphers, no security is gained by sending certificates anonymous TLS cipher suites in its TLS HELLO in addition to at least
clients are willing to ignore. Indeed support for anonymous one non-anonymous cipher suite (since servers often do support any of
ciphersuites in the server makes audit trails more useful when the the anonymous ones). Therefore, an SMTP server MUST either select
chosen ciphersuite is logged, as this will in many cases record which some suitable non-anonymous cipher suite offered by the client, or if
clients did not care to authenticate the server. For example, the it selects an anonymous cipher suite, it MUST NOT fail to complete
Postfix SMTP server enables anonymous TLS ciphersuites by default, the handshake merely because an anonymous cipher suite was chosen.
and the Postfix SMTP client offers these at its highest preference
when server authentication is not applicable.
With opportunistic DANE TLS, both the TLS support implied by the Note that while SMTP server operators are under no obligation to
presence of DANE TLSA records and the verification parameters enable anonymous cipher suites, no security is gained by sending
necessary to authenticate the TLS peer are obtained together, certificates to clients that will ignore them. Indeed support for
therefore authentication via this protocol is expected to be less anonymous cipher suites in the server makes audit trails more
prone to connection failure caused by incompatible configuration of informative. Log entries that record connections that employed an
the client and server. anonymous cipher suite record the fact that the clients did not care
to authenticate the server.
2.2.3. Digest algorithm agility 2.3.3. Digest algorithm agility
While [RFC6698] specifies multiple digest algorithms, it does not While [RFC6698] specifies multiple digest algorithms, it does not
explicitly specify a protocol by which the SMTP client and TLSA specify a protocol by which the SMTP client and TLSA record publisher
record publisher can agree on the strongest shared algorithm. Such a can agree on the strongest shared algorithm. Such a protocol would
protocol would allow the client and server to avoid exposure to any allow the client and server to avoid exposure to any deprecated
deprecated weaker algorithms that are published for campatibilty with weaker algorithms that are published for compatibilty with less
less capable clients, but should if possible be ignored. We specify capable clients, but should be ignored when possible. We specify
such a protocol below. such a protocol below.
Suppose that a DANE TLS client authenticating TLS server considers Suppose that a DANE TLS client authenticating a TLS server considers
digest algorithm X stronger than digest algorithm Y. Suppose further digest algorithm BETTER stronger than digest algorithm WORSE.
that that a server's TLSA RRset contains some records with X as the Suppose further that a server's TLSA RRset contains some records with
digest algorithm. Suppose that for every raw public key or BETTER as the digest algorithm. Finally, suppose that for every raw
certificate object that is included in the server's TLSA RRset in public key or certificate object that is included in the server's
digest form, whenever that object appears with digest Y (with some TLSA RRset in digest form, whenever that object appears with
usage and selector) it also appears with digest X (with the same algorithm WORSE with some usage and selector it also appears with
usage and selector). In that case our client can safely ignore TLSA algorithm BETTER with the same usage and selector. In that case our
records with the weaker digest Y, because it suffices to check the client can safely ignore TLSA records with the weaker algorithm
records with the stronger algorithm X. WORSE, because it suffices to check the records with the stronger
algorithm BETTER.
We take the simplest appraoch and mandate that all published TLSA Server operators MUST ensure that for any given usage and selector,
RRsets conform to the above assumptions. Then clients can each object (certificate or public key), for which a digest
unconditionally ignore all but the (equal) strongest digest records association exists in the TLSA RRset, is published with the SAME SET
with a given usage and selector. The ordering of digest algorithms of digest algorithms as all other objects that published with that
by strength is entirely up to the client. Only the future will tell usage and selector. In other words, for each usage and selector, the
which algoritms might be weakened by new attacks and when. records with non-zero matching types will correspond to on a cross-
product of a set of underlying objects and a fixed set of digest
algorithms that apply uniformly to all the objects.
Therefore, server operators MUST ensure that for any given usage and To achieve digest algorithm agility, all published TLSA RRsets for
selector, ALL objects with certificate association data with that use with opportunistic DANE TLS for SMTP MUST conform to the above
usage and selector that are published with a digest matching type are requirements. Then, for each combination of usage and selector, SMTP
published with the SAME SET of digests (non-zero matching types). In clients can simply ignore all digest records except those that employ
other words, for each usage and selector, the records with non-zero the strongest digest algorithm. The ordering of digest algorithms by
matching types will be a cross-product of a set of underlying objects strength is not specified in advance, it is entirely up to the SMTP
and a fixed set of digests that apply uniformly to all the objects. client. SMTP client implementations SHOULD make the digest algorithm
preference order configurable. Only the future will tell which
algorithms might be weakened by new attacks and when.
Records with a matching type of "0", that publish the full object Note, TLSA records with a matching type of Full(0), that publish the
value play no role in digest algorithm agility. They neither preempt full value of a certificate or public key object, play no role in
the processing of records that employ digests, nor are they ignored digest algorithm agility. They neither trump the processing of
in the presence of any digest records. records that employ digests, nor are they ignored in the presence of
any records with a digest (i.e. non-zero) matching type.
SMTP clients SHOULD use digest algorithm agility when processing the SMTP clients SHOULD use digest algorithm agility when processing the
DANE TLSA records of an SMTP server. Algorithm agility is to be DANE TLSA records of an SMTP server. Algorithm agility is to be
applied after first discarding any unusable or malformed records applied after first discarding any unusable or malformed records
(unsupported digest algorithm, or incorrect digest length). Thus, (unsupported digest algorithm, or incorrect digest length). Thus,
for each usage and selector, the client SHOULD only process any for each usage and selector, the client SHOULD process only any
usable records with a matching type of "0" and any usable records usable records with a matching type of Full(0) and the usable records
whose digest is believed to be the strongest among usable records whose digest algorithm is believed to be the strongest among usable
with the same usage and selector. records with the given usage and selector.
The main impact of this requirement is on key rotation, when the TLSA The main impact of this requirement is on key rotation, when the TLSA
RRset is pre-populated with digests of new certificates or public RRset is pre-populated with digests of new certificates or public
keys, before these replace or augment their predecessors. Were the keys, before these replace or augment their predecessors. Were the
newly introduced RRs to include previously unused digest algorithms, newly introduced RRs to include previously unused digest algorithms,
clients that employ this protocol could potentially ignore all the clients that employ this protocol could potentially ignore all the
digests corresponding to the currently deployed certificates causing digests corresponding to the current keys or certificates, causing
connectivity issues until the new keys or certificates are deployed. connectivity issues until the new keys or certificates are deployed.
Similarly, publishing new records with fewer digests could cause Similarly, publishing new records with fewer digests could cause
problems once the new keys are deployed. problems for clients using cached TLSA RRsets that list both the old
and new objects once the new keys are deployed.
Server operators SHOULD follow the following rules. When adding or
removing objects from the TLSA RRset (e.g. during key rotation), DO
NOT change the set of digests used, change just the list of objects.
When changing the set of digests used, change only the set of
digests, and generate a new RRset in which all the current objects
are re-published with the new set of digests.
The client-side of this "digest algorithm agility" protocol is
enabled by default in the first DANE for SMTP implementation. For
key rotation to work non-disruptively server operators MUST ensure
that their TLSA records conform with the above specification.
3. Opportunistic TLS for Submission
Prior to [RFC6409], the SMTP submission protocol was a poster-child
for PKIX TLS. The MUA typically connects to one or more submission
servers explicitly configured by the user. There is no indirection
via insecure MX records, and unlike web browsers, there is no need to
authenticate a large set of TLS servers. Once TLS is enabled for the
desired submission server or servers, provided the server certificate
is correctly maintained, the MUA is able to reliably use TLS to
authenticate the submission server.
[RFC6186] aims to simplify the configuration of the MUA submission To avoid problems, server operators SHOULD apply the following
service by dynamically deriving the submission service from the strategy:
user's email address. This is done via SRV records, but at the cost
of introducing the same TLS security problems faced by MTA to MTA
SMTP. Prompting the user when the SRV record domain is different
from the email domain is not a robust solution.
The protocol defined in this memo can also be used to secure o When changing the set of objects published via the TLSA RRset
submission service discovery. If the email domain is DNSSEC signed, (e.g. during key rotation), DO NOT change the set of digest
the SRV records are "secure" and the SRV host publishes secure TLSA algorithms used; change just the list of objects.
records for submission, then the MUA can safely auto-configure to
authenticate the submission server via DANE. When DANE TLSA records
are not available, the client SHOULD fall back to legacy behavior
(this may involve prompting the user to accept the resulting server
and perhaps "pin" its certificate).
Specifically, MUAs that dynamically determine the submission server o When changing the set of digest algorithms, change only the set of
via SRV records SHOULD support DNSSEC and DANE TLSA records. They algorithms, and generate a new RRset in which all the current
SHOULD use TLSA records to authenticate the server. The processing objects are re-published with the new set of digest algorithms.
of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA
with SRV records replaced by corresponding MX records.
Just as with MX service on port 25, SMTP submission servers SHOULD After either of these two changes are made, the new TLSA RRset should
NOT publish usage 0 or 1 TLSA associations, and MUAs that support be left in place long enough that the older TLSA RRset can be flushed
DANE TLSA are not expected to trust a full list of public CAs. from caches before making another change.
Server certificate subjectAltNames should include at least the server
name. When the server administrator is able to obtain a certificate
for the email domain, the server certificate should also include the
email domain name. MUAs that are not able to support DNSSEC may then
be able to authenticate the server domain. If it is practical to
field additional certificates for hosted domains, SNI may be used by
the server to select the appropriate domain's certificate.
4. Mandatory TLS Security 3. Mandatory TLS Security
An MTA implementing this protocol may require a stronger security An MTA implementing this protocol may require a stronger security
assurance when sending email to selected destinations to which the assurance when sending email to selected destinations. The sending
sending organization sends sensitive email and may have regulatory organization may need to send sensitive email and/or may have
obligations to protect its content. This protocol is not in conflict regulatory obligations to protect its content. This protocol is not
with such a requirement, and in fact it can often simplify in conflict with such a requirement, and in fact can often simplify
authenticated delivery to such destinations. authenticated delivery to such destinations.
Specifically, with domains that publish DANE TLSA records for their Specifically, with domains that publish DANE TLSA records for their
MX hosts a sending MTA can be configured to use the receiving MX hostnames, a sending MTA can be configured to use the receiving
domains's DANE TLSA records to authenticate the corresponding MX domains's DANE TLSA records to authenticate the corresponding SMTP
hosts, thereby obviating the complex manual provisioning process. In server. Authentication via DANE TLSA records is easier to manage, as
anticipation of, or in response to, a failure to obtain the expected changes in the receiver's expected certificate properties are made on
TLSA records, the sending system's administrator may choose from a the receiver end and don't require manually communicated
selection of fallback options, if supported by the sending MTA: configuration changes. With mandatory DANE TLS, when no usable TLSA
records are found, message delivery is delayed. Thus, mail is only
sent when an authenticated TLS channel is established to the remote
SMTP server.
o Defer mail if no usable TLSA records are found. This is useful Administrators of mail servers that employ mandatory DANE TLS, need
when the destination is known to publish TLSA records, and lack of to carefully monitor their mail logs and queues. If a partner domain
TLSA records is most likely a transient misconfiguration. unwittingly misconfigures their TLSA records, disables DNSSEC, or
misconfigures SMTP server certificate chains, mail will be delayed.
o Authenticate the peer via a manually configured certificate 4. Operational Considerations
digest. This may be obtained, for example, after a problem is
detected and confirmed to be valid by some out-of-band mechanism.
o Authenticate the peer via the existing public CA PKI, if the peer 4.1. Client Operational Considerations
server has usable CA issued certificates. In many cases the
sending MTA will need custom certificate name matching rules to
match the destination's gateways. And the sending server must
explicitly configure policy for the destination to always require
TLS to prevent MITM attacks.
o Send via unauthenticated mandatory TLS. This is useful if the SMTP clients may deploy opportunistic DANE TLS incrementally by
requirement is merely to always encrypt transmissions to protect enabling it only for selected sites, or may occasionally need to
against only eavesdropping, and the possibility of MITM attacks is disable opportunistic DANE TLS for peers that fail to interoperate
less of a concern than timely email delivery. due to misconfiguration or software defects on either end. Unless
local policy specifies that opportunistic DANE TLS is not to be used
for a particular destination, client MUST NOT deliver mail via a
server whose certificate chain fails to match at least one TLSA
record when usable TLSA records are available.
It should be noted that barring administrator intervention, email 4.2. Publisher Operational Considerations
SHOULD be deferred when DNSSEC lookups fail, (as distinct from
"secure" non-existence of TLSA records, or secure evidence that the
domain is no longer signed). In addition to configuring fallback
strategies when TLSA records are unexpectedly absent, administrators
may, in hopefully rare cases, need to disable DNSSEC lookups for a
destination to work around a DNSSEC outage.
5. Acknowledgements SMTP servers that publish certificate usage DANE-TA(2) associations
MUST include the TA certificate in their TLS server certificate
chain, even when that TA certificate is a self-signed root
certificate.
The authors would like to extend great thanks to Tony Finch, who TLSA Publishers must follow the digest agility guidelines in
started the original version of a DANE SMTP document. His work is Section 2.3.3 and must make sure that all objects published in digest
greatly appreciated and has been incorporated into this document. form for a particular usage and selector are published with the same
The authors would like to additionally thank Phil Pennock for his set of digest algorithms.
comments and advice on this document.
Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded TLSA Publishers should follow the TLSA publication size guidance
me into participating in DANE working group discussions. Thanks to found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
Paul Hoffman who motivated me to produce this memo and provided
feedback on early drafts. Thanks also to Wietse Venema who created
Postfix, and patiently guided the Postfix DANE implementation to
production quality.
6. Security Considerations 5. Security Considerations
This protocol leverages DANE TLSA records to implement MITM resistant This protocol leverages DANE TLSA records to implement MITM resistant
opportunistic channel security for SMTP. For destination domains opportunistic channel security for SMTP. For destination domains
that sign their MX records and publish signed TLSA records for their that sign their MX records and publish signed TLSA records for their
MX hosts, this protocol allows sending MTAs (and perhaps dynamically MX hostnames, this protocol allows sending MTAs to securely discover
configured MUAs) to securely discover both the availability of TLS both the availability of TLS and how to authenticate the destination.
and how to authenticate the destination.
This protocol does not aim to secure all SMTP traffic, as that is not This protocol does not aim to secure all SMTP traffic, as that is not
practical until DNSSEC and DANE adoption are universal. The practical until DNSSEC and DANE adoption are universal. The
incremental deployment provided by following this specification is a incremental deployment provided by following this specification is a
best possible path for securing SMTP. This protocol coexists and best possible path for securing SMTP. This protocol coexists and
interoperates with the existing insecure Internet email backbone. interoperates with the existing insecure Internet email backbone.
The protocol does not preclude existing non-opportunistic SMTP TLS The protocol does not preclude existing non-opportunistic SMTP TLS
security arrangements, which can continue to be used as before via security arrangements, which can continue to be used as before via
manual configuration and negotiated out-of-band key and TLS manual configuration with negotiated out-of-band key and TLS
configuration exchanges. configuration exchanges.
Opportunistic SMTP TLS depends critically on DNSSEC for downgrade Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
resistance and secure resolution of the destination name. If DNSSEC resistance and secure resolution of the destination name. If DNSSEC
is compromised, it is not possible to fall back on the public CA PKI is compromised, it is not possible to fall back on the public CA PKI
to prevent MITM attacks. A successful breach of DNSSEC enables the to prevent MITM attacks. A successful breach of DNSSEC enables the
attacker to publish TLSA usage 3 certificate associations, and attacker to publish TLSA usage 3 certificate associations, and
thereby bypass any security benefit the legitimate domain owner might thereby bypass any security benefit the legitimate domain owner might
hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
public CA PKI support in existing MTA deployments, deprecating public CA PKI support in existing MTA deployments, avoiding
certificate usages 0 and 1 in this specifications improves certificate usages 0 and 1 simplifies implementation and deployment
interoperability without degrading security. with no adverse security consequences.
7. Normative References Implementations must strictly follow the portions of this
specification that indicate when it is appropriate to initiate a non-
authenticated connection or cleartext connection to a SMTP server.
Specifically, in order to prevent downgrade attacks on this protocol,
implementation must not initiate a connection when this specification
indicates a particular SMTP server must be considered unreachable.
6. IANA considerations
This specification requires no support from IANA.
7. Acknowledgements
The authors would like to extend great thanks to Tony Finch, who
started the original version of a DANE SMTP document. His work is
greatly appreciated and has been incorporated into this document.
The authors would like to additionally thank Phil Pennock for his
comments and advice on this document.
Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
to begin work on this memo and provided feedback on early drafts.
Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
valuable review comments. Thanks also to Wietse Venema who created
Postfix, and whose advice and feedback were essential to the
development of the Postfix DANE implementation.
8. References
8.1. Normative References
[I-D.ietf-dane-ops] [I-D.ietf-dane-ops]
Dukhovni, V. and W. Hardaker, "DANE TLSA implementation Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
and operational guidance", draft-ietf-dane-ops-00 (work in and operational guidance", draft-ietf-dane-ops-00 (work in
progress), October 2013. progress), October 2013.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
skipping to change at page 20, line 28 skipping to change at page 28, line 28
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, March 2011. Submission/Access Services", RFC 6186, March 2011.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011. STD 72, RFC 6409, November 2011.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
8.2. Informative References
[I-D.ietf-dane-registry-acronyms]
Gudmundsson, O., "Adding acronyms to simplify DANE
conversations", draft-ietf-dane-registry-acronyms-01 (work
in progress), October 2013.
[I-D.ietf-dane-smtp]
Finch, T., "Secure SMTP using DNS-Based Authentication of
Named Entities (DANE) TLSA records.", draft-ietf-dane-
smtp-01 (work in progress), February 2013.
[I-D.ietf-dane-srv]
Finch, T., "Using DNS-Based Authentication of Named
Entities (DANE) TLSA records with SRV and MX records.",
draft-ietf-dane-srv-02 (work in progress), February 2013.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394,
October 2011.
[RFC6895] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, April 2013.
Authors' Addresses Authors' Addresses
Viktor Dukhovni Viktor Dukhovni
Unaffiliated Unaffiliated
Email: ietf-dane@dukhovni.org Email: ietf-dane@dukhovni.org
Wes Hardaker Wes Hardaker
Parsons Parsons
P.O. Box 382 P.O. Box 382
 End of changes. 121 change blocks. 
660 lines changed or deleted 1076 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/