< draft-ietf-dane-smtp-with-dane-00.txt   draft-ietf-dane-smtp-with-dane-01.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Experimental W. Hardaker Intended status: Experimental W.H. Hardaker
Expires: April 11, 2014 Parsons Expires: April 24, 2014 Parsons
October 08, 2013 October 21, 2013
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-00 draft-ietf-dane-smtp-with-dane-01
Abstract Abstract
This memo describes a protocol for opportunistic TLS security based This memo describes a protocol for opportunistic TLS security based
on the DANE TLSA DNS record. The protocol is downgrade resistant on the DANE TLSA DNS record. The protocol is downgrade resistant
when the SMTP client supports DANE TLSA and the server domain when the SMTP client supports DANE TLSA and the server domain
publishes TLSA records for its MX hosts. This enables an incremental publishes TLSA records for its MX hosts. This enables an incremental
transition of the Internet email backbone (MTA to MTA SMTP traffic) transition of the Internet email backbone (MTA to MTA SMTP traffic)
to TLS encrypted and authenticated delivery. to TLS encrypted and authenticated delivery.
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 April 11, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3 1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5 2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5
2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5 2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. MX resolution . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Non-MX destinations . . . . . . . . . . . . . . . . . 6
2.1.2. TLSA record lookup . . . . . . . . . . . . . . . . . 7 2.1.2. MX resolution . . . . . . . . . . . . . . . . . . . . 7
2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 8 2.1.3. TLSA record lookup . . . . . . . . . . . . . . . . . 9
2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 8 2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 10
2.2.2. Certificate matching . . . . . . . . . . . . . . . . 11 2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 11
3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 13 2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12
4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 14 3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Lacking verified DNS and "Server Name Indication" (SNI), there has Lacking verified DNS and "Server Name Indication" (SNI), there has
historically been no scalable way for SMTP server operators to historically been no scalable way for SMTP server operators to deploy
provide certificates which match a trustable identifier. It's only certificates with a client-trusted subject name. It's only with the
with the deployment of DNSSEC and DANE that authenticated TLS for deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX
SMTP to MX becomes possible between parties that have not already becomes possible between parties that have not already established an
established an identity convention out-of-band. identity convention out-of-band.
1.1. Background 1.1. Background
The Domain Name System Security Extensions (DNSSEC) add data origin The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. DNSSEC authentication and data integrity to the Domain Name System. DNSSEC
is defined in [RFC4033], [RFC4034] and [RFC4035]. is defined in [RFC4033], [RFC4034] and [RFC4035].
As described in the introduction of [RFC6698], TLS authentication via As described in the introduction of [RFC6698], TLS authentication via
the existing public Certificate Authority (CA) Public Key the existing public Certificate Authority (CA) Public Key
Infrastructure (PKI) suffers from an over-abundance of trusted Infrastructure (PKI) suffers from an over-abundance of trusted
skipping to change at page 3, line 19 skipping to change at page 3, line 19
protects against man-in-the-middle (MITM) attacks. protects against man-in-the-middle (MITM) attacks.
1.2. SMTP Channel Security 1.2. SMTP Channel Security
The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop
store & forward, while TLS security is hop-by-hop. The number of store & forward, while TLS security is hop-by-hop. The number of
hops from the sender's Mail User Agent to the recipient mailbox is hops from the sender's Mail User Agent to the recipient mailbox is
rarely less than 2 and is often higher. Some hops may be TLS rarely less than 2 and is often higher. Some hops may be TLS
protected, some may not. The same SMTP TCP endpoint can serve both protected, some may not. The same SMTP TCP endpoint can serve both
TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS
command ([RFC3207]). DNS MX records abstract the next hop transport command ([RFC3207]). DNS MX records abstract the next-hop transport
end-point. SMTP addresses are not transport addresses and are end-point. SMTP addresses are not transport addresses and are
security agnostic. Unlike HTTP, there is no URI scheme for email security agnostic. Unlike HTTP, there is no URI scheme for email
addresses to designate whether the SMTP server should be contacted addresses to designate whether the SMTP server should be contacted
with or without security. with or without security.
A Mail Transport Agent (MTA) may need to forward a message to a A Mail Transport Agent (MTA) may need to forward a message to a
particular email recipient <user@example.com>. To deliver the particular email recipient <user@example.com>. To deliver the
message, the MTA needs to retrieve the MX hosts of example.com from message, the MTA needs to retrieve the MX hosts of example.com from
DNS, and then deliver the message to one of them. Absent DNSSEC, the DNS, and then deliver the message to one of them. Absent DNSSEC, the
MX lookup is vulnerable to man-in-the-middle and cache poisoning MX lookup is vulnerable to man-in-the-middle and cache poisoning
attacks. As a result, secure verification of MX host certificates is attacks. An active attacker can forge DNS replies with fake MX
not possible without DNSSEC, as an active attacker can forge DNS records, and can direct traffic to a server of his choice.
replies with fake MX records, and can direct traffic to a server of Therefore, secure verification of MX host certificates is not
their choice. A man-in-the-middle can also suppress the MX host's possible without DNSSEC. A man in the middle can also suppress the
STARTTLS EHLO response, convincing the client that communication over MX host's STARTTLS EHLO response, convincing the client that
TLS is unavailable. communication over TLS is unavailable.
One might try to harden STARTTLS with SMTP against DNS attacks by One might try to harden STARTTLS with SMTP against DNS attacks by
requiring each MX host to posess an X.509 certificate for the requiring each MX host to posess an X.509 certificate for the
recipient domain that is obtained from the message envelope and is recipient domain that is obtained from the message envelope and is
not subject to DNS reply forgery. Unfortunately, this is not subject to DNS reply forgery. Unfortunately, this is
impractical, as email for many domains is handled by third parties, impractical, as email for many domains is handled by third parties,
which are not in a position to obtain certificates for all the which are not in a position to obtain certificates for all the
domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is
no panacea, since the key management is operationally challenging at no panacea, since SNI key management is operationally challenging
large scale unless the email service provider is also the domain's except when the email service provider is also the domain's registrar
registrar and its certificate issuer; this is rarely the case for and its certificate issuer; this is rarely the case for email.
email.
Since the recipient domain name cannot be used as the SMTP server Since the recipient domain name cannot be used as the SMTP server
authentication identity, nor can the MX hostname without DNSSEC, authentication identity, and neither can the MX hostname without
large scale deployment of authenticated TLS for SMTP requires secure DNSSEC, large scale deployment of authenticated TLS for SMTP requires
DNS. At this time, DNSSEC is not yet widely deployed and MTA to MTA secure DNS. At this time, DNSSEC is not yet widely deployed and MTA
traffic between Internet connected organizations rarely uses TLS at to MTA traffic between Internet connected organizations rarely uses
all, or simply uses TLS opportunistically without authentication and TLS at all, or simply uses TLS opportunistically without
protects against only passive eavesdropping attacks. authentication and protects against only passive eavesdropping
attacks.
The only exceptions are cases in which the sending MTA is statically The exceptions are cases in which the sending MTA is statically
configured to use TLS for mail sent to specific selected peer domains configured to use TLS for mail sent to specific selected peer domains
and is configured with appropriate names (or content digests) to and is configured with appropriate subject names (or content digests)
expect in the presented MX host certificates of those domains. Such to expect in the presented MX host certificates of those domains.
statically configured SMTP secure channels are also used rarely, and Such statically configured SMTP secure channels are used rarely,
only between domains that make bilateral arrangements with their generally between domains that make bilateral arrangements with their
business partners. Internet email, on the other hand, requires business partners. Internet email, on the other hand, requires
contacting many new domains for which security configurations can not contacting many new domains for which security configurations can not
be established in advance. be established in advance.
Note, the above does not apply to mail submission [RFC6409], where a Note, the above does not apply to mail submission [RFC6409], where a
mail user agent is pre-configured to send all email to a fixed Mail mail user agent is pre-configured to send all email to a fixed Mail
Submission Agent (MSA). Submission servers usually offer TLS and the Submission Agent (MSA). Submission servers usually offer TLS and the
Mail User Agent (MUA) can be statically configured to require TLS Mail User Agent (MUA) can be statically configured to require TLS
with its chosen MSA. The situation changes when submission servers with its chosen MSA. The situation changes when submission servers
are configured dynamically via SRV records (see [RFC6186] Section 6, are configured dynamically via SRV records (see [RFC6186] Section 6).
although this is not yet widely deployed). Applications to Applications to submission via SRV records will be discussed later in
submission via SRV records will be discussed later in this memo. this memo.
With little opportunity to use TLS authentication, MX hosts that With little opportunity to use TLS authentication, MX hosts that
support STARTTLS often use self-signed or private-CA issued X.509 support STARTTLS often use self-signed or private CA issued X.509
certificates. Sending systems are rarely configured with a certificates. Sending systems are rarely configured with a
comprehensive list of trusted CAs and do not check CRLs or implement comprehensive list of trusted CAs and do not check CRLs or implement
OCSP. In essence, they don't and can't reply on the existing public OCSP. In essence, they don't and can't rely on the existing public
CA PKI. This is not simply a result of complacency on the part SMTP CA PKI. This is not a result of complacency on the part SMTP server
server administrators and MTA developers. Nor is it just a result of administrators and MTA developers. Nor is it just a consequence of
the relative maturity of the SMTP infrastructure when TLS was the relative maturity of the SMTP infrastructure at the time that TLS
introduced. Rather, the abstraction of the SMTP transport endpoint was introduced. Rather, the abstraction of the SMTP transport
via DNS MX records, often across organization boundaries, limits the endpoint via DNS MX records, often across organization boundaries,
use of public CA PKI with SMTP to a small set of sender-configured limits the use of public CA PKI with SMTP to a small set of sender-
peer domains. configured peer domains.
This does not mean, however, that the Internet email backbone cannot This does not mean, however, that the Internet email backbone cannot
benefit from TLS. The fact that transport security is not explicitly benefit from TLS. The fact that transport security is not explicitly
specified in either the recipient address or the MX record means that specified in either the recipient address or the MX record means that
new protocols can furnish out-of-band information to SMTP, making it new protocols can furnish out-of-band information to SMTP, making it
possible to simultaneously discover both which peer domains support possible to simultaneously discover both which peer domains support
secure delivery via TLS and how to verify the authenticity of the secure delivery via TLS and how to verify the authenticity of the
associated MX hosts. The first such mechanism that can work an associated MX hosts. The first such mechanism that can work an
Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA
SMTP must be cognizant of the lack of any realistic role for the SMTP must be cognizant of the lack of any realistic role for the
existing public CA PKI. existing public CA PKI.
1.3. Terminology 1.3. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Hardening Opportunistic TLS 2. Hardening Opportunistic TLS
This section describes opportunistic SMTP over TLS security, where This memo describes opportunistic SMTP over TLS security, where
traffic from DANE TLSA aware SMTP clients to domains that implement traffic from DANE TLSA aware SMTP clients to domains that implement
DANE TLSA records in accordance with this memo is secure. Traffic to DANE TLSA records in accordance with this memo is secure. Traffic to
other domains continues to be sent in the same manner as before other domains continues to be sent in the same manner as before
(either manually configured for security or unencrypted and (either manually configured for security or unauthenticated and often
unauthenticated). It is hoped that, over time, more domains will unencrypted). It is hoped that, over time, more domains will
implement DNSSEC and publish DANE TLSA records for their MX hosts. implement DNSSEC and publish DANE TLSA records for their MX hosts.
This will enable an incremental transition of the email backbone to This will enable an incremental transition of the email backbone to
authenticated TLS delivery. authenticated TLS delivery.
Since email addresses and MX hostnames (or submission SRV records) Since email addresses and MX hostnames (or submission SRV records)
neither signal nor deny support for TLS by the receiving domain, it neither signal nor deny support for TLS by the receiving domain, it
is possible to use DANE TLSA records to securely signal TLS support is possible to use DANE TLSA records to securely signal TLS support
and simultaneously to provide the means by which SMTP clients can and simultaneously to provide the means by which SMTP clients can
successfully authenticate legitimate SMTP servers. successfully authenticate legitimate SMTP servers.
2.1. TLS discovery 2.1. TLS discovery
As noted previously (Section 1.2), opportunistic TLS with SMTP As noted previously (Section 1.2), opportunistic TLS with SMTP
servers that advertise TLS support via STARTTLS is subject to a man servers that advertise TLS support via STARTTLS is subject to a man
in the middle downgrade attack. Some SMTP servers erroneously in the middle downgrade attack. Some SMTP servers erroneously
advertise STARTTLS in default configurations that are not in fact TLS advertise STARTTLS in default configurations that are not, in fact,
capable, and clients need to be prepared to retry plaintext delivery TLS capable, and clients need to be prepared to retry plaintext
after STARTTLS fails. A downgrade resistant mechanism for a server delivery after STARTTLS fails. This memo specifies a downgrade
to advertise TLS support based on DANE TLSA records is specified resistant mechanism that allows a server to advertise TLS support
below. DNSSEC validated TLSA records are unlikely to be accidentally based on DANE TLSA records. DNSSEC validated TLSA records are
published for servers that do not in fact support TLS, and thus unlikely to be accidentally published for servers that do not in fact
clients can safely interpret their presence as a commitment by the support TLS, and thus clients can safely interpret their presence as
server operator to implement STARTTLS. a commitment by the server operator to implement STARTTLS.
SMTP is a store & forward protocol. An MTA that is not the final SMTP is a store & forward protocol. An MTA that is not the final
destination for a message recipient forwards the message one hop destination for a message recipient forwards the message one hop
closer to the recipient's mailbox. To do so, it must determine the closer to the recipient's mailbox. To do so, it must determine the
appropriate next-hop destination. appropriate next-hop destination, and locate one or more associated
SMTP servers. When DNSSEC validated TLSA records are available for a
given next-hop SMTP server, the TLS connection to that server will be
downgrade resistant. If the records in question are "usable"
([RFC6698], Section 4.1) to authenticate the server, the connection
will also be authenticated and thus immune to eavesdropping or
tampering (unless DNSSEC itself is compromised).
Typically, the next-hop destination defaults to the domain part of Typically, the next-hop destination will be the domain part of the
the recipient address, which is then subject to MX resolution. The recipient address, which is then subject to MX resolution. The next-
next-hop destination may also be configured by the MTA administrator hop destination may also be configured by the MTA administrator to be
to be a next-hop destination host (explicitly exempt from MX a next-hop destination host (explicitly exempt from MX resolution),
resolution), or a next-hop destination domain (subject to MX or a next-hop destination domain (subject to MX resolution) which
resolution) which takes the place of the domain part of the recipient takes the place of the domain part of the recipient address.
address. In the language of [RFC5321] Section 5.1, we'll refer to
this next-hop destination host or domain as "the initial name".
2.1.1. MX resolution The protocol in this memo is "opportunistic". Absent "secure"
(DNSSEC validated) TLSA records, mail delivery should generally fall
back to pre-DANE opportunistic TLS. The SMTP client may be
configured to require DANE verified delivery for some or all
destinations, in which case absent "secure" TLSA records delivery
will be deferred.
If the initial name is a next-hop domain subject to MX resolution, a Below we explain how to determine for a given next-hop destination
DNSSEC validated "MX" lookup is performed, to obtain the list of the associated SMTP servers, the TLSA base domain and TLSA records.
associated MX hosts. If no MX records are found, or if the initial
name is a next-hop host not subject to MX resolution, it is resolved
to one or more network addresses, by performing DNSSEC validated "A"
and/or "AAAA" lookups.
Following [RFC5321] Section 5.1, if the "A", "AAAA" or "MX" lookup of 2.1.1. Non-MX destinations
the initial name yields a CNAME, we replace it with the resulting
name as if it were the initial name and try the same lookup again
with the new name. MTAs typically support limited recursion in CNAME
expansion so this replacement is performed recursively. If
initially, or at any stage of recursion, the response is "bogus", MX
resolution fails with a temporary error. Mail delivery SHOULD either
be deferred or attempted via any alternative delivery channel
configured by the MTA administrator (which may also employ
opportunistic DANE TLS).
With a next-hop destination domain subject to MX resolution which has As mentioned above, the next-hop destination domain may in some cases
MX records, if at least one lookup in the (possibly empty) chain of be exempt from MX lookups. In addition, MX lookups for the next-hop
CNAMEs leading to the MX RRset is "insecure", opportunistic DANE TLS domain may yield no results. In either case, the destination server
is not applicable, and mail delivery may proceed with pre-DANE for such a domain is determined by looking up the corresponding A or
opportunistic TLS (subject to its various MITM attacks). AAAA records.
With a next-hop destination host not subject to MX resolution or a When "bogus" records are encountered either during CNAME expansion,
domain with no MX records, if at least one lookup in the (possibly or when retrieving the associated TLSA RRset, the SMTP client MUST
empty) chain of CNAMEs leading to the A or AAAA RRset is "insecure", proceed as if the next-hop domain were unreachable. Delivery should
the TLSA base domain is the initial next-hop name, and opportunistic either be deferred or may be attempted via any fallback next-hop
DANE TLS is applicable only when a "secure" TLSA RRset is found at (which may also employ opportunistic DANE TLS) configured by the SMTP
that base domain. client administrator. Proceeding with the original next-hop despite
"bogus" DNS responses would destroy protection against downgrade
attacks.
Otherwise, if at each and every stage of CNAME expansion the DNS Following [RFC5321] Section 5.1, if the A or AAAA lookup of the
response is "secure", and either the initial name is a next-hop host initial name yields a CNAME, we replace it with the resulting name as
name not subject to MX resolution or no MX records are found, the if it were the initial name and perform a lookup again using the new
resulting final name becomes the next-hop destination and is the base name. This replacement is performed recursively, although MTAs
domain for TLSA record lookup. In summary, the TLSA base domain is typically support only limited recursion in CNAME expansion. We
the fully CNAME expanded name that is "secure" or else is the initial consider the following cases:
name.
Finally, if at each and every stage the DNS response is "secure", and Non-CNAME: The next-hop destination domain is not a CNAME alias.
and one or more MX records are found, the MX records MUST be sorted The lookup key for the DNSSEC validated TLSA records is obtained
by preference. A better (numerically lower) MX preference for a host by prepending service labels ("_<port-number>._tcp") to the
that does not support TLS MUST NOT be preempted by a worse initial next-hop destination domain. If associated "secure" TLSA
(numerically higher) MX preference for a host that does support TLS. records are found (see Section 2.1.3) the TLSA base domain is the
In other words, avoiding delivery loops trumps any preference for next-hop domain. If no secure TLSA records are found,
channel security. In each delivery attempt via a candidate MX host, opportunistic DANE TLS is not applicable and mail delivery
the MX host MUST be treated as though it were the initial next-hop proceeds with pre-DANE opportunistic TLS.
destination host (which is, of course, not subject to further MX
resolution). The associated TLSA base domain is equal to the CNAME
resolved MX exchange name if CNAME expansion of MX exchange names is
supported and all CNAMEs encountered are "secure". Otherwise, the
unexpanded name of the MX exchange is the TLSA base domain.
CNAMEs are not legal in the exchange field of MX records, thus MTAs Insecure CNAME: The next-hop destination domain is a CNAME alias,
MAY skip over MX records in which the MX exchange is a CNAME. There but at least one of the CNAME RRs leading to the ultimate target
is some additional risk, in this case, that the MTA may fail to of this alias (during recursive CNAME expansion) is "insecure".
notice that it is one of the MX hosts for the destination and that it We treat this case just like the non-CNAME case above.
must skip MX records with equal or worse (numerically higher
precedence). If an MTA does allow CNAMEs to be used in MX records it
SHOULD process them recursively as described above to determine
whether opportunistic DANE TLS is applicable and if so the associated
TLSA RRset base domain.
2.1.2. TLSA record lookup Secure CNAME, no TLSA: The next-hop destination domain is a CNAME
alias, and all the CNAME RRs leading to the ultimate target of
this alias (during recursive CNAME expansion) are "secure" (DNSSEC
validated), but no "secure" TLSA RRs are found after prefixing the
service labels to the CNAME-expanded next-hop domain. This case
is also treated just like the non-CNAME case.
When all the DNSSEC lookups, "CNAME", "MX", "A" or "AAAA", used to Secure CNAME, TLSA: The next-hop destination domain is a CNAME
obtain a given TLSA base domain (one for each candidate MX host if alias, all the CNAME RRs leading to the ultimate target of this
multiple DNSSEC validated MX hosts were found) are "secure", and the alias (during recursive CNAME expansion) are "secure", and in
SMTP client is configured for opportunistic DANE TLS, it SHOULD addition "secure" TLSA RRs are found after prefixing the service
locate the TLSA RRset corresponding to this base domain. If, for labels to the CNAME-expanded next-hop domain. In this case the
example, the base domain is "mail.example.com", the TLSA RRset is CNAME-expanded next-hop domain is taken as the TLSA base domain.
obtained via a DNSSEC query of the form: The original next-hop domain is (see Section 2.2.2) used only as
an alternative name in certificate peername verification if
applicable.
In summary, if it is possible to securely obtain the full, CNAME-
expanded, DNSSEC-validated address records for the non-MX next-hop
domain then that name is the preferred TLSA base domain. If that is
not possible, then the original next-hop domain is used as the TLSA
base domain. When no "secure" TLSA records are found at either the
CNAME expanded or original next-hop domain, then opportunistic DANE
TLS does not apply for mail delivery to the non-MX destination in
question.
2.1.2. MX resolution
In this section we consider next-hop domains that are subject to MX
resolution and have MX records. When DANE TLS is applicable, the
TLSA base domain will be associated with the MX host selected for
message delivery. Therefore, the MX host names must be determined
securely by performing a DNSSEC validated MX lookup to obtain the
list of associated MX hosts. If the MX RRset is "insecure", DANE
TLSA does not apply and mail delivery proceeds with pre-DANE
opportunistic TLS (subject to its various MITM attacks and unecrypted
transmission when STARTTLS is not supported by the destination).
When "bogus" DNSSEC records are encountered during CNAME expansion of
the next-hop domain or when processing the actual MX RRset, delivery
MUST either be deferred, or MAY be attempted via any fallback next-
hop (which may also employ opportunistic DANE TLS) configured by the
SMTP client administrator. Proceeding with the original next-hop
despite "bogus" DNS responses would destroy protection against
downgrade attacks. When "bogus" DNSSEC records are encountered with
CNAME expansion or TLSA RRset lookup for a particular MX host,
delivery MUST proceed as if MX host in question were unreachable.
MX records MUST be sorted by preference; an MX host with a better
preference and no TLSA records MUST NOT be preempted by a host with a
worse MX preference but with TLSA records. In other words, avoiding
delivery loops by following MX preferences must take place even if it
means insecure delivery.
In accordance with Section 5.1 of [RFC5321], if the MX lookup of the
initial name yields a CNAME, we replace the initial name with the
resulting name and perform a new lookup with the new name. MTAs
typically support recursion in CNAME expansion, so this replacement
is performed repeatedly until the ultimate non-CNAME domain is found
(or the limit on the number of CNAMEs to examine is reached). If at
any stage of CNAME expansion the DNS result is "bogus", MX resolution
fails with a temporary error. In that case, mail delivery MUST
either be deferred, or attempted via any alternative delivery channel
configured by the MTA administrator. We consider the following
cases:
Non-CNAME: The next-hop destination domain is not a CNAME alias,
that is, it resolves directly to a set of DNSSEC validated
("secure") MX hosts. With each MX host, if MX host CNAME
expansion is supported by the MTA, and the full CNAME expansion of
the MX host name is "secure", then the CNAME expanded MX host name
is the TLSA base domain provided secure TLSA records are found
there after prefixing service labels ("_<port-number>._tcp").
Otherwise, the initial MX host name is the TLSA base domain
provided secure TLSA records are found there after prefixing
service labels. With the MX hostname (or its CNAME expansion) as
the TLSA base domain, the original next-hop domain SHOULD be used
only in certificate name checks. If no "secure" TLSA RRs are
found, and no "bogus" records encountered, DANE TLSA is not
applicable with the MX host in question and delivery proceeds as
with pre-DANE opportunistic TLS.
CNAME: The next-hop destination domain is a CNAME alias, and
resolves via a chain of "secure" CNAME records to a final domain
with "secure" MX records. The TLSA base domain for each MX host
in this case is the same as in the "Non-CNAME" case above, but now
both the initial domain and its CNAME-expansion are candidate
names in certificate name checks. If the CNAME chain contains
"insecure" elements, DANE TLSA does not apply to the next-hop
domain, and delivery proceeds via pre-DANE opportunistic TLS.
Note: CNAMEs are not legal in the exchange field of MX records, thus
MTAs are not obligated to perform MX exchange CNAME expansion. If an
MTA does not perform CNAME expansion, there is potential risk, that
the MTA may fail to notice that it is one of the MX hosts for the
destination and that it must skip MX records with equal or worse
(numerically higher precedence). If an MTA does allow CNAMEs to be
used in MX records, it SHOULD process them recursively as described
above to determine the most appropriate TLSA RRset base domain.
2.1.3. TLSA record lookup
Each TLSA base domain obtained above (for a non-MX destination, or
for a particular MX host of an MX destination), when prefixed with
appropriate service labels leads to associated "secure" TLSA RRs
(possibly via a chain of "secure" CNAME RRs). If, for example, the
base domain is "mail.example.com", the TLSA RRset is obtained via a
DNSSEC query of the form:
_25._tcp.mail.example.com. IN TLSA ? _25._tcp.mail.example.com. IN TLSA ?
Typically, the destination TCP port is 25, but this may be different Typically, the destination TCP port is 25, but this may be different
with custom routes specified by the MTA administrator or when an MUA with custom routes specified by the MTA administrator or when an MUA
connects to a submission server on port 587. The SMTP client MUST connects to a submission server on port 587. The SMTP client MUST
use the appropriate "_<port>" prefix in place of "_25" when the port use the appropriate "_<port-number>" prefix in place of "_25" when
number is not equal to 25. The query response may be a CNAME (or a the port number is not equal to 25. The query response may be a
DNAME + CNAME combination), or the TLSA RRset. DNAME processing with CNAME (or a DNAME + CNAME combination), or the TLSA RRset. If the
DNSSEC can be done using standard DNAME resolution techniques and record is a CNAME or DNAME, the SMTP client restarts the TLSA query
will not be discussed in detail here. The SMTP client MUST check the at the target domain, following CNAMEs as appropriate.
security status of the response.
If the response is "bogus", delivery via the host in question SHOULD CNAMEs encountered during TLSA record lookups can be used to share a
NOT proceed, otherwise the SMTP client is vulnerable to man in the single TLSA RRset specifying a common certificate authority or a
middle STARTTLS downgrade attacks. If the response is "insecure", common leaf certificate for multiple TLS services. Such CNAME
opportunistic DANE TLS is not applicable for the host in question, expansion does not change the SMTP client's notion of the TLSA base
and the SMTP client SHOULD proceed with ordinary opportunistic TLS. domain, thus when _25._tcp.mail.example.com is a CNAME the base
domain remains mail.example.com and is still used in peer certificate
name checks. For example:
If the response is "secure" and the record is a CNAME or DNAME, the example.com. IN MX 0 mail.example.com.
SMTP client restarts the TLSA query at the target domain, following example.com. IN MX 0 mail2.example.com.
CNAMEs as appropriate (such CNAME expansion does not change the SMTP _25._tcp.mail.example.com. IN CNAME 2.1.1._dane.example.com.
client's notion of the TLSA base domain). _25._tcp.mail2.example.com. IN CNAME 2.1.1._dane.example.com.
2.1.1._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14
9afbf4c8996fb924
27ae41e4649b934c
a495991b7852b855
If, after possible CNAME indirection, the response is "secure" and at Here, mail.example.com and mail2.example.com have certificates issued
least one TLSA record is found (even if not usable because it is under a common trust-anchor, but each MX host's TLSA base domain
unsupported by the implementation or administratively disabled) the remains its hostname and MUST match the subject name (or subject
next-hop host has committed to TLS support. The SMTP client SHOULD alternative name) in its certificate.
NOT deliver mail via such a next-hop host unless a TLS session is
negotiated via STARTTLS. This avoids man in the middle STARTTLS
downgrade attacks.
When no TLSA records are found at a CNAME-expanded initial name If, after possible CNAME indirection, at least one "secure" TLSA
(insecure response or no records), the unexpanded initial name MUST record is found (even if not usable because it is unsupported by the
be tried instead. This supports clients of hosting providers where implementation or administratively disabled) the next-hop host has
the provider zone is not DNSSEC validated, but the client has shared committed to TLS support. The SMTP client SHOULD NOT deliver mail
appropriate key material with the hosting provider to enable TLS via via such a next-hop host unless a TLS session is negotiated via
SNI. STARTTLS. This avoids man in the middle STARTTLS downgrade attacks.
When usable TLSA records are available, a client SHOULD NOT deliver As noted previously (Section 2.1.1, Section 2.1.2), when no TLSA
mail via a server that fails to match at least one TLSA record. This records are found at a CNAME-expanded name (due to an insecure
is not a "must" because clients may incrementally deploy response or a lack of TLSA records verified by DNSSEC's proof-of-non-
opportunistic DANE TLS only for selected peer domains. At times, existence), the unexpanded name MUST be tried instead. This supports
clients may need to disable opportunistic DANE TLS for peers that clients of hosting providers where the provider's zone is not DNSSEC
fail to interoperate due to misconfiguration or software defects on validated, but the client has shared appropriate key material with
either end. For opportunistic DANE TLS to be robust (resistant to the hosting provider to enable TLS via SNI.
failures), servers MUST live up to the promises stated by the
existence of the TLSA record, but it is not always possible to compel SMTP clients may deploy opportunistic DANE TLS incrementally by
clients to use a security policy chosen by the server. Given a enabling it only for selected sites, or may occasionally need to
robust security protocol, clients will hopefully, over time, disable opportunistic DANE TLS for peers that fail to interoperate
willingly choose to adopt it. due to misconfiguration or software defects on either end. Unless
local policy specifies that opportunistic DANE TLS is not to be used
for a particular destination, client MUST NOT deliver mail via a
server whose certificate chain fails to match at least one TLSA
record when usable TLSA records are available.
SMTP clients employing opportunistic DANE TLS and TLSA record SMTP clients employing opportunistic DANE TLS and TLSA record
publishers for SMTP servers need to follow the guidance outlined in publishers for SMTP servers need to follow the guidance outlined in
[I-D.dukhovni-dane-ops]'s "Certificate Name Check Conventions", [I-D.ietf-dane-ops]'s "Certificate Name Check Conventions", "Service
"Service Provider and TLSA Publisher Synchronization" and "TLSA Base Provider and TLSA Publisher Synchronization" and "TLSA Base Domain
Domain and CNAMEs" sections. and CNAMEs" sections.
2.2. DANE authentication 2.2. DANE authentication
2.2.1. TLSA certificate usages 2.2.1. TLSA certificate usages
As noted in the introduction, the existing public CA PKI is not
viable for the Internet email backbone. TLSA records for MX hosts or
submission servers that are to be found via SRV records SHOULD NOT
include certificate usage "0" or "1", as in both cases SMTP clients
cannot be expected to perform [RFC5280] PKIX validation or [RFC6125]
identity verification. Clients MAY treat such TLSA records as
unusable.
SMTP clients may also to the extent possible map these usages to the
corresponding non-PKIX certificate usages (0 to 2 and 1 to 3).
Servers publishing these certificate usages hoping to be protected by
both the public CA PKI and by DNSSEC will typically be protected by
neither.
TLSA Publishers should follow the TLSA publication size guidance TLSA Publishers should follow the TLSA publication size guidance
found in [I-D.dukhovni-dane-ops] about "DANE DNS Record Size found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
Guidelines".
2.2.1.1. Certificate usage 3 2.2.1.1. Certificate usage 3
Since opportunistic DANE TLS will be used by non-interactive MTAs, Since opportunistic DANE TLS will be used by non-interactive MTAs,
with no user to "press OK" when authentication fails, reliability of with no user to "press OK" when authentication fails, reliability of
peer authentication is paramount. TLSA records published for SMTP peer authentication is paramount. TLSA records published for SMTP
servers SHOULD be "3 1 1" records to support opportunistic SMTP over servers SHOULD be "3 1 1" records to support opportunistic SMTP over
TLS with DANE. This record specifies the SHA-256 digest of the TLS with DANE. This record specifies the SHA-256 digest of the
server's public key. server's public key. Since all DANE implementations are required to
support SHA-256, this record works for all clients and need not
change across certificate renewals with the same key.
Authentication via certificate usage "3" TLSA records involves simply
checking that the server's leaf certificate matches the TLSA record.
Other than extracting the relevant certificate elements for
comparison, no other use is made of the certificate content.
Authentication via certificate usage "3" TLSA records involves no Authentication via certificate usage "3" TLSA records involves no
certificate authority signature checks. It also involves no server certificate authority signature checks. It also involves no server
name checks, and thus does not impose any new requirements on the name checks, and thus does not impose any new requirements on the
names contained in the server certificate (SNI is not required when names contained in the server certificate (SNI is not required when
the TLSA record matches the public key of the server's default the TLSA record matches server's default certificate).
certificate). It uses the SHA-256 digest which all clients are
obligated to support, and works across certificate renewals with the
same key.
Two TLSA records will need to be published before updating a server's Two TLSA records will need to be published before updating a server's
public key, one matching the currently deployed key and the other public key, one matching the currently deployed key and the other
matching the new key scheduled to replace it. Once sufficient time matching the new key scheduled to replace it. Once sufficient time
has elapsed for all DNS caches to time out the previous TLSA RRset, has elapsed for all DNS caches to time out the previous TLSA RRset,
which contains only the old key, the server may be reconfigured to which contains only the old key, the server may be reconfigured to
use the new private key and associated public key certificate. The use the new private key and associated public key certificate. The
amount of time a server should wait before using a new key that is amount of time a server should wait before using a new key that is
referenced by new TLSA records should be at least twice the TTL of referenced by new TLSA records should be at least twice the TTL of
the previously published TLSA records. Once the server is using a the previously published TLSA records. Once the server is using a
skipping to change at page 10, line 20 skipping to change at page 12, line 9
for multiple TLS services, it may be simpler to publish the issuing for multiple TLS services, it may be simpler to publish the issuing
authority's public key as a trust-anchor for the certificate chains authority's public key as a trust-anchor for the certificate chains
of all relevant services. The TLSA RRs for each service issued by of all relevant services. The TLSA RRs for each service issued by
the same TA may then be CNAMEs to a common TLSA RRset that matches the same TA may then be CNAMEs to a common TLSA RRset that matches
the TA. In this case, the certificate chain presented in the TLS the TA. In this case, the certificate chain presented in the TLS
handshake of each service SHOULD include the TA certificate, as SMTP handshake of each service SHOULD include the TA certificate, as SMTP
clients cannot generally be expected to have domain-issued trust- clients cannot generally be expected to have domain-issued trust-
anchor certificates in their trusted certificate store. TLSA anchor certificates in their trusted certificate store. TLSA
Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters, Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters,
which specify the SHA-256 digest of the trust-anchor public key or which specify the SHA-256 digest of the trust-anchor public key or
certificate respectively. As with regular certificate rollover certificate respectively. As with leaf certificate rollover
discussed in Section 2.2.1.1, two such TLSA RRs need to be published discussed in Section 2.2.1.1, two such TLSA RRs need to be published
to facilitate TA certificate rollover. to facilitate TA certificate rollover.
The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not
assured. If server operators employing these RRs universally ensure assured. If server operators employing these RRs universally ensure
that the corresponding TA certificate is included in the SMTP that the corresponding TA certificate is included in the SMTP
server's TLS handshake trust chain, clients can safely enable support server's TLS handshake certificate chain, clients can safely enable
for these RRs. If sufficiently many server administrators are support for these RRs. If sufficiently many server administrators
negligent in deploying these RRs, SMTP clients will be hesitant to negligently omit the TA certificate from the server's TLS certificate
support them, since mail delivery will not work to many destination chain, SMTP clients will be hesitant to support usage "2" TLSA RRs,
domains if they do. Server operators are encouraged to implement since mail delivery will not work to many destination domains if they
these RRs, if they are operationally a better fit for their do. Server operators are encouraged to implement these RRs, if they
organization, provided they do so with care. It is critical to never are operationally a better fit for their organization, provided they
forget to include trust-anchor certificates in server trust chains. do so with care. It is critical to not forget to include trust-
SMTP client implementations SHOULD support these TLSA RRs, unless anchor certificates in server trust chains. SMTP client
server operators fail publish certificate chains that include the implementations SHOULD support these TLSA RRs, unless, despite the
required TA certificate. above warning, a non-trivial fraction of server operators fail to
publish certificate chains that include the required TA certificate.
2.2.1.3. Certificate usage 1
SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "1".
Clients MAY treat such TLSA records as unusable. Alternatively, SMTP
clients that implement this specification MAY ignore the PKIX
validation requirement when they encounter certificate usage "1", and
authenticate the server per the content of the TLSA record alone.
That is, SMTP clients may treat certificate usage "1" as certificate
usage "3".
2.2.1.4. Certificate usage 0
SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0".
Clients MAY treat such TLSA records as unusable. Alternatively,
since PKIX validation is not possible with opportunistic DANE TLS,
SMTP clients MAY treat certificate usage "0" RRs as though they were
certificate usage "2" RRs. But, with certificate usage "0" the
usability of the TLSA record depends more strongly on its matching
type.
If the matching type is "0" (the server should also avoid this 2.2.1.3. Certificate usages 0 and 1
matching type and should publish usage "3" or "2" public key or
certificate digests), the TLSA record contains the full certificate
or full public key of the trusted certificate authority. In this
case the client has all the information it needs to match the server
trust-chain to the TLSA record. The client SHOULD ignore the PKIX
validation requirement, and verify the server's trust chain via its
DANE TLSA records only (name checks still apply as with usage "2").
If the matching type is not "0", the TLSA record contains only a SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0"
digest of the trust certificate authority certificate or public key. or "1". SMTP clients cannot be expected to be configured with a
The server operator publishing usage 0 TLSA records may expect that suitably complete set of trusted public CAs. Even with a full set of
clients already have the issuing authority certificate on hand, and public CAs, SMTP clients cannot (without relying on DNSSEC for secure
may omit it from the server's certificate chain. As a result, the MX records) perform [RFC6125] server identity verification.
client may not be able to match the server trust chain against the
TLSA record if it, in fact, does not have a copy of the certificate
authority certificate or public key.
SMTP clients that implement this specification SHOULD treat TLSA SMTP client treatment of TLSA RRs with certificate usages "0" or "1"
records with certificate usage "0" and a digest matching type as is undefined. For example, clients MAY (will likely) treat such TLSA
unusable, but MAY be explicitly configured to support them when it is records as unusable.
believed that clients posses a sufficiently complete set of trusted
public CA certificates. This is most plausible with an MUA which
only needs enough CA certificates to authenticate its preferred
submission service.
2.2.2. Certificate matching 2.2.2. Certificate matching
When at least one usable "secure" TLSA record is found, the SMTP When at least one usable "secure" TLSA record is found, the SMTP
client SHOULD use TLSA records to authenticate the next-hop host, client SHOULD use TLSA records to authenticate the next-hop host,
mail SHOULD not be delivered via this next-hop host if authentication mail SHOULD not be delivered via this next-hop host if authentication
fails, otherwise the SMTP client is vulnerable to TLS man in the fails, otherwise the SMTP client is vulnerable to TLS man in the
middle attacks. middle attacks.
To match a server via a TLSA record with certificate usage "2", the To match a server via a TLSA record with certificate usage "2", the
client MUST perform name checks to ensure that it has reached the client MUST perform name checks to ensure that it has reached the
correct server. The SMTP client MUST accept the TLSA base domain as correct server. In all cases the SMTP client MUST accept the TLSA
a valid DNS name in the server certificate. Clients should also base domain as a valid DNS name in the server certificate.
accept securely looked up TLSA base domain obtained indirectly via an
MX lookup, or a CNAME resolved expansion. MX: If the TLSA base domain was obtained indirectly via an MX lookup
(it is the name of an MX exchange that may be securely CNAME
expanded), then the initial query name used in the MX lookup
SHOULD be accepted in the peer certificate. The CNAME-expanded
initial query name SHOULD also be accepted if different from the
initial query name.
Non-MX: If no MX records were found and the TLSA base domain is the
CNAME-expanded initial query name, then the initial query name
SHOULD also be accepted.
Accepting certificates with the next-hop domain in addition to the Accepting certificates with the next-hop domain in addition to the
next-hop MX host allows a domain with multiple MX hosts to field a next-hop MX host allows a domain with multiple MX hosts to field a
single certificate bearing the email domain name across all the MX single certificate bearing the email domain name across all the MX
hosts, this is also compatible with pre-DANE SMTP clients that are hosts, this is also compatible with pre-DANE SMTP clients that are
configured to look for the email domain name in server certificates. configured to look for the email domain name in server certificates.
The client MUST NOT perform certificate usage name checks with The SMTP client MUST NOT perform certificate usage name checks with
certificate usage "3", since with usage "3" the server is certificate usage "3", since with usage "3" the server is
authenticated directly by matching the TLSA RRset to its certificate authenticated directly by matching the TLSA RRset to its certificate
or public key without resort to any issuing authority. The or public key without resort to any issuing authority. The
certificate content is ignored except in so far as it is used to certificate content is ignored except in so far as it is used to
match the certificate or public key digest with the TLSA RRset. match the certificate or public key (ASN.1 object or its digest) with
the TLSA RRset.
To ensure that the server sends the right certificate chain, the SMTP To ensure that the server sends the right certificate chain, the SMTP
client MUST send the TLS SNI extension containing the TLSA base client MUST send the TLS SNI extension containing the TLSA base
domain. Since DANE-aware clients are obligated to send SNI domain. Since DANE-aware clients are obligated to send SNI
information, which requires at least TLS 1.0, SMTP servers for which information, which requires at least TLS 1.0, SMTP servers for which
DANE TLSA records are published MUST support TLS 1.0 or later with DANE TLSA records are published MUST support TLS 1.0 or later with
any client authorized to use the service. any client authorized to use the service.
Each SMTP server MUST present a certificate trust chain (see Each SMTP server MUST present a certificate chain (see [RFC2246]
[RFC2246] Section 7.4.2) that matches at least one of the TLSA Section 7.4.2) that matches at least one of the TLSA records. The
records. The server MAY rely on SNI to determine which certificate server MAY rely on SNI to determine which certificate chain to
chain to present to the client. Clients that don't send SNI present to the client. Clients that don't send SNI information may
information may not see the expected certificate chain. not see the expected certificate chain.
If the server's TLSA RRset includes records with a matching type If the server's TLSA RRset includes records with a matching type
indication a digest record (i.e., a value other than "0"), the indicating a digest record (i.e., a value other than "0"), the
SHA-256 digest of any object SHOULD be provided along with any other SHA-256 digest of any object SHOULD be provided along with any other
digest published, since clients may support only SHA-256. Unless digest published, since clients may support only SHA-256. Unless
SHA-256 proves vulnerable to a "second preimage" attack, it should be SHA-256 proves vulnerable to a "second preimage" attack, it should be
the only digest algorithm used in TLSA records. the only digest algorithm used in TLSA records.
If the server's TLSA records match the server's default certificate If the server's TLSA records match the server's default certificate
chain, the server need not support SNI. The server need not include chain, the server need not support SNI. The server need not include
the extension in its TLS HELLO, simply returning a matching the extension in its TLS HELLO, simply returning a matching
certificate chain is sufficient. Servers MUST NOT enforce the use of certificate chain is sufficient. Servers MUST NOT enforce the use of
SNI by clients, if the client sends no SNI extension, or sends an SNI SNI by clients, if the client sends no SNI extension, or sends an SNI
extension for an unsupported domain the server MUST simply use its extension for an unsupported domain the server MUST simply use its
default certificate chain. The client may be using unauthenticated default certificate chain. The client may be using unauthenticated
opportunistic TLS and may not expect any particular certificate from opportunistic TLS and may not expect any particular certificate from
the server. the server.
The client may even offer to use anonymous TLS ciphersuites and The client may even offer to use anonymous TLS ciphersuites and
servers SHOULD support these, no security is gained by forcing the servers SHOULD support these. No security is gained by sending a
use of a certificate the client will ignore. Indeed support for certificate the client is willing to ignore. Indeed support for
anonymous ciphersuites in the server makes audit trails more useful anonymous ciphersuites in the server makes audit trails more useful
if the chosen ciphersuite is logged, as this will in many cases when the chosen ciphersuite is logged, as this will in many cases
record which clients did not care to authenticate the server. (The record which clients did not care to authenticate the server. (The
Postfix SMTP server supports anonymous TLS ciphersuites by default, Postfix SMTP server supports anonymous TLS ciphersuites by default,
and the Postfix SMTP client offers these at its highest preference and the Postfix SMTP client offers these at its highest preference
when server authentication is not applicable). when server authentication is not applicable).
With opportunistic DANE TLS, both the TLS support implied by the With opportunistic DANE TLS, both the TLS support implied by the
presence of DANE TLSA records and the verification parameters presence of DANE TLSA records and the verification parameters
necessary to authenticate the TLS peer are obtained together, necessary to authenticate the TLS peer are obtained together,
therefore authentication via this protocol is expected to be less therefore authentication via this protocol is expected to be less
prone to connection failure caused by incompatible configuration of prone to connection failure caused by incompatible configuration of
the client and server. the client and server.
3. Opportunistic TLS for Submission 3. Opportunistic TLS for Submission
Prior to [RFC6409], the SMTP submission protocol was a poster child Prior to [RFC6409], the SMTP submission protocol was a poster-child
for PKIX TLS. The MUA typically connects to one or more submission for PKIX TLS. The MUA typically connects to one or more submission
servers explicitly configured by the user. There is no indirection servers explicitly configured by the user. There is no indirection
via insecure MX records, and unlike web browsers, there is no need to via insecure MX records, and unlike web browsers, there is no need to
authenticate a large set of TLS servers. Once TLS is enabled for the authenticate a large set of TLS servers. Once TLS is enabled for the
desired submission server or servers, provided the server certificate desired submission server or servers, provided the server certificate
is correctly maintained, the MUA is able to reliably use TLS to is correctly maintained, the MUA is able to reliably use TLS to
authenticate the submission server. authenticate the submission server.
[RFC6186] aims to simplify the configuration of the MUA submission [RFC6186] aims to simplify the configuration of the MUA submission
service by dynamically deriving the submission service from the service by dynamically deriving the submission service from the
user's email address. This is done via SRV records, but at the cost user's email address. This is done via SRV records, but at the cost
of introducing the same TLS security problems faced by MTA to MTA of introducing the same TLS security problems faced by MTA to MTA
SMTP. Prompting the user when the SRV record domain is different SMTP. Prompting the user when the SRV record domain is different
from the email domain is not a robust solution. from the email domain is not a robust solution.
The protocol defined in this memo can also be used to The protocol defined in this memo can also be used to secure
opportunistically secure the submission service association. If the submission service discovery. If the email domain is DNSSEC signed,
email domain is DNSSEC signed, the SRV records are "secure" and the the SRV records are "secure" and the SRV host publishes secure TLSA
SRV host publishes secure TLSA records for submission, then the MUA records for submission, then the MUA can safely auto-configure to
can safely auto-configure to authenticate the submission server via authenticate the submission server via DANE. When DANE TLSA records
DANE. When DANE TLSA records are not available, the client SHOULD are not available, the client SHOULD fall back to legacy behavior
fall back to legacy behavior. (this may involve prompting the user to accept the resulting server
and perhaps "pin" its certificate).
Specifically, MUAs that dynamically determine the submission server Specifically, MUAs that dynamically determine the submission server
via SRV records SHOULD support DNSSEC and DANE TLSA records. They via SRV records SHOULD support DNSSEC and DANE TLSA records. They
SHOULD use TLSA records to authenticate the server. The processing SHOULD use TLSA records to authenticate the server. The processing
of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA
with SRV records replaced by corresponding MX records. with SRV records replaced by corresponding MX records.
Just as with port 25, SMTP submission servers SHOULD NOT publish Just as with MX service on port 25, SMTP submission servers SHOULD
usage 0 or 1 TLSA associations, and MUAs that support DANE TLSA are NOT publish usage 0 or 1 TLSA associations, and MUAs that support
not expected to trust a full list of public CAs. Server certificate DANE TLSA are not expected to trust a full list of public CAs.
subjectAltNames should include at least the server name. When the Server certificate subjectAltNames should include at least the server
server administrator is also authorized to obtain certificates for name. When the server administrator is able to obtain a certificate
the email domain, the server certificate should also include the for the email domain, the server certificate should also include the
email domain name. MUAs that are not able to support DNSSEC may then email domain name. MUAs that are not able to support DNSSEC may then
be able to authenticate the server domain. If it is practical to be able to authenticate the server domain. If it is practical to
field additional certificates for hosted domains, SNI may be used by field additional certificates for hosted domains, SNI may be used by
the server to select the appropriate domain's certificate. the server to select the appropriate domain's certificate.
4. Mandatory TLS Security 4. Mandatory TLS Security
An MTA implementing this protocol may require a stronger security An MTA implementing this protocol may require a stronger security
assurance when sending email to selected destinations to which the assurance when sending email to selected destinations to which the
sending organization sends sensitive email and may have regulatory sending organization sends sensitive email and may have regulatory
skipping to change at page 16, line 18 skipping to change at page 17, line 38
to prevent MITM attacks. A successful breach of DNSSEC enables the to prevent MITM attacks. A successful breach of DNSSEC enables the
attacker to publish TLSA usage 3 certificate associations, and attacker to publish TLSA usage 3 certificate associations, and
thereby bypass any security benefit the legitimate domain owner might thereby bypass any security benefit the legitimate domain owner might
hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
public CA PKI support in existing MTA deployments, deprecating public CA PKI support in existing MTA deployments, deprecating
certificate usages 0 and 1 in this specifications improves certificate usages 0 and 1 in this specifications improves
interoperability without degrading security. interoperability without degrading security.
7. Normative References 7. Normative References
[I-D.dukhovni-dane-ops] [I-D.ietf-dane-ops]
Dukhovni, V., "DANE TLSA implementation and operational Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
guidance", draft-dukhovni-dane-ops-00 (work in progress), and operational guidance", draft-ietf-dane-ops-00 (work in
May 2013. progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
 End of changes. 58 change blocks. 
293 lines changed or deleted 351 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/