< draft-ietf-dane-smtp-with-dane-10.txt   draft-ietf-dane-smtp-with-dane-11.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: November 26, 2014 Parsons Expires: February 3, 2015 Parsons
May 25, 2014 August 2, 2014
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-10 draft-ietf-dane-smtp-with-dane-11
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 November 26, 2014. This Internet-Draft will expire on February 3, 2015.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7 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 . . . . . . . . . . . . 8
1.3.4. Too many certification authorities . . . . . . . . . 8 1.3.4. Too many certification authorities . . . . . . . . . 8
2. Identifying applicable TLSA records . . . . . . . . . . . . . 8 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
2.1.1. DNS errors, bogus and indeterminate responses . . . . 8 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
2.1.3. Stub resolver considerations . . . . . . . . . . . . 11 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 23 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
3.2.3. Reference identifier matching . . . . . . . . . . . . 24 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
4. Server key management . . . . . . . . . . . . . . . . . . . . 25 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 28
7. Note on DANE for Message User Agents . . . . . . . . . . . . 28 7. Note on DANE for Message User Agents . . . . . . . . . . . . 29
8. Interoperability considerations . . . . . . . . . . . . . . . 29 8. Interoperability considerations . . . . . . . . . . . . . . . 29
8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 29 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 30
9. Operational Considerations . . . . . . . . . . . . . . . . . 30 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
9.1. Client Operational Considerations . . . . . . . . . . . . 30 9.1. Client Operational Considerations . . . . . . . . . . . . 30
9.2. Publisher Operational Considerations . . . . . . . . . . 30 9.2. Publisher Operational Considerations . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 neither email addresses nor MX hostnames signal a records and that neither email addresses nor MX hostnames signal a
requirement for either secure or cleartext transport. Therefore, requirement for either secure or cleartext transport. Therefore,
aside from a few manually configured exceptions, SMTP transport aside from a few manually configured exceptions, SMTP transport
security is of necessity opportunistic. security is of necessity opportunistic.
This specification uses the presence of DANE TLSA records to securely This specification uses the presence of DANE TLSA records to securely
signal TLS support and to publish the means by which SMTP clients can signal TLS support and to publish the means by which SMTP clients can
successfully authenticate legitimate SMTP servers. This becomes successfully authenticate legitimate SMTP servers. This becomes
"opportunistic DANE TLS" and is resistant to downgrade and MITM "opportunistic DANE TLS" and is resistant to downgrade and man-in-
attacks. It enables an incremental transition of the email backbone the-middle (MITM) attacks. It enables an incremental transition of
to authenticated TLS delivery, with increased global protection as the email backbone to authenticated TLS delivery, with increased
adoption increases. global protection as adoption increases.
With opportunistic DANE TLS, traffic from SMTP clients to domains With opportunistic DANE TLS, traffic from SMTP clients to domains
that publish "usable" DANE TLSA records in accordance with this memo that publish "usable" DANE TLSA records in accordance with this memo
is authenticated and encrypted. Traffic from legacy clients or to is authenticated and encrypted. Traffic from legacy clients or to
domains that do not publish TLSA records will continue to be sent in domains that do not publish TLSA records will continue to be sent in
the same manner as before, via manually configured security, (pre- the same manner as before, via manually configured security, (pre-
DANE) opportunistic TLS or just cleartext SMTP. 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
skipping to change at page 4, line 12 skipping to change at page 4, line 12
traffic by an adversary able to thereby compromise the traffic by an adversary able to thereby compromise the
confidentiality or integrity of the data. confidentiality or integrity of the data.
secure, bogus, insecure, indeterminate: DNSSEC validation results, secure, bogus, insecure, indeterminate: DNSSEC validation results,
as defined in Section 4.3 of [RFC4035]. as defined in Section 4.3 of [RFC4035].
Validating Security-Aware Stub Resolver and Non-Validating Validating Security-Aware Stub Resolver and Non-Validating
Security-Aware Stub Resolver: Security-Aware Stub Resolver:
Capabilities of the stub resolver in use as defined in [RFC4033]; Capabilities of the stub resolver in use as defined in [RFC4033];
note that this specification requires the use of a Security-Aware note that this specification requires the use of a Security-Aware
Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used. Stub Resolver.
opportunistic DANE TLS: Best-effort use of TLS, resistant to
downgrade attacks for destinations with DNSSEC-validated TLSA
records. When opportunistic DANE TLS is determined to be
unavailable, clients should fall back to opportunistic TLS below.
Opportunistic DANE TLS requires support for DNSSEC, DANE and
STARTTLS on the client side and STARTTLS plus a DNSSEC published
TLSA record on the server side.
(pre-DANE) opportunistic TLS: Best-effort use of TLS that is (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
generally vulnerable to DNS forgery and STARTTLS downgrade generally vulnerable to DNS forgery and STARTTLS downgrade
attacks. When a TLS-encrypted communication channel is not attacks. When a TLS-encrypted communication channel is not
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.
opportunistic DANE TLS: Best-effort use of TLS, resistant to
downgrade attacks for destinations with DNSSEC-validated TLSA
records. When opportunistic DANE TLS is determined to be
unavailable, clients should fall back to opportunistic TLS.
Opportunistic DANE TLS requires support for DNSSEC, DANE and
STARTTLS on the client side and STARTTLS plus a DNSSEC published
TLSA record on the server side.
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 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
process. When an MTA is unable forward a message that may become process. When an MTA is unable forward a message that may become
deliverable later, the message is queued and delivery is retried deliverable later the message is queued and delivery is retried
periodically. Some MTAs may be configured with a fallback next- periodically. Some MTAs may be configured with a fallback next-
hop destination that handles messages that the MTA would otherwise hop destination that handles messages that the MTA would otherwise
queue and retry. In these cases, messages that would otherwise queue and retry. When a fallback next-hop is configured, messages
have to be delayed, may be sent to the fallback next-hop that would otherwise have to be delayed may be sent to the
destination instead. The fallback destination may itself be fallback next-hop destination instead. The fallback destination
subject to opportunistic or mandatory DANE TLS as though it were may itself be subject to opportunistic or mandatory DANE TLS as
the original message destination. though it were the original message destination.
original next hop destination: The logical destination for mail original next hop destination: The logical destination for mail
delivery. By default this is the domain portion of the recipient delivery. By default this is the domain portion of the recipient
address, but MTAs may be configured to forward mail for some or address, but MTAs may be configured to forward mail for some or
all recipients via designated relays. The original next hop all recipients via designated relays. The original next hop
destination is, respectively, either the recipient domain or the destination is, respectively, either the recipient domain or the
associated configured relay. associated configured relay.
MTA: Message Transfer Agent ([RFC5598], Section 4.3.2). MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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. An
envelope recipient addresses are not transport addresses and are SMTP envelope recipient address does not correspond to a specific
security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and transport-layer endpoint address, rather at each relay hop the
its corresponding secured version, HTTPS, where the use of TLS is transport-layer endpoint is the next-hop relay, while the envelope
signaled via the URI scheme, email recipient addresses do not recipient address typically remains the same. Unlike the Hypertext
directly signal transport security policy. Indeed, no such signaling Transfer Protocol (HTTP) and its corresponding secured version,
could work well with SMTP since TLS encryption of SMTP protects email HTTPS, where the use of TLS is signaled via the URI scheme, email
traffic on a hop-by-hop basis while email addresses could only recipient addresses do not directly signal transport security policy.
express end-to-end policy. Indeed, no such signaling could work well with SMTP since TLS
encryption of SMTP protects email traffic on a hop-by-hop basis while
email addresses could only express end-to-end policy.
With no mechanism available to signal transport security policy, SMTP 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
over a cleartext SMTP connection, and, if the client also supports over a cleartext SMTP connection, and, if the client also supports
TLS, it may negotiate a TLS encrypted channel to use for email TLS, it may negotiate a TLS encrypted channel to use for email
transmission. The server's indication of TLS support can be easily transmission. The server's indication of TLS support can be easily
suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
skipping to change at page 7, line 16 skipping to change at page 7, line 29
With SMTP, DNS Mail Exchange (MX) records abstract the next-hop With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
transport endpoint and allow administrators to specify a set of transport endpoint and allow administrators to specify a set of
target servers to which SMTP traffic should be directed for a given target servers to which SMTP traffic should be directed for a given
domain. domain.
A PKIX TLS client is vulnerable to MITM attacks unless it verifies A PKIX TLS client is vulnerable to MITM attacks unless it verifies
that the server's certificate binds the public key to a name that that the server's certificate binds the public key to a name that
matches one of the client's reference identifiers. A natural choice matches one of the client's reference identifiers. A natural choice
of reference identifier is the server's domain name. However, with of reference identifier is the server's domain name. However, with
SMTP, server names are obtained indirectly via MX records. Without SMTP, server names are not directly encoded in the recipient address,
DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning instead they are obtained indirectly via MX records. Without DNSSEC,
attacks. Active attackers can forge DNS replies with fake MX records the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
and can redirect email to servers with names of their choice. Active attackers can forge DNS replies with fake MX records and can
Therefore, secure verification of SMTP TLS certificates matching the redirect email to servers with names of their choice. Therefore,
server name is not possible without DNSSEC. secure verification of SMTP TLS certificates matching the server name
is not possible without DNSSEC.
One might try to harden TLS for SMTP against DNS attacks by using the One might try to harden TLS for SMTP against DNS attacks by using the
envelope recipient domain as a reference identifier and requiring envelope recipient domain as a reference identifier and requiring
each SMTP server to possess a trusted certificate for the envelope each SMTP server to possess a trusted certificate for the envelope
recipient domain rather than the MX hostname. Unfortunately, this is recipient domain rather than the MX hostname. 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
that are not in a position to obtain certificates for all the domains that are not in a position to obtain certificates for all the domains
they serve. Deployment of the Server Name Indication (SNI) extension they serve. Deployment of the Server Name Indication (SNI) extension
to TLS (see [RFC6066] Section 3) is no panacea, since SNI key to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
management is operationally challenging except when the email service management is operationally challenging except when the email service
skipping to change at page 7, line 45 skipping to change at page 8, line 10
Since the recipient domain name cannot be used as the SMTP server Since the recipient domain name cannot be used as the SMTP server
reference identifier, and neither can the MX hostname without DNSSEC, reference identifier, and neither can the MX hostname without DNSSEC,
large-scale deployment of authenticated TLS for SMTP requires that large-scale deployment of authenticated TLS for SMTP requires that
the DNS be secure. the DNS be secure.
Since SMTP security depends critically on DNSSEC, it is important to Since SMTP security depends critically on DNSSEC, it is important to
point out that consequently SMTP with DANE is the most conservative point out that consequently SMTP with DANE is the most conservative
possible trust model. It trusts only what must be trusted and no possible trust model. It trusts only what must be trusted and no
more. Adding any other trusted actors to the mix can only reduce more. Adding any other trusted actors to the mix can only reduce
SMTP security. A sender may choose to further harden DNSSEC for SMTP security. A sender may choose to further harden DNSSEC for
selected high-value receiving domains, by configuring explicit trust selected high-value receiving domains by configuring explicit trust
anchors for those domains instead of relying on the chain of trust anchors for those domains instead of relying on the chain of trust
from the root domain. Detailed discussion of DNSSEC security from the root domain. However, detailed discussion of DNSSEC
practices is out of scope for this document. security practices is out of scope for this document.
1.3.3. Sender policy does not scale 1.3.3. Sender policy does not scale
Sending systems are in some cases explicitly configured to use TLS Sending systems are in some cases explicitly configured to use TLS
for mail sent to selected peer domains. This requires sending MTAs for mail sent to selected peer domains. This requires sending MTAs
to be configured with appropriate subject names or certificate to be configured with appropriate subject names or certificate
content digests to expect in the presented server certificates. content digests to expect in the presented server certificates.
Because of the heavy administrative burden, such statically Because of the heavy administrative burden, such statically
configured SMTP secure channels are used rarely (generally only configured SMTP secure channels are used rarely (generally only
between domains that make bilateral arrangements with their business between domains that make bilateral arrangements with their business
partners). Internet email, on the other hand, requires regularly partners). Internet email, on the other hand, requires regularly
contacting new domains for which security configurations cannot be contacting new domains for which security configurations cannot be
established in advance. established in advance.
skipping to change at page 8, line 31 skipping to change at page 8, line 44
signed or issued by a private CA. signed or issued by a private CA.
1.3.4. Too many certification authorities 1.3.4. Too many certification authorities
Even if it were generally possible to determine a secure server name, Even if it were generally possible to determine a secure server name,
the SMTP client would still need to verify that the server's the SMTP client would still need to verify that the server's
certificate chain is issued by a trusted Certification Authority (a certificate chain is issued by a trusted Certification Authority (a
trust anchor). MTAs are not interactive applications where a human trust anchor). MTAs are not interactive applications where a human
operator can make a decision (wisely or otherwise) to selectively operator can make a decision (wisely or otherwise) to selectively
disable TLS security policy when certificate chain verification disable TLS security policy when certificate chain verification
fails. With no user to "click OK", the MTAs list of public CA trust fails. With no user to "click OK", the MTA's list of public CA trust
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.
skipping to change at page 9, line 4 skipping to change at page 9, line 16
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. Identifying applicable TLSA records 2. Identifying applicable TLSA records
2.1. DNS considerations 2.1. DNS considerations
2.1.1. DNS errors, bogus and indeterminate responses 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.2. 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
[RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
[RFC4035] the meaning of the "indeterminate" security status is: [RFC4035] the meaning of the "indeterminate" security status is:
skipping to change at page 9, line 29 skipping to change at page 9, line 42
the necessary DNSSEC RRs. This can occur when the security-aware the necessary DNSSEC RRs. This can occur when the security-aware
resolver is not able to contact security-aware name servers for resolver is not able to contact security-aware name servers for
the relevant zones. the relevant zones.
Note, the "indeterminate" security status has a conflicting Note, the "indeterminate" security status has a conflicting
definition in section 5 of [RFC4033]. definition in section 5 of [RFC4033].
There is no trust anchor that would indicate that a specific There is no trust anchor that would indicate that a specific
portion of the tree is secure. portion of the tree is secure.
To avoid further confusion, the adjective "anchorless" will be used
below to refer to domains or RRsets that are "indeterminate" in the
[RFC4033] sense, and the term "indeterminate" will be used
exclusively in the sense of [RFC4035].
SMTP clients following this specification SHOULD NOT distinguish SMTP clients following this specification SHOULD NOT distinguish
between "insecure" and "indeterminate" in the [RFC4033] sense. Both between "insecure" and "anchorless" DNS responses. Both "insecure"
"insecure" and RFC4033 "indeterminate" are handled identically: in and "anchorless" RRsets MUST be handled identically: in either case
either case unvalidated data for the query domain is all that is and unvalidated data for the query domain is all that is and can be
can be available, and authentication using the data is impossible. available, and authentication using the data is impossible. In what
In what follows, when we say "insecure", we include also DNS results follows, the term "insecure" will also includes the case of
for domains that lie in a portion of the DNS tree for which there is "anchorless" domains that lie in a portion of the DNS tree for which
no applicable trust anchor. With the DNS root zone signed, we expect there is no applicable trust anchor. With the DNS root zone signed,
that validating resolvers used by Internet-facing MTAs will be we expect that validating resolvers used by Internet-facing MTAs will
configured with trust anchor data for the root zone. Therefore, be configured with trust anchor data for the root zone, and that
RFC4033-style "indeterminate" domains should be rare in practice. therefore "anchorless" domains should be rare in practice.
From here on, when we say "indeterminate", it is exclusively in the
sense of [RFC4035].
As noted in section 4.3 of [RFC4035], a security-aware DNS resolver As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
MUST be able to determine whether a given non-error DNS response is MUST be able to determine whether a given non-error DNS response is
"secure", "insecure", "bogus" or "indeterminate". It is expected "secure", "insecure", "bogus" or "indeterminate". It is expected
that most security-aware stub resolvers will not signal an that most security-aware stub resolvers will not signal an
"indeterminate" security status in the RFC4035-sense to the "indeterminate" security status (in the sense of RFC4035) to the
application, and will signal a "bogus" or error result instead. If a application, and will signal a "bogus" or error result instead. If a
resolver does signal an RFC4035 "indeterminate" security status, this resolver does signal an RFC4035 "indeterminate" security status, this
MUST be treated by the SMTP client as though a "bogus" or error MUST be treated by the SMTP client as though a "bogus" or error
result had been returned. result had been returned.
An MTA making use of a non-validating security-aware stub resolver An MTA making use of a non-validating security-aware stub resolver
MAY use the stub resolver's ability, if available, to signal DNSSEC MAY use the stub resolver's ability, if available, to signal DNSSEC
validation status based on information the stub resolver has learned validation status based on information the stub resolver has learned
from an upstream validating recursive resolver. In accordance with from an upstream validating recursive resolver. Security-Oblivious
section 4.9.3 of [RFC4035]: stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
[RFC4035]:
... a security-aware stub resolver MUST NOT place any reliance on ... a security-aware stub resolver MUST NOT place any reliance on
signature validation allegedly performed on its behalf, except signature validation allegedly performed on its behalf, except
when the security-aware stub resolver obtained the data in question when the security-aware stub resolver obtained the data in question
from a trusted security-aware recursive name server via a secure from a trusted security-aware recursive name server via a secure
channel. channel.
To avoid much repetition in the text below, we will pause to explain To avoid much repetition in the text below, we will pause to explain
the handling of "bogus" or "indeterminate" DNSSEC query responses. the handling of "bogus" or "indeterminate" DNSSEC query responses.
These are not necessarily the result of a malicious actor; they can, These are not necessarily the result of a malicious actor; they can,
skipping to change at page 11, line 36 skipping to change at page 12, line 7
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 2.1.3. Stub resolver considerations
SMTP clients that employ opportunistic DANE TLS to secure connections
to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
A note about DNAME aliases: a query for a domain name whose ancestor 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, 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 along with a CNAME that maps the query domain to the corresponding
sub-domain of the target domain of the DNAME alias [RFC6672]. sub-domain of the target domain of the DNAME alias [RFC6672].
Therefore, whenever we speak of CNAME aliases, we implicitly allow Therefore, whenever we speak of CNAME aliases, we implicitly allow
for the possibility that the alias in question is the result of an for the possibility that the alias in question is the result of an
ancestor domain DNAME record. Consequently, no explicit support for ancestor domain DNAME record. Consequently, no explicit support for
DNAME records is needed in SMTP software, it is sufficient to process DNAME records is needed in SMTP software; it is sufficient to process
the resulting CNAME aliases. DNAME records only require special the resulting CNAME aliases. DNAME records only require special
processing in the validating stub-resolver library that checks the processing in the validating stub-resolver library that checks the
integrity of the combined DNAME + CNAME reply. When DNSSEC integrity of the combined DNAME + CNAME reply. When DNSSEC
validation is handled by a local caching resolver, rather than the 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 itself, even that part of the DNAME support logic is outside the
MTA. MTA.
When a stub resolver returns a response containing a CNAME alias that When a stub resolver returns a response containing a CNAME alias that
does not also contain the corresponding query results for the target 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 of the alias, the SMTP client will need to repeat the query at the
skipping to change at page 12, line 17 skipping to change at page 12, line 40
stage of CNAME expansion an error is detected, the lookup of the stage of CNAME expansion an error is detected, the lookup of the
original requested records MUST be considered to have failed. original requested records MUST be considered to have failed.
Whether a chain of CNAME records was returned in a single stub Whether a chain of CNAME records was returned in a single stub
resolver response or via explicit recursion by the SMTP client, if at resolver response or via explicit recursion by the SMTP client, if at
any stage of recursive expansion an "insecure" CNAME record is any stage of recursive expansion an "insecure" CNAME record is
encountered, then it and all subsequent results (in particular, the encountered, then it and all subsequent results (in particular, the
final result) MUST be considered "insecure" regardless of whether any final result) MUST be considered "insecure" regardless of whether any
earlier CNAME records leading to the "insecure" record were "secure". earlier CNAME records leading to the "insecure" record were "secure".
Note, a security-aware non-validating stub resolver may return to the Note that a security-aware non-validating stub resolver may return to
SMTP client an "insecure" reply received from a validating recursive the SMTP client an "insecure" reply received from a validating
resolver that contains a CNAME record along with additional answers recursive resolver that contains a CNAME record along with additional
recursively obtained starting at the target of the CNAME. In this answers recursively obtained starting at the target of the CNAME. In
all that one can say is that some record in the set of records this case, the only possible conclusion is that some record in the
returned is "insecure", but it is possible that the initial CNAME set of records returned is "insecure", and it is in fact possible
record and a subset of the subsequent records are "secure". 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 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 zone containing the initial CNAME record, it may need to issue a
separate query of type "CNAME" that returns only the initial CNAME separate query of type "CNAME" that returns only the initial CNAME
record. In particular in Section 2.2.2 when insecure A or AAAA 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 records are found for an SMTP server via a CNAME alias, it may be
necessary to perform an additional CNAME query to determine whether necessary to perform an additional CNAME query to determine whether
the DNS zone in which the alias is published is signed. 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
skipping to change at page 13, line 11 skipping to change at page 13, line 32
insecure or no results or an error signal. The term "usable" in this insecure or no results or an error signal. The term "usable" in this
context is in the sense of Section 4.1 of [RFC6698]. Specifically, context is in the sense of Section 4.1 of [RFC6698]. Specifically,
if the DNS lookup for a TLSA record returns: if the DNS lookup for a TLSA record returns:
A secure TLSA RRset with at least one usable record: A connection to A secure TLSA RRset with at least one usable record: A connection to
the MTA MUST be made using authenticated and encrypted TLS, using the MTA MUST be made using authenticated and encrypted TLS, using
the techniques discussed in the rest of this document. Failure to the techniques discussed in the rest of this document. Failure to
establish an authenticated TLS connection MUST result in falling establish an authenticated TLS connection MUST result in falling
back to the next SMTP server or delayed delivery. back to the next SMTP server or delayed delivery.
A Secure non-empty TLSA RRset where all the records are unusable: A A secure non-empty TLSA RRset where all the records are unusable: A
connection to the MTA MUST be made via TLS, but authentication is connection to the MTA MUST be made via TLS, but authentication is
not required. Failure to establish an encrypted TLS connection not required. Failure to establish an encrypted TLS connection
MUST result in falling back to the next SMTP server or delayed MUST result in falling back to the next SMTP server or delayed
delivery. delivery.
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
skipping to change at page 13, line 39 skipping to change at page 14, line 12
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.
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 an MTA chooses to connect to the network
address DANE TLSA does not apply for such a connection. address in the non-conformat MX record, 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
skipping to change at page 14, line 23 skipping to change at page 14, line 46
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 (up to the MTA's recursion limit) 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.1), DANE TLS need not apply, and delivery MAY proceed via Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
pre-DANE opportunistic TLS. That said, the protocol in this memo is pre-DANE opportunistic TLS. That said, the protocol in this memo is
an "opportunistic security" protocol, meaning that it strives to an "opportunistic security" protocol, meaning that it strives to
communicate with each peer as securely as possible, while maintaining communicate with each peer as securely as possible, while maintaining
broad interoperability. Therefore, the SMTP client MAY proceed to broad interoperability. Therefore, the SMTP client MAY proceed to
use DANE TLS (as described in Section 2.2.2 below) even with MX hosts use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
obtained via an "insecure" MX RRset. For example, when a hosting obtained via an "insecure" MX RRset. For example, when a hosting
provider has a signed DNS zone and publishes TLSA records for its provider has a signed DNS zone and publishes TLSA records for its
skipping to change at page 16, line 15 skipping to change at page 16, line 38
With the problem domains, TLSA queries will lead to DNS lookup errors With the problem domains, TLSA queries will lead to DNS lookup errors
and cause messages to be consistently delayed and ultimately returned and cause messages to be consistently delayed and ultimately returned
to the sender. We don't expect to find any "secure" TLSA records to the sender. We don't expect to find any "secure" TLSA records
associated with a TLSA base domain that lies in an unsigned DNS zone. associated 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 (up to the MTA's recursion limit).
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:
Not found: When the DNS queries for A and/or AAAA records yield Not found: When the DNS queries for A and/or AAAA records yield
neither a list of addresses nor a CNAME (or CNAME expansion is not neither a list of addresses nor a CNAME (or CNAME expansion is not
supported) the destination is unreachable. supported) the destination is unreachable.
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
skipping to change at page 17, line 31 skipping to change at page 18, line 4
query with the query type set to TLSA ([RFC6698] Section 7.1). query with the query type set to TLSA ([RFC6698] Section 7.1).
For SMTP, the destination TCP port is typically 25, but this may be For SMTP, the destination TCP port is typically 25, but this may be
different with custom routes specified by the MTA administrator in different with custom routes specified by the MTA administrator in
which case the SMTP client MUST use the appropriate number in the which case the SMTP client MUST use the appropriate number in the
"_<port>" prefix in place of "_25". If, for example, the candidate "_<port>" prefix in place of "_25". If, for example, the candidate
base domain is "mx.example.com", and the SMTP connection is to port base domain is "mx.example.com", and the SMTP connection is to port
25, the TLSA RRset is obtained via a DNSSEC query of the form: 25, the TLSA RRset is obtained via a DNSSEC query of the form:
_25._tcp.mx.example.com. IN TLSA ? _25._tcp.mx.example.com. IN TLSA ?
The query response may be a CNAME, or the actual TLSA RRset. If the The query response may be a CNAME, or the actual TLSA RRset. If the
response is a CNAME, the SMTP client (through the use of its response is a CNAME, the SMTP client (through the use of its
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 domain 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 MAY proceed via pre-DANE opportunistic TLS. SMTP clients delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
or even to skip SMTP servers that fail authentication, but MUST NOT or even to skip SMTP servers that fail authentication, but MUST NOT
misrepresent authentication success as either a secure connection to misrepresent authentication success as either a secure connection to
the SMTP server or as a secure delivery to the intended next-hop the SMTP server or as a secure delivery to the intended next-hop
skipping to change at page 18, line 11 skipping to change at page 18, line 32
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.
Note, shared end entity certificate associations expose the Note that shared end entity certificate associations expose the
publishing domain to substitution attacks, where an MITM attacker can publishing domain to substitution attacks, where an MITM attacker can
reroute traffic to a different server that shares the same end entity reroute traffic to a different server that shares the same end entity
certificate. Such shared end entity records SHOULD be avoided unless certificate. Such shared end entity TLSA records SHOULD be avoided
the servers in question are functionally equivalent (an active unless the servers in question are functionally equivalent or employ
attacker gains nothing by diverting client traffic from one such mutually incompatible protocols (an active attacker gains nothing by
server to another). diverting client traffic from one such server to another).
For example, given the DNSSEC validated records below: A better example, employing a shared trust anchor rather than shared
end-entity certificates, is illustrated by the DNSSEC validated
records below:
example.com. IN MX 0 mx1.example.com. example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com. example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com. _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com. _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c149a... tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
The SMTP servers mx1.example.com and mx2.example.com will be expected The SMTP servers mx1.example.com and mx2.example.com will be expected
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
skipping to change at page 19, line 21 skipping to change at page 19, line 43
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.
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 [RFC7218]. The
[I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is rest of the TLSA record is the "certificate association data field",
the "certificate association data field", which specifies the full or which specifies the full or digest value of a certificate or public
digest value of a certificate or public key. The parameters are: 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 four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
EE(3). There is an additional private-use value: PrivCert(255). DANE-EE(3). There is an additional private-use value:
All other values are reserved for use by future specifications. PrivCert(255). All other values are reserved for use by future
specifications.
The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: The selector field: Section 2.1.2 of [RFC6698] specifies two values:
Cert(0), SPKI(1). There is an additional private-use value: Cert(0) and SPKI(1). There is an additional private-use value:
PrivSel(255). All other values are reserved for use by future PrivSel(255). All other values are reserved for use by future
specifications. specifications.
The matching type field: Section 2.1.3 of [RFC6698] specifies 3 The matching type field: Section 2.1.3 of [RFC6698] specifies three
values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
private-use value: PrivMatch(255). All other values are reserved additional private-use value: PrivMatch(255). All other values
for use by future specifications. are reserved for use by future specifications.
We may think of TLSA Certificate Usage values 0 through 3 as a We may think of TLSA Certificate Usage values 0 through 3 as a
combination of two one-bit flags. The low bit chooses between trust combination of two one-bit flags. The low bit chooses between trust
anchor (TA) and end entity (EE) certificates. The high bit chooses anchor (TA) and end entity (EE) certificates. The high bit chooses
between public PKI issued and domain-issued certificates. between public PKI issued and domain-issued certificates.
The selector field specifies whether the TLSA RR matches the whole The selector field specifies whether the TLSA RR matches the whole
certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
algorithm id, any parameters and the public key data. certificate's algorithm id, any parameters and the public key data.
The matching type field specifies how the TLSA RR Certificate The matching type field specifies how the TLSA RR Certificate
Association Data field is to be compared with the certificate or Association Data field is to be compared with the certificate or
public key. A value of Full(0) means an exact match: the full DER public key. A value of Full(0) means an exact match: the full DER
encoding of the certificate or public key is given in the TLSA RR. A encoding of the certificate or public key is given in the TLSA RR. A
value of SHA2-256(1) means that the association data matches the value of SHA2-256(1) means that the association data matches the
SHA2-256 digest of the certificate or public key, and likewise SHA2-256 digest of the certificate or public key, and likewise
SHA2-512(2) means a SHA2-512 digest is used. SHA2-512(2) means a SHA2-512 digest is used.
Since opportunistic DANE TLS will be used by non-interactive MTAs, Since opportunistic DANE TLS will be used by non-interactive MTAs,
skipping to change at page 21, line 46 skipping to change at page 22, line 33
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:
example.com. IN MX 0 mx1.example.com. example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com. example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com. _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com. _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14.... tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
With usage DANE-TA(2) the server certificates will need to have names With usage DANE-TA(2) the server certificates will need to have names
that match one of the client's reference identifiers (see [RFC6125]). that match one of the client's reference identifiers (see [RFC6125]).
The server MAY employ SNI to select the appropriate certificate to The server MAY employ SNI to select the appropriate certificate to
present to the client. present to the client.
SMTP servers that rely on certificate usage DANE-TA(2) TLSA records SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
for TLS authentication MUST include the TA certificate as part of the for TLS authentication MUST include the TA certificate as part of the
certificate chain presented in the TLS handshake server certificate certificate chain presented in the TLS handshake server certificate
message even when it is a self-signed root certificate. At this message even when it is a self-signed root certificate. At this
skipping to change at page 23, line 36 skipping to change at page 24, line 19
3.2. Certificate matching 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 MUST use TLSA records to authenticate the SMTP server. client MUST use TLSA records to authenticate the SMTP server.
Messages MUST NOT be delivered via the SMTP server if authentication Messages MUST NOT be delivered via the SMTP server if authentication
fails, otherwise the SMTP client is vulnerable to MITM attacks. fails, otherwise the SMTP client is vulnerable to MITM attacks.
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 3.1.1 above. certificate usage DANE-EE(3); see Section 3.1.1 above.
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
skipping to change at page 30, line 49 skipping to change at page 31, line 31
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.
9.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 5 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".
10. 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 security ([I-D.dukhovni-opportunistic-security]) for
that sign their MX records and publish signed TLSA records for their SMTP. For destination domains that sign their MX records and publish
MX hostnames, this protocol allows sending MTAs to securely discover signed TLSA records for their MX hostnames, this protocol allows
both the availability of TLS and how to authenticate the destination. sending MTAs to securely discover 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
best possible path for securing SMTP. This protocol coexists and best possible path for securing SMTP. This protocol coexists and
interoperates with the existing insecure Internet email backbone. interoperates with the existing insecure Internet email backbone.
The protocol does not preclude existing non-opportunistic SMTP TLS The protocol does not preclude existing non-opportunistic SMTP TLS
security arrangements, which can continue to be used as before via security arrangements, which can continue to be used as before via
manual configuration with negotiated out-of-band key and TLS manual configuration with negotiated out-of-band key and TLS
skipping to change at page 33, line 27 skipping to change at page 34, line 21
[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.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, April 2014.
[X.690] International Telecommunications Union, "Recommendation
ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", July 2002.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dane-registry-acronyms] [I-D.dukhovni-opportunistic-security]
Gudmundsson, O., "Adding acronyms to simplify DANE Dukhovni, V., "Opportunistic Security: some protection
conversations", draft-ietf-dane-registry-acronyms-01 (work most of the time", draft-dukhovni-opportunistic-
in progress), October 2013. security-01 (work in progress), July 2014.
[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.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009. 2009.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
 End of changes. 54 change blocks. 
138 lines changed or deleted 166 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/