< draft-ietf-dane-smtp-with-dane-08.txt   draft-ietf-dane-smtp-with-dane-09.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Two Sigma Internet-Draft Two Sigma
Intended status: Standards Track W. Hardaker Intended status: Standards Track W. Hardaker
Expires: October 25, 2014 Parsons Expires: November 7, 2014 Parsons
April 23, 2014 May 6, 2014
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-08 draft-ietf-dane-smtp-with-dane-09
Abstract Abstract
This memo describes a downgrade-resistant protocol for SMTP transport This memo describes a downgrade-resistant protocol for SMTP transport
security between Mail Transfer Agents (MTAs) based on the DNS-Based security between Mail Transfer Agents (MTAs) based on the DNS-Based
Authentication of Named Entities (DANE) TLSA DNS record. Adoption of Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
this protocol enables an incremental transition of the Internet email this protocol enables an incremental transition of the Internet email
backbone to one using encrypted and authenticated Transport Layer backbone to one using encrypted and authenticated Transport Layer
Security (TLS). Security (TLS).
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 25, 2014. This Internet-Draft will expire on November 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 5 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 5 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
1.3.2. Insecure server name without DNSSEC . . . . . . . . . 6 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
1.3.3. Sender policy does not scale . . . . . . . . . . . . 7 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7
1.3.4. Too many certification authorities . . . . . . . . . 7 1.3.4. Too many certification authorities . . . . . . . . . 8
2. Opportunistic DANE TLS . . . . . . . . . . . . . . . . . . . 8 2. Identifying applicable TLSA records . . . . . . . . . . . . . 8
2.1. DNS errors, bogus and indeterminate responses . . . . . . 8 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8
2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1. DNS errors, bogus and indeterminate responses . . . . 8
2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
2.1.3. Stub resolver considerations . . . . . . . . . . . . 11
2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13
2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 14 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 16 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
2.3. DANE authentication . . . . . . . . . . . . . . . . . . . 17 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
2.3.1. TLSA certificate usages . . . . . . . . . . . . . . . 18 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
2.3.2. Certificate matching . . . . . . . . . . . . . . . . 22 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20
2.3.3. Key rotation . . . . . . . . . . . . . . . . . . . . 24 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21
2.3.4. Digest algorithm agility . . . . . . . . . . . . . . 24 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22
3. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 26 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23
4. Note on DANE for Message User Agents . . . . . . . . . . . . 26 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23
5. Interoperability considerations . . . . . . . . . . . . . . . 27 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 23
5.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3. Reference identifier matching . . . . . . . . . . . . 24
5.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28 4. Server key management . . . . . . . . . . . . . . . . . . . . 25
6. Operational Considerations . . . . . . . . . . . . . . . . . 28 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
6.1. Client Operational Considerations . . . . . . . . . . . . 28 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
6.2. Publisher Operational Considerations . . . . . . . . . . 29 7. Note on DANE for Message User Agents . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Interoperability considerations . . . . . . . . . . . . . . . 29
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Client Operational Considerations . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 32 9.2. Publisher Operational Considerations . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This memo specifies a new connection security model for Message This memo specifies a new connection security model for Message
Transfer Agents (MTAs). This model is motivated by key features of Transfer Agents (MTAs). This model is motivated by key features of
inter-domain SMTP delivery, in particular the fact that the inter-domain SMTP delivery, in particular the fact that the
destination server is selected indirectly via DNS Mail Exchange (MX) destination server is selected indirectly via DNS Mail Exchange (MX)
records and that with MTA to MTA SMTP the use of TLS is generally records and that neither email addresses nor MX hostnames signal a
opportunistic. requirement for either secure or cleartext transport. Therefore,
aside from a few manually configured exceptions, SMTP transport
security is of necessity opportunistic.
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. It enables an incremental transition of the email backbone
to authenticated TLS delivery, with increased global protection as
adoption increases.
With opportunistic DANE TLS, traffic from SMTP clients to domains
that publish "usable" DANE TLSA records in accordance with this memo
is authenticated and encrypted. Traffic from legacy clients or to
domains that do not publish TLSA records will continue to be sent in
the same manner as before, via manually configured security, (pre-
DANE) opportunistic TLS or just cleartext SMTP.
Problems with existing use of TLS in MTA to MTA SMTP that motivate Problems with existing use of TLS in MTA to MTA SMTP that motivate
this specification are described in Section 1.3. The specification this specification are described in Section 1.3. The specification
itself follows in Section 2. Then, in Section 3, we discuss itself follows in Section 2 and Section 3 which describe respectively
application of DANE TLS to destinations for which channel integrity how to locate and use DANE TLSA records with SMTP. In Section 6, we
and confidentiality are mandatory. In Section 4 we briefly comment discuss application of DANE TLS to destinations for which channel
on potential applicability of this specification to Message User integrity and confidentiality are mandatory. In Section 7 we briefly
Agents. comment on potential applicability of this specification to Message
User Agents.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The following terms or concepts are used through the document: The following terms or concepts are used through the document:
skipping to change at page 4, line 7 skipping to change at page 4, line 35
available, message transmission takes place in the clear. MX available, message transmission takes place in the clear. MX
record indirection generally precludes authentication even when record indirection generally precludes authentication even when
TLS is available. TLS is available.
reference identifier: (Special case of [RFC6125] definition). One reference identifier: (Special case of [RFC6125] definition). One
of the domain names associated by the SMTP client with the of the domain names associated by the SMTP client with the
destination SMTP server for performing name checks on the server destination SMTP server for performing name checks on the server
certificate. When name checks are applicable, at least one of the certificate. When name checks are applicable, at least one of the
reference identifiers MUST match an [RFC6125] DNS-ID (or if none reference identifiers MUST match an [RFC6125] DNS-ID (or if none
are present the [RFC6125] CN-ID) of the server certificate (see are present the [RFC6125] CN-ID) of the server certificate (see
Section 2.3.2.3). Section 3.2.3).
MX hostname: The RRDATA of an MX record consists of a 16 bit MX hostname: The RRDATA of an MX record consists of a 16 bit
preference followed by a Mail Exchange domain name (see [RFC1035], preference followed by a Mail Exchange domain name (see [RFC1035],
Section 3.3.9). We will use the term "MX hostname" to refer to 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 the latter, that is, the DNS domain name found after the
preference value in an MX record. Thus an "MX hostname" is preference value in an MX record. Thus an "MX hostname" is
specifically a reference to a DNS domain name, rather than any specifically a reference to a DNS domain name, rather than any
host that bears that name. host that bears that name.
delayed delivery: Email delivery is a multi-hop store & forward delayed delivery: Email delivery is a multi-hop store & forward
skipping to change at page 6, line 4 skipping to change at page 6, line 28
either the recipient address or the MX record, a new signaling either the recipient address or the MX record, a new signaling
mechanism is required to indicate when channel security is possible mechanism is required to indicate when channel security is possible
and should be used. The publication of TLSA records allows server and should be used. The publication of TLSA records allows server
operators to securely signal to SMTP clients that TLS is available operators to securely signal to SMTP clients that TLS is available
and should be used. DANE TLSA makes it possible to simultaneously and should be used. DANE TLSA makes it possible to simultaneously
discover which destination domains support secure delivery via TLS discover which destination domains support secure delivery via TLS
and how to verify the authenticity of the associated SMTP services, and how to verify the authenticity of the associated SMTP services,
providing a path forward to ubiquitous SMTP channel security. providing a path forward to ubiquitous SMTP channel security.
1.3.1. STARTTLS downgrade attack 1.3.1. STARTTLS downgrade attack
The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
protocol in a multi-hop store & forward email delivery process. SMTP protocol in a multi-hop store & forward email delivery process. SMTP
envelope recipient addresses are not transport addresses and are envelope recipient addresses are not transport addresses and are
security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and
its corresponding secured version, HTTPS, where the use of TLS is its corresponding secured version, HTTPS, where the use of TLS is
signalled via the URI scheme, email recipient addresses do not signaled via the URI scheme, email recipient addresses do not
directly signal transport security policy. Indeed, no such signaling directly signal transport security policy. Indeed, no such signaling
could work well with SMTP since TLS encryption of SMTP protects email could work well with SMTP since TLS encryption of SMTP protects email
traffic on a hop-by-hop basis while email addresses could only traffic on a hop-by-hop basis while email addresses could only
express end-to-end policy. express end-to-end policy.
With no mechanism available to signal transport security policy, SMTP With no mechanism available to signal transport security policy, SMTP
relays employ a best-effort "opportunistic" security model for TLS. relays employ a best-effort "opportunistic" security model for TLS.
A single SMTP server TCP listening endpoint can serve both TLS and 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 non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
command ([RFC3207]). The server signals TLS support to the client command ([RFC3207]). The server signals TLS support to the client
skipping to change at page 8, line 17 skipping to change at page 8, line 42
anchors would need to be comprehensive in order to avoid bouncing anchors would need to be comprehensive in order to avoid bouncing
mail addressed to sites that employ unknown Certification mail addressed to sites that employ unknown Certification
Authorities. Authorities.
On the other hand, each trusted CA can issue certificates for any On the other hand, each trusted CA can issue certificates for any
domain. If even one of the configured CAs is compromised or operated domain. If even one of the configured CAs is compromised or operated
by an adversary, it can subvert TLS security for all destinations. by an adversary, it can subvert TLS security for all destinations.
Any set of CAs is simultaneously both overly inclusive and not Any set of CAs is simultaneously both overly inclusive and not
inclusive enough. inclusive enough.
2. Opportunistic DANE TLS 2. Identifying applicable TLSA records
Neither email addresses nor MX hostnames signal a requirement for
either secure or cleartext transport. Therefore, aside from a few
manually configured exceptions, SMTP transport security is of
necessity opportunistic.
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.
With opportunistic DANE TLS, traffic from SMTP clients to domains
that publish "usable" DANE TLSA records in accordance with this memo
is authenticated and encrypted. Traffic from non-compliant clients
or to domains that do not publish TLSA records will continue to be
sent in the same manner as before, via manually configured security,
(pre-DANE) opportunistic TLS or just cleartext SMTP.
2.1. DNS errors, bogus and indeterminate responses 2.1. DNS considerations
2.1.1. DNS errors, bogus and indeterminate responses
An SMTP client that implements opportunistic DANE TLS per this An SMTP client that implements opportunistic DANE TLS per this
specification depends critically on the integrity of DNSSEC lookups, specification depends critically on the integrity of DNSSEC lookups,
as discussed in Section 1.3. This section lists the DNS resolver as discussed in Section 1.3. This section lists the DNS resolver
requirements needed to avoid downgrade attacks when using requirements needed to avoid downgrade attacks when using
opportunistic DANE TLS. opportunistic DANE TLS.
A DNS lookup may signal an error or return a definitive answer. A A DNS lookup may signal an error or return a definitive answer. A
security-aware resolver must be used for this specification. security-aware resolver must be used for this specification.
Security-aware resolvers will indicate the security status of a DNS Security-aware resolvers will indicate the security status of a DNS
RRset with one of four possible values defined in Section 4.3 of RRset with one of four possible values defined in Section 4.3 of
skipping to change at page 10, line 34 skipping to change at page 10, line 40
either no records of the requested type or non-existence of the query either no records of the requested type or non-existence of the query
domain, the response is not a DNS error condition. The DNS client domain, the response is not a DNS error condition. The DNS client
has not been left without an answer; it has learned that records of has not been left without an answer; it has learned that records of
the requested type do not exist. the requested type do not exist.
Security-aware stub resolvers will, of course, also signal DNS lookup Security-aware stub resolvers will, of course, also signal DNS lookup
errors in other cases, for example when processing a "ServFail" errors in other cases, for example when processing a "ServFail"
RCODE, which will not have an associated DNSSEC status. All lookup RCODE, which will not have an associated DNSSEC status. All lookup
errors are treated the same way by this specification, regardless of errors are treated the same way by this specification, regardless of
whether they are from a "bogus" or "indeterminate" DNSSEC status or whether they are from a "bogus" or "indeterminate" DNSSEC status or
from a more generic DNS error: the information that was requested can from a more generic DNS error: the information that was requested
not be obtained by the security-aware resolver at this time. A cannot be obtained by the security-aware resolver at this time. A
lookup error is thus a failure to obtain the relevant RRset if it 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. exists, or to determine that no such RRset exists when it does not.
In contrast to a "bogus" or an "indeterminate" response, an In contrast to a "bogus" or an "indeterminate" response, an
"insecure" DNSSEC response is not an error, rather it indicates that "insecure" DNSSEC response is not an error, rather it indicates that
the target DNS zone is either securely opted out of DNSSEC validation the target DNS zone is either securely opted out of DNSSEC validation
or is not connected with the DNSSEC trust anchors being used. or is not connected with the DNSSEC trust anchors being used.
Insecure results will leave the SMTP client with degraded channel Insecure results will leave the SMTP client with degraded channel
security, but do not stand in the way of message delivery. See security, but do not stand in the way of message delivery. See
section Section 2.2 for further details. section Section 2.2 for further details.
When a stub resolver receives a response containing a CNAME alias, it 2.1.2. DNS error handling
will generally restart the query at the target of the alias, and
should do so recursively up to some configured or implementation-
dependent recursion limit. If at any stage of recursive CNAME
expansion a query fails, the stub resolver's lookup of the original
requested records will result in a failure status being returned. If
at any stage of recursive expansion the response is "insecure", then
it and all subsequent results (in particular, the final result) MUST
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.
When a DNS lookup failure (error or "bogus" or "indeterminate" as When a DNS lookup failure (error or "bogus" or "indeterminate" as
defined above) prevents an SMTP client from determining which SMTP defined above) prevents an SMTP client from determining which SMTP
server or servers it should connect to, message delivery MUST be server or servers it should connect to, message delivery MUST be
delayed. This naturally includes, for example, the case when a delayed. This naturally includes, for example, the case when a
"bogus" or "indeterminate" response is encountered during MX "bogus" or "indeterminate" response is encountered during MX
resolution. When multiple MX hostnames are obtained from a resolution. When multiple MX hostnames are obtained from a
successful MX lookup, but a later DNS lookup failure prevents network successful MX lookup, but a later DNS lookup failure prevents network
address resolution for a given MX hostname, delivery may proceed via address resolution for a given MX hostname, delivery may proceed via
any remaining MX hosts. any remaining MX hosts.
When a particular SMTP server is selected as the delivery When a particular SMTP server is securely identified as the delivery
destination, a set of DNS lookups must be performed to discover any destination, a set of DNS lookups (Section 2.2) MUST be performed to
related TLSA records. If any DNS queries used to locate TLSA records locate any related TLSA records. If any DNS queries used to locate
fail (be it due to "bogus" or "indeterminate" records, timeouts, TLSA records fail (be it due to "bogus" or "indeterminate" records,
malformed replies, ServFails, etc.), then the SMTP client MUST treat timeouts, malformed replies, ServFails, etc.), then the SMTP client
that server as unreachable and MUST NOT deliver the message via that MUST treat that server as unreachable and MUST NOT deliver the
server. If no servers are reachable, delivery is delayed. message via that server. If no servers are reachable, delivery is
delayed.
In what follows, we will only describe what happens when all relevant In what follows, we will only describe what happens when all relevant
DNS queries succeed. If any DNS failure occurs, the SMTP client MUST DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
behave as described in this section, by skipping the problem SMTP behave as described in this section, by skipping the problem SMTP
server, or the problem destination. Queries for candidate TLSA server, or the problem destination. Queries for candidate TLSA
records are explicitly part of "all relevant DNS queries" and SMTP records are explicitly part of "all relevant DNS queries" and SMTP
clients MUST NOT continue to connect to an SMTP server or destination clients MUST NOT continue to connect to an SMTP server or destination
whose TLSA record lookup fails. whose TLSA record lookup fails.
2.1.3. Stub resolver considerations
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 [RFC6672].
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 a stub resolver returns a response containing a CNAME alias that
does not also contain the corresponding query results for the target
of the alias, the SMTP client will need to repeat the query at the
target of the alias, and should do so recursively up to some
configured or implementation-dependent recursion limit. If at any
stage of CNAME expansion an error is detected, the lookup of the
original requested records MUST be considered to have failed.
Whether a chain of CNAME records was returned in a single stub
resolver response or via explicit recursion by the SMTP client, if at
any stage of recursive expansion an "insecure" CNAME record is
encountered, then it and all subsequent results (in particular, the
final result) MUST be considered "insecure" regardless of whether any
earlier CNAME records leading to the "insecure" record were "secure".
Note, a security-aware non-validating stub resolver may return to the
SMTP client an "insecure" reply received from a validating recursive
resolver that contains a CNAME record along with additional answers
recursively obtained starting at the target of the CNAME. In this
all that one can say is that some record in the set of records
returned is "insecure", but it is possible that the initial CNAME
record and a subset of the subsequent records are "secure".
If the SMTP client needs to determine the security status of the DNS
zone containing the initial CNAME record, it may need to issue an a
separate query of type "CNAME" that returns only the initial CNAME
record. In particular in Section 2.2.2 when insecure A or AAAA
records are found for an SMTP server via a CNAME alias, it may be
necessary to perform an additional CNAME query to determine whether
the DNS zone in which the alias is published is signed.
2.2. TLS discovery 2.2. TLS discovery
As noted previously (in Section 1.3.1), opportunistic TLS with SMTP As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
servers that advertise TLS support via STARTTLS is subject to an MITM servers that advertise TLS support via STARTTLS is subject to an MITM
downgrade attack. Also some SMTP servers that are not, in fact, TLS downgrade attack. Also some SMTP servers that are not, in fact, TLS
capable erroneously advertise STARTTLS by default and clients need to capable erroneously advertise STARTTLS by default and clients need to
be prepared to retry cleartext delivery after STARTTLS fails. In be prepared to retry cleartext delivery after STARTTLS fails. In
contrast, DNSSEC validated TLSA records MUST NOT be published for contrast, DNSSEC validated TLSA records MUST NOT be published for
servers that do not support TLS. Clients can safely interpret their servers that do not support TLS. Clients can safely interpret their
presence as a commitment by the server operator to implement TLS and presence as a commitment by the server operator to implement TLS and
skipping to change at page 12, line 29 skipping to change at page 13, line 26
An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
records: records:
A connection to the MTA SHOULD be made using (pre-DANE) A connection to the MTA SHOULD be made using (pre-DANE)
opportunistic TLS, this includes using cleartext delivery when the opportunistic TLS, this includes using cleartext delivery when the
remote SMTP server does not appear to support TLS. The MTA MAY remote SMTP server does not appear to support TLS. The MTA MAY
retry in cleartext when delivery via TLS fails either during the retry in cleartext when delivery via TLS fails either during the
handshake or even during data transfer. handshake or even during data transfer.
Any lookup error: Lookup errors, including "bogus" and Any lookup error: Lookup errors, including "bogus" and
"indeterminate", as explained in Section 2.1 MUST result in "indeterminate", as explained in Section 2.1.1 MUST result in
falling back to the next SMTP server or delayed delivery. falling back to the next SMTP server or delayed delivery.
An SMTP client MAY be configured to require DANE verified delivery An SMTP client MAY be configured to require DANE verified delivery
for some destinations. We will call such a configuration "mandatory for some destinations. We will call such a configuration "mandatory
DANE TLS". With mandatory DANE TLS, delivery proceeds only when DANE TLS". With mandatory DANE TLS, delivery proceeds only when
"secure" TLSA records are used to establish an encrypted and "secure" TLSA records are used to establish an encrypted and
authenticated TLS channel with the SMTP server. authenticated TLS channel with the SMTP server.
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 [RFC6672].
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 When the original next-hop destination is an address literal, rather
than a DNS domain, DANE TLS does not apply. Delivery proceeds using than a DNS domain, DANE TLS does not apply. Delivery proceeds using
any relevant security policy configured by the MTA administrator. any relevant security policy configured by the MTA administrator.
Similarly, when an MX RRset incorrectly lists a network address in Similarly, when an MX RRset incorrectly lists a network address in
lieu of an MX hostname, if the MTA chooses to connect to the network lieu of an MX hostname, if the MTA chooses to connect to the network
address DANE TLSA does not apply for such a connection. address DANE TLSA does not apply for such a connection.
In the subsections that follow we explain how to locate the SMTP In the subsections that follow we explain how to locate the SMTP
servers and the associated TLSA records for a given next-hop servers and the associated TLSA records for a given next-hop
destination domain. We also explain which name or names are to be destination domain. We also explain which name or names are to be
used in identity checks of the SMTP server certificate. used in identity checks of the SMTP server certificate.
2.2.1. MX resolution 2.2.1. MX resolution
In this section we consider next-hop domains that are subject to MX In this section we consider next-hop domains that are subject to MX
resolution and have MX records. The TLSA records and the associated resolution and have MX records. The TLSA records and the associated
base domain are derived separately for each MX hostname that is used base domain are derived separately for each MX hostname that is used
to attempt message delivery. Clearly, if DANE TLS security is to to attempt message delivery. DANE TLS can authenticate message
apply to message delivery via any of the SMTP servers, the MX records delivery to the intended next-hop domain only when the MX records are
must be obtained securely via a DNSSEC validated MX lookup. obtained securely via a DNSSEC validated lookup.
MX records MUST be sorted by preference; an MX hostname with a worse MX records MUST be sorted by preference; an MX hostname with a worse
(numerically higher) MX preference that has TLSA records MUST NOT (numerically higher) MX preference that has TLSA records MUST NOT
preempt an MX hostname with a better (numerically lower) preference preempt an MX hostname with a better (numerically lower) preference
that has no TLSA records. In other words, prevention of delivery that has no TLSA records. In other words, prevention of delivery
loops by obeying MX preferences MUST take precedence over channel loops by obeying MX preferences MUST take precedence over channel
security considerations. Even with two equal-preference MX records, security considerations. Even with two equal-preference MX records,
an MTA is not obligated to choose the MX hostname that offers more an MTA is not obligated to choose the MX hostname that offers more
security. Domains that want secure inbound mail delivery need to security. Domains that want secure inbound mail delivery need to
ensure that all their SMTP servers and MX records are configured ensure that all their SMTP servers and MX records are configured
accordingly. accordingly.
In the language of [RFC5321] Section 5.1, the original next-hop 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 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 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 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.
If the MX RRset (or any CNAME leading to it) is "insecure" (see If the MX RRset (or any CNAME leading to it) is "insecure" (see
Section 2.1), DANE TLS does not apply, and delivery proceeds via pre- Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
DANE opportunistic TLS. Otherwise (assuming no DNS errors or "bogus" pre-DANE opportunistic TLS. That said, the protocol in this memo is
/"indeterminate" responses), the MX RRset is "secure", and the SMTP an "opportunistic security" protocol, meaning that it strives to
client MUST treat each MX hostname as a separate non-MX destination communicate with each peer as securely as possible, while maintaining
for opportunistic DANE TLS as described in Section 2.2.2. When, for broad interoperability. Therefore, the SMTP client MAY proceed to
a given MX hostname, no TLSA records are found, or only "insecure" use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
TLSA records are found, DANE TLSA is not applicable with the SMTP obtained via an "insecure" MX RRset. For example, when a hosting
server in question and delivery proceeds to that host as with pre- provider has a signed DNS zone and publishes TLSA records for its
DANE opportunistic TLS. To avoid downgrade attacks, any errors SMTP servers, hosted domains that are not signed may still benefit
during TLSA lookups MUST, as explained in Section 2.1, cause the SMTP from the provider's TLSA records. Deliveries via the provider's SMTP
server in question to be treated as unreachable. servers will not be subject to active attacks when sending SMTP
clients elect to make use of the provider's TLSA records.
When the MX records are not (DNSSEC) signed, an active attacker can
redirect SMTP clients to MX hosts of his choice. Such redirection is
tamper-evident when SMTP servers found via "insecure" MX records are
recorded as the next-hop relay in the MTA delivery logs in their
original (rather than CNAME expanded) form. Sending MTAs SHOULD log
unexpanded MX hostnames when these result from insecure MX lookups.
Any successful authentication via an insecurely determined MX host
MUST NOT be misrepresented in the mail logs as secure delivery to the
intended next-hop domain. When DANE TLS is mandatory (xref
target="madatory"/>) for a given destination, delivery MUST be
delayed when the MX RRset is not "secure".
Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
"secure", and the SMTP client MUST treat each MX hostname as a
separate non-MX destination for opportunistic DANE TLS as described
in Section 2.2.2. When, for a given MX hostname, no TLSA records are
found, or only "insecure" TLSA records are found, DANE TLSA is not
applicable with the SMTP server in question and delivery proceeds to
that host as with pre-DANE opportunistic TLS. To avoid downgrade
attacks, any errors during TLSA lookups MUST, as explained in
Section 2.1.1, cause the SMTP server in question to be treated as
unreachable.
2.2.2. Non-MX destinations 2.2.2. Non-MX destinations
This section describes the algorithm used to locate the TLSA records This section describes the algorithm used to locate the TLSA records
and associated TLSA base domain for an input domain not subject to MX and associated TLSA base domain for an input domain not subject to MX
resolution. Such domains include: resolution. Such domains include:
o Each MX hostname used in a message delivery attempt for an o Each MX hostname used in a message delivery attempt for an
original next-hop destination domain subject to MX resolution. original next-hop destination domain subject to MX resolution.
Note, MTAs are not obligated to support CNAME expansion of MX Note, MTAs are not obligated to support CNAME expansion of MX
skipping to change at page 15, line 7 skipping to change at page 15, line 52
To avoid problems delivering mail to domains whose SMTP servers are To avoid problems delivering mail to domains whose SMTP servers are
served by the problem nameservers the SMTP client MUST perform any A served by the problem nameservers the SMTP client MUST perform any A
and/or AAAA queries for the destination before attempting to locate and/or AAAA queries for the destination before attempting to locate
the associated TLSA records. This lookup is needed in any case to the associated TLSA records. This lookup is needed in any case to
determine whether the destination domain is reachable and the DNSSEC determine whether the destination domain is reachable and the DNSSEC
validation status of the chain of CNAME queries required to reach the validation status of the chain of CNAME queries required to reach the
ultimate address records. ultimate address records.
If no address records are found, the destination is unreachable. If If no address records are found, the destination is unreachable. If
address records are found, but the DNSSEC validation status of the address records are found, but the DNSSEC validation status of the
first query response is "insecure" (there may be additional queries first query response is "insecure" (see Section 2.1.3), the SMTP
if the initial response is a CNAME alias), the SMTP client SHOULD NOT client SHOULD NOT proceed to search for any associated TLSA records.
proceed to search for any associated TLSA records. With the problem With the problem domains, TLSA queries will lead to DNS lookup errors
domains, TLSA queries will lead to DNS lookup errors and cause and cause messages to be consistently delayed and ultimately returned
messages to be consistently delayed and ultimately returned to the to the sender. We don't expect to find any "secure" TLSA records
sender. We don't expect to find any "secure" TLSA records associated associated with a TLSA base domain that lies in an unsigned DNS zone.
with a TLSA base domain that lies in an unsigned DNS zone.
Therefore, skipping TLSA lookups in this case will also reduce Therefore, skipping TLSA lookups in this case will also reduce
latency with no detrimental impact on security. latency with no detrimental impact on security.
If the A and/or AAAA lookup of the "initial name" yields a CNAME, we 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 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 perform a lookup again using the new name. This replacement is
performed recursively. performed recursively.
We consider the following cases for handling a DNS response for an A We consider the following cases for handling a DNS response for an A
or AAAA DNS lookup: or AAAA DNS lookup:
skipping to change at page 15, line 38 skipping to change at page 16, line 33
Non-CNAME: The answer is not a CNAME alias. If the address RRset Non-CNAME: The answer is not a CNAME alias. If the address RRset
is "secure", TLSA lookups are performed as described in is "secure", TLSA lookups are performed as described in
Section 2.2.3 with the initial name as the candidate TLSA base 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 domain. If no "secure" TLSA records are found, DANE TLS is not
applicable and mail delivery proceeds with pre-DANE opportunistic applicable and mail delivery proceeds with pre-DANE opportunistic
TLS (which, being best-effort, degrades to cleartext delivery when TLS (which, being best-effort, degrades to cleartext delivery when
STARTTLS is not available or the TLS handshake fails). STARTTLS is not available or the TLS handshake fails).
Insecure CNAME: The input domain is a CNAME alias, but the ultimate Insecure CNAME: The input domain is a CNAME alias, but the ultimate
network address RRset is "insecure" (see Section 2.1). If the network address RRset is "insecure" (see Section 2.1.1). If the
initial CNAME response is also "insecure", DANE TLS does not initial CNAME response is also "insecure", DANE TLS does not
apply. Otherwise, this case is treated just like the non-CNAME apply. Otherwise, this case is treated just like the non-CNAME
case above, where a search is performed for a TLSA record with the case above, where a search is performed for a TLSA record with the
original input domain as the candidate TLSA base domain. original input domain as the candidate TLSA base domain.
Secure CNAME: The input domain is a CNAME alias, and the ultimate Secure CNAME: The input domain is a CNAME alias, and the ultimate
network address RRset is "secure" (see Section 2.1). Two network address RRset is "secure" (see Section 2.1.1). Two
candidate TLSA base domains are tried: the fully CNAME-expanded candidate TLSA base domains are tried: the fully CNAME-expanded
initial name and, failing that, then the initial name itself. initial name and, failing that, then the initial name itself.
In summary, if it is possible to securely obtain the full, CNAME- In summary, if it is possible to securely obtain the full, CNAME-
expanded, DNSSEC-validated address records for the input domain, then expanded, DNSSEC-validated address records for the input domain, then
that name is the preferred TLSA base domain. Otherwise, the that name is the preferred TLSA base domain. Otherwise, the
unexpanded input-MX domain is the candidate TLSA base domain. When unexpanded input-MX domain is the candidate TLSA base domain. When
no "secure" TLSA records are found at either the CNAME-expanded or no "secure" TLSA records are found at either the CNAME-expanded or
unexpanded domain, then DANE TLS does not apply for mail delivery via unexpanded domain, then DANE TLS does not apply for mail delivery via
the input domain in question. And, as always, errors, bogus or the input domain in question. And, as always, errors, bogus or
skipping to change at page 16, line 39 skipping to change at page 17, line 44
security-aware stub resolver) restarts the TLSA query at the target security-aware stub resolver) restarts the TLSA query at the target
domain, following CNAMEs as appropriate and keeping track of whether domain, following CNAMEs as appropriate and keeping track of whether
the entire chain is "secure". If any "insecure" records are the entire chain is "secure". If any "insecure" records are
encountered, or the TLSA records don't exist, the next candidate TLSA encountered, or the TLSA records don't exist, the next candidate TLSA
base is tried instead. base is tried instead.
If the ultimate response is a "secure" TLSA RRset, then the candidate If the ultimate response is a "secure" TLSA RRset, then the candidate
TLSA base domain will be the actual TLSA base domain and the TLSA TLSA base domain will be the actual TLSA base domain and the TLSA
RRset will constitute the TLSA records for the destination. If none RRset will constitute the TLSA records for the destination. If none
of the candidate TLSA base domains yield "secure" TLSA records then of the candidate TLSA base domains yield "secure" TLSA records then
delivery should proceed via pre-DANE opportunistic TLS. delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
or even to skip SMTP servers that fail authentication, but MUST NOT
misrepresent authentication success as either a secure connection to
the SMTP server or as a secure delivery to the intended next-hop
domain.
TLSA record publishers may leverage CNAMEs to reference a single TLSA record publishers may leverage CNAMEs to reference a single
authoritative TLSA RRset specifying a common Certification Authority authoritative TLSA RRset specifying a common Certification Authority
or a common end entity certificate to be used with multiple TLS or a common end entity certificate to be used with multiple TLS
services. Such CNAME expansion does not change the SMTP client's services. Such CNAME expansion does not change the SMTP client's
notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
a CNAME, the base domain remains mx.example.com and this is still the a CNAME, the base domain remains mx.example.com and this is still the
reference identifier used together with the next-hop domain in peer reference identifier used together with the next-hop domain in peer
certificate name checks. certificate name checks.
skipping to change at page 17, line 29 skipping to change at page 18, line 38
to have certificates issued under a common trust anchor, but each MX to have certificates issued under a common trust anchor, but each MX
hostname's TLSA base domain remains unchanged despite the above CNAME hostname's TLSA base domain remains unchanged despite the above CNAME
records. Correspondingly, each SMTP server will be associated with a records. Correspondingly, each SMTP server will be associated with a
pair of reference identifiers consisting of its hostname plus the pair of reference identifiers consisting of its hostname plus the
next-hop domain "example.com". next-hop domain "example.com".
If, during TLSA resolution (including possible CNAME indirection), at If, during TLSA resolution (including possible CNAME indirection), at
least one "secure" TLSA record is found (even if not usable because least one "secure" TLSA record is found (even if not usable because
it is unsupported by the implementation or support is it is unsupported by the implementation or support is
administratively disabled), then the corresponding host has signaled administratively disabled), then the corresponding host has signaled
its commitment to implement TLS. The SMTP client SHOULD NOT deliver its commitment to implement TLS. The SMTP client MUST NOT deliver
mail via the corresponding host unless a TLS session is negotiated mail via the corresponding host unless a TLS session is negotiated
via STARTTLS. This is required to avoid MITM STARTTLS downgrade via STARTTLS. This is required to avoid MITM STARTTLS downgrade
attacks. attacks.
As noted previously (in Section Section 2.2.2), when no "secure" TLSA As noted previously (in Section Section 2.2.2), when no "secure" TLSA
records are found at the fully CNAME-expanded name, the original records are found at the fully CNAME-expanded name, the original
unexpanded name MUST be tried instead. This supports customers of unexpanded name MUST be tried instead. This supports customers of
hosting providers where the provider's zone cannot be validated with hosting providers where the provider's zone cannot be validated with
DNSSEC, but the customer has shared appropriate key material with the DNSSEC, but the customer has shared appropriate key material with the
hosting provider to enable TLS via SNI. Intermediate names that hosting provider to enable TLS via SNI. Intermediate names that
arise during CNAME expansion that are neither the original, nor the arise during CNAME expansion that are neither the original, nor the
final name, are never candidate TLSA base domains, even if "secure". final name, are never candidate TLSA base domains, even if "secure".
2.3. DANE authentication 3. DANE authentication
This section describes which TLSA records are applicable to SMTP This section describes which TLSA records are applicable to SMTP
opportunistic DANE TLS and how to apply such records to authenticate opportunistic DANE TLS and how to apply such records to authenticate
the SMTP server. With opportunistic DANE TLS, both the TLS support the SMTP server. With opportunistic DANE TLS, both the TLS support
implied by the presence of DANE TLSA records and the verification implied by the presence of DANE TLSA records and the verification
parameters necessary to authenticate the TLS peer are obtained parameters necessary to authenticate the TLS peer are obtained
together. In contrast to protocols where channel security policy is together. In contrast to protocols where channel security policy is
set exclusively by the client, authentication via this protocol is set exclusively by the client, authentication via this protocol is
expected to be less prone to connection failure caused by expected to be less prone to connection failure caused by
incompatible configuration of the client and server. incompatible configuration of the client and server.
2.3.1. TLSA certificate usages 3.1. TLSA certificate usages
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
via combinations of 3 numeric parameters. The numeric values of via combinations of 3 numeric parameters. The numeric values of
these parameters were later given symbolic names in these parameters were later given symbolic names in
[I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is [I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is
the "certificate association data field", which specifies the full or the "certificate association data field", which specifies the full or
digest value of a certificate or public key. The parameters are: digest value of a certificate or public key. The parameters are:
The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] 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- specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-
skipping to change at page 19, line 34 skipping to change at page 20, line 43
SHA2-256(1). When the server's TLSA RRset includes records with a SHA2-256(1). When the server's TLSA RRset includes records with a
matching type indicating a digest record (i.e., a value other than matching type indicating a digest record (i.e., a value other than
Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
provided along with any other digest published, since some SMTP provided along with any other digest published, since some SMTP
clients may support only SHA2-256(1). If at some point the SHA2-256 clients may support only SHA2-256(1). If at some point the SHA2-256
digest algorithm is tarnished by new cryptanalytic attacks, digest algorithm is tarnished by new cryptanalytic attacks,
publishers will need to include an appropriate stronger digest in publishers will need to include an appropriate stronger digest in
their TLSA records, initially along with, and ultimately in place of, their TLSA records, initially along with, and ultimately in place of,
SHA2-256. SHA2-256.
2.3.1.1. Certificate usage DANE-EE(3) 3.1.1. Certificate usage DANE-EE(3)
Authentication via certificate usage DANE-EE(3) TLSA records involves Authentication via certificate usage DANE-EE(3) TLSA records involves
simply checking that the server's leaf certificate matches the TLSA simply checking that the server's leaf certificate matches the TLSA
record. In particular the binding of the server public key to its record. In particular the binding of the server public key to its
name is based entirely on the TLSA record association The server MUST name is based entirely on the TLSA record association. The server
be considered authenticated even if none of the names in the MUST be considered authenticated even if none of the names in the
certificate match the client's reference identity for the server. certificate match the client's reference identity for the server.
Similarly, the expiration date of the server certificate MUST be Similarly, the expiration date of the server certificate MUST be
ignored, the validity period of the TLSA record key binding is ignored, the validity period of the TLSA record key binding is
determined by the validity interval of the TLSA record DNSSEC determined by the validity interval of the TLSA record DNSSEC
signature. signature.
With DANE-EE(3) servers need not employ SNI (may ignore the client's With DANE-EE(3) servers need not employ SNI (may ignore the client's
SNI message) even when the server is known under independent names SNI message) even when the server is known under independent names
that would otherwise require separate certificates. It is instead that would otherwise require separate certificates. It is instead
skipping to change at page 20, line 22 skipping to change at page 21, line 32
certificates expire, and don't fail when the server operator neglects certificates expire, and don't fail when the server operator neglects
to configure all the required issuer certificates in the server to configure all the required issuer certificates in the server
certificate chain. certificate chain.
TLSA records published for SMTP servers SHOULD, in most cases, be TLSA records published for SMTP servers SHOULD, in most cases, be
"DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
implementations are required to support SHA2-256, this record type implementations are required to support SHA2-256, this record type
works for all clients and need not change across certificate renewals works for all clients and need not change across certificate renewals
with the same key. with the same key.
2.3.1.2. Certificate usage DANE-TA(2) 3.1.2. Certificate usage DANE-TA(2)
Some domains may prefer to avoid the operational complexity of 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 Certification Authority to create employs a common issuing Certification Authority to create
certificates for multiple TLS services, it may be simpler to publish certificates for multiple TLS services, it may be simpler to publish
the issuing authority as a trust anchor (TA) for the certificate the issuing authority as a trust anchor (TA) for the certificate
chains of all relevant services. The TLSA query domain (TLSA base chains of all relevant services. The TLSA query domain (TLSA base
domain with port and protocol prefix labels) for each service issued domain with port and protocol prefix labels) for each service issued
by the same TA may then be set to a CNAME alias that points to a by the same TA may then be set to a CNAME alias that points to a
common TLSA RRset that matches the TA. For example: common TLSA RRset that matches the TA. For example:
skipping to change at page 21, line 34 skipping to change at page 22, line 47
relevant constraints from the trust anchor certificate, such as, for relevant constraints from the trust anchor certificate, such as, for
example, path length constraints. example, path length constraints.
While a selector of SPKI(1) may also be employed, the resulting TLSA While a selector of SPKI(1) may also be employed, the resulting TLSA
record will not specify the full trust anchor certificate content, record will not specify the full trust anchor certificate content,
and elements of the trust anchor certificate other than the public and elements of the trust anchor certificate other than the public
key become mutable. This may, for example, allow a subsidiary CA to key become mutable. This may, for example, allow a subsidiary CA to
issue a chain that violates the trust anchor's path length or name issue a chain that violates the trust anchor's path length or name
constraints. constraints.
2.3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
SMTP servers SHOULD NOT publish TLSA RRs with certificate usage As noted in the introduction, SMTP clients cannot, without relying on
"PKIX-TA(0)" or "PKIX-EE(1)". SMTP clients cannot be expected to be DNSSEC for secure MX records and DANE for STARTTLS support signaling,
configured with a suitably complete set of trusted public CAs. Even perform server identity verification or prevent STARTTLS downgrade
with a full set of public CAs, SMTP clients cannot (without relying attacks. The use of PKIX CAs offers no added security since an
on DNSSEC for secure MX records and DANE for STARTTLS support attacker capable of compromising DNSSEC is free to replace any PKIX-
signaling) perform [RFC6125] server identity verification or prevent TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
STARTTLS downgrade attacks. The use of trusted public CAs offers no non-PKIX certificate usage.
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- SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
likely) treat such TLSA records as unusable. configured with a suitably complete set of trusted public CAs.
Lacking a complete set of public CAs, clients would not be able to
verify the certificates of SMTP servers whose issuing root CAs are
not trusted by the client.
2.3.2. Certificate matching Opportunistic DANE TLS needs to interoperate without bilateral
coordination of security settings between client and server systems.
Therefore, parameter choices that are fragile in the absence of
bilateral coordination are unsupported. Nothing is lost since the
PKIX certificate usages cannot aid SMTP TLS security, they can only
impede SMTP TLS interoperability.
SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
or PKIX-EE(1) is undefined. SMTP clients should generally treat such
TLSA records as unusable.
3.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 SMTP server. client MUST use TLSA records to authenticate the SMTP server.
Messages SHOULD NOT be delivered via the SMTP server if Messages MUST NOT be delivered via the SMTP server if authentication
authentication fails, otherwise the SMTP client is vulnerable to MITM fails, otherwise the SMTP client is vulnerable to MITM attacks.
attacks.
2.3.2.1. DANE-EE(3) name checks 3.2.1. DANE-EE(3) name checks
The SMTP client MUST NOT perform certificate name checks with The SMTP client MUST NOT perform certificate name checks with
certificate usage DANE-EE(3), see Section 2.3.1.1 above. certificate usage DANE-EE(3), see Section 3.1.1 above.
2.3.2.2. DANE-TA(2) name checks 3.2.2. DANE-TA(2) name checks
To match a server via a TLSA record with certificate usage DANE- To match a server via a TLSA record with certificate usage DANE-
TA(2), the client MUST perform name checks to ensure that it has TA(2), the client MUST perform name checks to ensure that it has
reached the correct server. In all DANE-TA(2) cases the SMTP client reached the correct server. In all DANE-TA(2) cases the SMTP client
MUST include the TLSA base domain as one of the valid reference MUST include the TLSA base domain as one of the valid reference
identifiers for matching the server certificate. identifiers for matching the server certificate.
TLSA records for MX hostnames: If the TLSA base domain was obtained TLSA records for MX hostnames: If the TLSA base domain was obtained
indirectly via an MX lookup (including any CNAME-expanded name of indirectly via a "secure" MX lookup (including any CNAME-expanded
an MX hostname), then the original next-hop domain used in the MX name of an MX hostname), then the original next-hop domain used in
lookup MUST be included as as a second reference identifier. The the MX lookup MUST be included as as a second reference
CNAME-expanded original next-hop domain MUST be included as a identifier. The CNAME-expanded original next-hop domain MUST be
third reference identifier if different from the original next-hop included as a third reference identifier if different from the
domain. original next-hop domain. When the client MTA is employing DANE
TLS security despite "insecure" MX redirection the MX hostname is
the only reference identifier.
TLSA records for Non-MX hostnames: If MX records were not used TLSA records for Non-MX hostnames: If MX records were not used
(e.g., if none exist) and the TLSA base domain is the CNAME- (e.g., if none exist) and the TLSA base domain is the CNAME-
expanded original next-hop domain, then the original next-hop expanded original next-hop domain, then the original next-hop
domain MUST be included as a second reference identifier. domain MUST be included as a second reference identifier.
Accepting certificates with the original next-hop domain in addition Accepting certificates with the original next-hop domain in addition
to the MX hostname allows a domain with multiple MX hostnames to to the MX hostname allows a domain with multiple MX hostnames to
field a single certificate bearing a single domain name (i.e., the field a single certificate bearing a single domain name (i.e., the
email domain) across all the SMTP servers. This also aids email domain) across all the SMTP servers. This also aids
skipping to change at page 23, line 34 skipping to change at page 24, line 50
via any of the associated SMTP servers MUST accept at least the names via any of the associated SMTP servers MUST accept at least the names
"exchange.example.org" and "example.com", which are respectively the "exchange.example.org" and "example.com", which are respectively the
original and fully expanded next-hop domain. When the SMTP server is 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, name checks MUST accept the TLSA base domain
"mx10.example.com". If, despite the fact that MX hostnames are "mx10.example.com". If, despite the fact that MX hostnames are
required to not be aliases, the MTA supports delivery via required to not be aliases, the MTA supports delivery via
"mx15.example.com" or "mx20.example.com" then name checks MUST accept "mx15.example.com" or "mx20.example.com" then name checks MUST accept
the respective TLSA base domains "mx15.example.com" and the respective TLSA base domains "mx15.example.com" and
"mxbackup.example.net". "mxbackup.example.net".
2.3.2.3. Reference identifier matching 3.2.3. Reference identifier matching
When name checks are applicable (certificate usage DANE-TA(2)), if When name checks are applicable (certificate usage DANE-TA(2)), if
the server certificate contains a Subject Alternative Name extension the server certificate contains a Subject Alternative Name extension
([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS- ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
IDs are matched against the client's reference identifiers. The CN- IDs are matched against the client's reference identifiers. The CN-
ID ([RFC6125]) is only considered when no DNS-IDs are present. The ID ([RFC6125]) is only considered when no DNS-IDs are present. The
server certificate is considered matched when one of its presented server certificate is considered matched when one of its presented
identifiers ([RFC5280]) matches any of the client's reference identifiers ([RFC5280]) matches any of the client's reference
identifiers. identifiers.
Wildcards are valid in either DNS-IDs or the CN-ID when applicable. Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
skipping to change at page 24, line 9 skipping to change at page 25, line 26
"*smtp.example.com" are not. SMTP clients MUST support wildcards "*smtp.example.com" are not. SMTP clients MUST support wildcards
that match the first label of the reference identifier, with the that match the first label of the reference identifier, with the
remaining labels matching verbatim. For example, the DNS-ID remaining labels matching verbatim. For example, the DNS-ID
"*.example.com" matches the reference identifier "mx1.example.com". "*.example.com" matches the reference identifier "mx1.example.com".
SMTP clients MAY, subject to local policy allow wildcards to match SMTP clients MAY, subject to local policy allow wildcards to match
multiple reference identifier labels, but servers cannot expect broad multiple reference identifier labels, but servers cannot expect broad
support for such a policy. Therefore any wildcards in server support for such a policy. Therefore any wildcards in server
certificates SHOULD match exactly one label in either the TLSA base certificates SHOULD match exactly one label in either the TLSA base
domain or the next-hop domain. domain or the next-hop domain.
2.3.3. Key rotation 4. Server key management
Two TLSA records MUST be published before employing a new EE or TA Two TLSA records MUST be published before employing a new EE or TA
public key or certificate, one matching the currently deployed key public key or certificate, one matching the currently deployed key
and the other matching the new key scheduled to replace it. Once and the other matching the new key scheduled to replace it. Once
sufficient time has elapsed for all DNS caches to expire the previous sufficient time has elapsed for all DNS caches to expire the previous
TLSA RRset and related signature RRsets, servers may be configured to TLSA RRset and related signature RRsets, servers may be configured to
use the new EE private key and associated public key certificate or use the new EE private key and associated public key certificate or
may employ certificates signed by the new trust anchor. may employ certificates signed by the new trust anchor.
Once the new public key or certificate is in use, the TLSA RR that Once the new public key or certificate is in use, the TLSA RR that
matches the retired key can be removed from DNS, leaving only RRs matches the retired key can be removed from DNS, leaving only RRs
that match keys or certificates in active use. that match keys or certificates in active use.
2.3.4. Digest algorithm agility As described in Section 3.1.2, when server certificates are validated
via a DANE-TA(2) trust anchor, and CNAME records are employed to
store the TA association data at a single location, the
responsibility of updating the TLSA RRset shifts to the operator of
the trust anchor. Before a new trust anchor is used to sign any new
server certificates, its certificate (digest) is added to the
relevant TLSA RRset. After enough time elapses for the original TLSA
RRset to age out of DNS caches, the new trust anchor can start
issuing new server certificates. Once all certificates issued under
the previous trust anchor have expired, its associated RRs can be
removed from the TLSA RRset.
In the DANE-TA(2) key management model server operators do not
generally need to update DNS TLSA records after initially creating a
CNAME record that references the centrally operated DANE-TA(2) RRset.
If a particular server's key is compromised, its TLSA CNAME SHOULD be
replaced with a DANE-EE(3) association until the certificate for the
compromised key expires, at which point it can return to using CNAME
record. If the central trust anchor is compromised, all servers need
to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
needs to be published containing just the new TA. SMTP servers
cannot expect broad SMTP client CRL or OCSP support.
5. Digest algorithm agility
While [RFC6698] specifies multiple digest algorithms, it does not While [RFC6698] specifies multiple digest algorithms, it does not
specify a protocol by which the SMTP client and TLSA record publisher specify a protocol by which the SMTP client and TLSA record publisher
can agree on the strongest shared algorithm. Such a protocol would can agree on the strongest shared algorithm. Such a protocol would
allow the client and server to avoid exposure to any deprecated allow the client and server to avoid exposure to any deprecated
weaker algorithms that are published for compatibility with less weaker algorithms that are published for compatibility with less
capable clients, but should be ignored when possible. 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 a TLS server considers Suppose that a DANE TLS client authenticating a TLS server considers
digest algorithm BETTER stronger than digest algorithm WORSE. digest algorithm "BetterAlg" stronger than digest algorithm
Suppose further that a server's TLSA RRset contains some records with "WorseAlg". Suppose further that a server's TLSA RRset contains some
BETTER as the digest algorithm. Finally, suppose that for every raw records with "BetterAlg" as the digest algorithm. Finally, suppose
public key or certificate object that is included in the server's that for every raw public key or certificate object that is included
TLSA RRset in digest form, whenever that object appears with in the server's TLSA RRset in digest form, whenever that object
algorithm WORSE with some usage and selector it also appears with appears with algorithm "WorseAlg" with some usage and selector it
algorithm BETTER with the same usage and selector. In that case our also appears with algorithm "BetterAlg" with the same usage and
client can safely ignore TLSA records with the weaker algorithm selector. In that case our client can safely ignore TLSA records
WORSE, because it suffices to check the records with the stronger with the weaker algorithm "WorseAlg", because it suffices to check
algorithm BETTER. the records with the stronger algorithm "BetterAlg".
Server operators MUST ensure that for any given usage and selector, Server operators MUST ensure that for any given usage and selector,
each object (certificate or public key), for which a digest each object (certificate or public key), for which a digest
association exists in the TLSA RRset, is published with the SAME SET association exists in the TLSA RRset, is published with the SAME SET
of digest algorithms as all other objects that published with that of digest algorithms as all other objects that published with that
usage and selector. In other words, for each usage and selector, the usage and selector. In other words, for each usage and selector, the
records with non-zero matching types will correspond to on a cross- 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 product of a set of underlying objects and a fixed set of digest
algorithms that apply uniformly to all the objects. algorithms that apply uniformly to all the objects.
skipping to change at page 26, line 17 skipping to change at page 27, line 49
algorithms used; change just the list of objects. algorithms used; change just the list of objects.
o When changing the set of digest algorithms, change only the set of o When changing the set of digest algorithms, change only the set of
algorithms, and generate a new RRset in which all the current algorithms, and generate a new RRset in which all the current
objects are re-published with the new set of digest algorithms. objects are re-published with the new set of digest algorithms.
After either of these two changes are made, the new TLSA RRset should After either of these two changes are made, the new TLSA RRset should
be left in place long enough that the older TLSA RRset can be flushed be left in place long enough that the older TLSA RRset can be flushed
from caches before making another change. from caches before making another change.
3. Mandatory TLS Security 6. 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. The sending assurance when sending email to selected destinations. The sending
organization may need to send sensitive email and/or may have organization may need to send sensitive email and/or may have
regulatory obligations to protect its content. This protocol is not regulatory obligations to protect its content. This protocol is not
in conflict with such a requirement, and in fact 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 hostnames, 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 SMTP domains's DANE TLSA records to authenticate the corresponding SMTP
skipping to change at page 26, line 43 skipping to change at page 28, line 28
records are found, message delivery is delayed. Thus, mail is only records are found, message delivery is delayed. Thus, mail is only
sent when an authenticated TLS channel is established to the remote sent when an authenticated TLS channel is established to the remote
SMTP server. SMTP server.
Administrators of mail servers that employ mandatory DANE TLS, need Administrators of mail servers that employ mandatory DANE TLS, need
to carefully monitor their mail logs and queues. If a partner domain to carefully monitor their mail logs and queues. If a partner domain
unwittingly misconfigures their TLSA records, disables DNSSEC, or unwittingly misconfigures their TLSA records, disables DNSSEC, or
misconfigures SMTP server certificate chains, mail will be delayed misconfigures SMTP server certificate chains, mail will be delayed
and may bounce if the issue is not resolved in a timely manner. and may bounce if the issue is not resolved in a timely manner.
4. Note on DANE for Message User Agents 7. Note on DANE for Message User Agents
We note that the SMTP protocol is also used between Message User We note that the SMTP protocol is also used between Message User
Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
[RFC6186] a protocol is specified that enables an MUA to dynamically [RFC6186] a protocol is specified that enables an MUA to dynamically
locate the MSA based on the user's email address. SMTP connection locate the MSA based on the user's email address. SMTP connection
security considerations for MUAs implementing [RFC6186] are largely security considerations for MUAs implementing [RFC6186] are largely
analogous to connection security requirements for MTAs, and this analogous to connection security requirements for MTAs, and this
specification could be applied largely verbatim with DNS MX records specification could be applied largely verbatim with DNS MX records
replaced by corresponding DNS Service (SRV) records replaced by corresponding DNS Service (SRV) records
[I-D.ietf-dane-srv]. [I-D.ietf-dane-srv].
However, until MUAs begin to adopt the dynamic configuration However, until MUAs begin to adopt the dynamic configuration
mechanisms of [RFC6186] they are adequately served by more mechanisms of [RFC6186] they are adequately served by more
traditional static TLS security policies. Specification of DANE TLS traditional static TLS security policies. Specification of DANE TLS
for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
is left to future documents that focus specifically on SMTP security is left to future documents that focus specifically on SMTP security
between MUAs and MSAs. between MUAs and MSAs.
5. Interoperability considerations 8. Interoperability considerations
5.1. SNI support 8.1. SNI support
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 the backward compatible SSL 2.0 domain. This precludes the use of the backward compatible SSL 2.0
compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
HELLO version for SMTP clients performing DANE authentication is SSL 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 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 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. of SNI MAY negotiate SSL 3.0 if offered by the client.
skipping to change at page 27, line 48 skipping to change at page 29, line 32
not see the expected certificate chain. not see the expected certificate chain.
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. In either case, the server chain, the server need not support SNI. In either case, the server
need not include the SNI extension in its TLS HELLO as simply need not include the SNI extension in its TLS HELLO as simply
returning a matching certificate chain is sufficient. Servers MUST returning a matching certificate chain is sufficient. Servers MUST
NOT enforce the use of SNI by clients, as the client may be using NOT enforce the use of SNI by clients, as the client may be using
unauthenticated opportunistic TLS and may not expect any particular unauthenticated opportunistic TLS and may not expect any particular
certificate from the server. If the client sends no SNI extension, certificate from the server. If the client sends no SNI extension,
or sends an SNI extension for an unsupported domain, the server MUST or sends an SNI extension for an unsupported domain, the server MUST
simply send its default certificate chain. The reason for not simply send some fallback certificate chain of its choice. The
enforcing strict matching of the requested SNI hostname is that DANE reason for not enforcing strict matching of the requested SNI
TLS clients are typically willing to accept multiple server names, hostname is that DANE TLS clients are typically willing to accept
but can only send one name in the SNI extension. The server's multiple server names, but can only send one name in the SNI
default certificate may match a different name acceptable to the extension. The server's fallback certificate may match a different
client, e.g., the original next-hop domain. name acceptable to the client, e.g., the original next-hop domain.
5.2. Anonymous TLS cipher suites 8.2. Anonymous TLS cipher suites
Since many SMTP servers either do not support or do not enable any Since many SMTP servers either do not support or do not enable any
anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
offer to negotiate a typical set of non-anonymous cipher suites offer to negotiate a typical set of non-anonymous cipher suites
required for interoperability with such servers. An SMTP client required for interoperability with such servers. An SMTP client
employing pre-DANE opportunistic TLS MAY in addition include one or employing pre-DANE opportunistic TLS MAY in addition include one or
more anonymous TLS cipher suites in its TLS HELLO. SMTP servers, more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
that need to interoperate with opportunistic TLS clients SHOULD be that need to interoperate with opportunistic TLS clients SHOULD be
prepared to interoperate with such clients by either always selecting prepared to interoperate with such clients by either always selecting
a mutually supported non-anonymous cipher suite or by correctly a mutually supported non-anonymous cipher suite or by correctly
handling client connections that negotiate anonymous cipher suites. handling client connections that negotiate anonymous cipher suites.
Note that while SMTP server operators are under no obligation to Note that while SMTP server operators are under no obligation to
enable anonymous cipher suites, no security is gained by sending enable anonymous cipher suites, no security is gained by sending
certificates to clients that will ignore them. Indeed support for certificates to clients that will ignore them. Indeed support for
anonymous cipher suites in the server makes audit trails more anonymous cipher suites in the server makes audit trails more
informative. Log entries that record connections that employed an informative. Log entries that record connections that employed an
anonymous cipher suite record the fact that the clients did not care anonymous cipher suite record the fact that the clients did not care
to authenticate the server. to authenticate the server.
6. Operational Considerations 9. Operational Considerations
6.1. Client Operational Considerations 9.1. Client Operational Considerations
An operational error on the sending or receiving side that cannot be An operational error on the sending or receiving side that cannot be
corrected in a timely manner may, at times, lead to consistent corrected in a timely manner may, at times, lead to consistent
failure to deliver time-sensitive email. The sending MTA failure to deliver time-sensitive email. The sending MTA
administrator may have to choose between letting email queue until administrator may have to choose between letting email queue until
the error is resolved and disabling opportunistic or mandatory DANE the error is resolved and disabling opportunistic or mandatory DANE
TLS for one or more destinations. The choice to disable DANE TLS TLS for one or more destinations. The choice to disable DANE TLS
security should not be made lightly. Every reasonable effort should security should not be made lightly. Every reasonable effort should
be made to determine that problems with mail delivery are the result be made to determine that problems with mail delivery are the result
of an operational error, and not an attack. A fallback strategy may of an operational error, and not an attack. A fallback strategy may
skipping to change at page 29, line 9 skipping to change at page 30, line 42
due to misconfiguration or software defects on either end. Some due to misconfiguration or software defects on either end. Some
implementations MAY support DANE TLS in an "audit only" mode in which implementations MAY support DANE TLS in an "audit only" mode in which
failure to achieve the requisite security level is logged as a failure to achieve the requisite security level is logged as a
warning and delivery proceeds at a reduced security level. Unless warning and delivery proceeds at a reduced security level. Unless
local policy specifies "audit only" or that opportunistic DANE TLS is local policy specifies "audit only" or that opportunistic DANE TLS is
not to be used for a particular destination, an SMTP client MUST NOT not to be used for a particular destination, an SMTP client MUST NOT
deliver mail via a server whose certificate chain fails to match at deliver mail via a server whose certificate chain fails to match at
least one TLSA record when usable TLSA records are found for that least one TLSA record when usable TLSA records are found for that
server. server.
6.2. Publisher Operational Considerations 9.2. Publisher Operational Considerations
SMTP servers that publish certificate usage DANE-TA(2) associations SMTP servers that publish certificate usage DANE-TA(2) associations
MUST include the TA certificate in their TLS server certificate MUST include the TA certificate in their TLS server certificate
chain, even when that TA certificate is a self-signed root chain, even when that TA certificate is a self-signed root
certificate. certificate.
TLSA Publishers must follow the digest agility guidelines in TLSA Publishers must follow the digest agility guidelines in
Section 2.3.4 and must make sure that all objects published in digest Section 5 and must make sure that all objects published in digest
form for a particular usage and selector are published with the same form for a particular usage and selector are published with the same
set of digest algorithms. set of digest algorithms.
TLSA Publishers should follow the TLSA publication size guidance TLSA Publishers should follow the TLSA publication size guidance
found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
7. Security Considerations 10. 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 hostnames, this protocol allows sending MTAs to securely discover MX hostnames, this protocol allows sending MTAs to securely discover
both the availability of TLS and how to authenticate the destination. both the availability of TLS 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
skipping to change at page 30, line 23 skipping to change at page 31, line 45
certificate usages 0 and 1 simplifies implementation and deployment certificate usages 0 and 1 simplifies implementation and deployment
with no adverse security consequences. with no adverse security consequences.
Implementations must strictly follow the portions of this Implementations must strictly follow the portions of this
specification that indicate when it is appropriate to initiate a non- specification that indicate when it is appropriate to initiate a non-
authenticated connection or cleartext connection to a SMTP server. authenticated connection or cleartext connection to a SMTP server.
Specifically, in order to prevent downgrade attacks on this protocol, Specifically, in order to prevent downgrade attacks on this protocol,
implementation must not initiate a connection when this specification implementation must not initiate a connection when this specification
indicates a particular SMTP server must be considered unreachable. indicates a particular SMTP server must be considered unreachable.
8. IANA considerations 11. IANA considerations
This specification requires no support from IANA. This specification requires no support from IANA.
9. Acknowledgements 12. Acknowledgements
The authors would like to extend great thanks to Tony Finch, who The authors would like to extend great thanks to Tony Finch, who
started the original version of a DANE SMTP document. His work is started the original version of a DANE SMTP document. His work is
greatly appreciated and has been incorporated into this document. greatly appreciated and has been incorporated into this document.
The authors would like to additionally thank Phil Pennock for his The authors would like to additionally thank Phil Pennock for his
comments and advice on this document. comments and advice on this document.
Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
to begin work on this memo and provided feedback on early drafts. to begin work on this memo and provided feedback on early drafts.
Thanks to Patrick Koetter, Perry Metzger and Nico Williams for Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
valuable review comments. Thanks also to Wietse Venema who created valuable review comments. Thanks also to Wietse Venema who created
Postfix, and whose advice and feedback were essential to the Postfix, and whose advice and feedback were essential to the
development of the Postfix DANE implementation. development of the Postfix DANE implementation.
10. References 13. References
10.1. Normative References 13.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 [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. 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
skipping to change at page 32, line 5 skipping to change at page 33, line 27
[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.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012. 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.
10.2. Informative References 13.2. Informative References
[I-D.ietf-dane-registry-acronyms] [I-D.ietf-dane-registry-acronyms]
Gudmundsson, O., "Adding acronyms to simplify DANE Gudmundsson, O., "Adding acronyms to simplify DANE
conversations", draft-ietf-dane-registry-acronyms-01 (work conversations", draft-ietf-dane-registry-acronyms-01 (work
in progress), October 2013. in progress), October 2013.
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., "Using DNS-Based Authentication of Named Finch, T., "Using DNS-Based Authentication of Named
Entities (DANE) TLSA records with SRV and MX records.", Entities (DANE) TLSA records with SRV and MX records.",
draft-ietf-dane-srv-02 (work in progress), February 2013. draft-ietf-dane-srv-02 (work in progress), February 2013.
 End of changes. 62 change blocks. 
199 lines changed or deleted 292 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/