< draft-ietf-dane-smtp-with-dane-05.txt   draft-ietf-dane-smtp-with-dane-06.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track W. Hardaker Intended status: Standards Track W. Hardaker
Expires: August 13, 2014 Parsons Expires: August 16, 2014 Parsons
February 9, 2014 February 12, 2014
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-05 draft-ietf-dane-smtp-with-dane-06
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 August 13, 2014. This Internet-Draft will expire on August 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 45 skipping to change at page 4, line 45
MUA: Message User Agent ([RFC5598], Section 4.2.1). MUA: Message User Agent ([RFC5598], Section 4.2.1).
RR: A DNS Resource Record RR: A DNS Resource Record
RRset: A set of DNS Resource Records for a particular class, domain RRset: A set of DNS Resource Records for a particular class, domain
and record type. and record type.
1.2. Background 1.2. Background
The Domain Name System Security Extensions (DNSSEC) adds data origin The Domain Name System Security Extensions (DNSSEC) add data origin
authentication, data integrity and data non-existence proofs to the authentication, data integrity and data non-existence proofs to the
Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034] Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
and [RFC4035]. 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) PKI suffers from an the existing public Certificate Authority (CA) PKI suffers from an
over-abundance of trusted certificate authorities capable of issuing over-abundance of trusted certificate authorities capable of issuing
certificates for any domain of their choice. DANE leverages the certificates for any domain of their choice. DANE leverages the
DNSSEC infrastructure to publish trusted public keys and certificates DNSSEC infrastructure to publish trusted public keys and certificates
for use with the Transport Layer Security (TLS) [RFC5246] protocol for use with the Transport Layer Security (TLS) [RFC5246] protocol
skipping to change at page 5, line 25 skipping to change at page 5, line 25
integrity protection to guard against man-in-the-middle (MITM) integrity protection to guard against man-in-the-middle (MITM)
attacks. attacks.
1.3. SMTP channel security 1.3. SMTP channel security
With HTTPS, Transport Layer Security (TLS) employs X.509 certificates With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
issued by one of the many Certificate Authorities (CAs) bundled with issued by one of the many Certificate Authorities (CAs) bundled with
popular web browsers to allow users to authenticate their "secure" popular web browsers to allow users to authenticate their "secure"
websites. Before we specify a new DANE TLS security model for SMTP, websites. Before we specify a new DANE TLS security model for SMTP,
we will explain why a new security model is needed. In the process, we will explain why a new security model is needed. In the process,
we will explain why the familiar HTTPS security model is is we will explain why the familiar HTTPS security model is inadequate
inadequate to protect inter-domain SMTP traffic. to protect inter-domain SMTP traffic.
The subsections below outline four key problems with applying The subsections below outline four key problems with applying
traditional PKI to SMTP that are addressed by this specification. traditional PKI to SMTP that are addressed by this specification.
Since SMTP channel security policy is not explicitly specified in Since SMTP channel security policy is not explicitly specified in
either the recipient address or the MX record, a new signaling either the recipient address or the MX record, a new signaling
mechanism is required to indicate when channel security is possible mechanism is required to indicate when channel security is possible
and should be used. The publication of TLSA records allows server and should be used. The publication of TLSA records allows server
operators to securely signal to SMTP clients that TLS is available operators to securely signal to SMTP clients that TLS is available
and should be used. DANE TLSA makes it possible to simultaneously and should be used. DANE TLSA makes it possible to simultaneously
discover which destination domains support secure delivery via TLS discover which destination domains support secure delivery via TLS
and how to verify the authenticity of the associated SMTP services and how to verify the authenticity of the associated SMTP services,
providing a path forward to ubiquitous SMTP channel security. providing a path forward to ubiquitous SMTP channel security.
1.3.1. STARTTLS downgrade attack 1.3.1. STARTTLS downgrade attack
The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
protocol in a multi-hop store & forward email delivery process. SMTP protocol in a multi-hop store & forward email delivery process. SMTP
envelope recipient addresses are not transport addresses and are envelope recipient addresses are not transport addresses and are
security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and
its corresponding secured version, HTTPS, there is no URI scheme for its corresponding secured version, HTTPS, there is no URI scheme for
email addresses to designate whether communication with the SMTP email addresses to designate whether communication with the SMTP
server should be conducted via a cleartext or a TLS-encrypted server should be conducted via a cleartext or a TLS-encrypted
channel. Indeed no such URI scheme could work well with SMTP since channel. Indeed, no such URI scheme could work well with SMTP since
TLS encryption of SMTP protects email traffic on a hop-by-hop basis TLS encryption of SMTP protects email traffic on a hop-by-hop basis
while email addresses could only express end-to-end policy. 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 a man in the middle attacker. Thus pre-DANE SMTP TLS suppressed by a man in the middle attacker. Thus pre-DANE SMTP TLS
security can be subverted by simply downgrading a connection to security can be subverted by simply downgrading a connection to
cleartext. No TLS security feature, such as the use of PKIX, can cleartext. No TLS security feature, such as the use of PKIX, can
prevent this. The attacker can simply bypass TLS. prevent this. The attacker can simply bypass TLS.
1.3.2. Insecure server name without DNSSEC 1.3.2. Insecure server name without DNSSEC
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 man in the middle (MITM) attacks A PKIX TLS client is vulnerable to man in the middle (MITM) attacks
unless it verifies that the server's certificate binds its public key unless it verifies that the server's certificate binds its public key
to its name. However, with SMTP server names are obtained indirectly to its name. However, with SMTP server names are obtained indirectly
via MX records. Without DNSSEC, the MX lookup is vulnerable MITM and via MX records. Without DNSSEC, the MX lookup is vulnerable to MITM
DNS cache poisoning attacks. Active attackers can forge DNS replies and DNS cache poisoning attacks. Active attackers can forge DNS
with fake MX records, and can redirect email to servers with names of replies with fake MX records and can redirect email to servers with
their choice. Therefore, secure verification of SMTP TLS names of their choice. Therefore, secure verification of SMTP TLS
certificates is not possible without DNSSEC. certificates is not possible without DNSSEC.
One might try to harden the use of TLS with SMTP against DNS attacks One might try to harden the use of TLS with SMTP against DNS attacks
by requiring each SMTP server to possess a trusted certificate for by requiring each SMTP server to possess a trusted certificate for
the envelope recipient domain rather than the MX hostname. the envelope recipient domain rather than the MX hostname.
Unfortunately, this is impractical, as email for many domains is Unfortunately, this is impractical, as email for many domains is
handled by third parties that are not in a position to obtain handled by third parties that are not in a position to obtain
certificates for all the domains they serve. Deployment of the certificates for all the domains they serve. Deployment of the
Server Name Indication (SNI) extension to TLS (see [RFC6066] Server Name Indication (SNI) extension to TLS (see [RFC6066]
Section 3) is no panacea, since SNI key management is operationally Section 3) is no panacea, since SNI key management is operationally
skipping to change at page 7, line 46 skipping to change at page 7, line 46
1.3.4. Too many certificate authorities 1.3.4. Too many certificate 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 certificate authority (a certificate chain is issued by a trusted certificate 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 MTAs 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 sites to sites employing an unknown certificate authority. mail addressed to sites that employ unknown certificate authorities.
On the other hand, each trusted CA can issue certificates for any On the other hand, each trusted CA can issue certificates for any
domain. If even one of the configured CAs is compromised or operated domain. If even one of the configured CAs is compromised or operated
by an adversary, it can subvert TLS security for all destinations. by an adversary, it can subvert TLS security for all destinations.
Any set of CAs is simultaneously both overly inclusive and not Any set of CAs is simultaneously both overly inclusive and not
inclusive enough. inclusive enough.
2. Hardening (pre-DANE) Opportunistic TLS 2. Hardening (pre-DANE) Opportunistic TLS
Neither email addresses nor MX hostnames (or submission SRV records) Neither email addresses nor MX hostnames (or submission SRV records)
skipping to change at page 9, line 29 skipping to change at page 9, line 29
that validating resolvers used by Internet-facing MTAs will be that validating resolvers used by Internet-facing MTAs will be
configured with trust anchor data for the root zone. Therefore, configured with trust anchor data for the root zone. Therefore,
RFC4033-style "indeterminate" domains should be rare in practice. RFC4033-style "indeterminate" domains should be rare in practice.
From here on, when we say "indeterminate", it is exclusively in the From here on, when we say "indeterminate", it is exclusively in the
sense of [RFC4035]. 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 the RFC4035-sense to the application, "indeterminate" security status in the RFC4035-sense to the
and will signal a "bogus" or error result instead. If a resolver application, and will signal a "bogus" or error result instead. If a
does signal an RFC4035 "indeterminate" security status, this MUST be resolver does signal an RFC4035 "indeterminate" security status, this
treated by the SMTP client as though a "bogus" or error result had MUST be treated by the SMTP client as though a "bogus" or error
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. In accordance with
section 4.9.3 of [RFC4035]: 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
skipping to change at page 16, line 19 skipping to change at page 16, line 19
2.2.3. TLSA record lookup 2.2.3. TLSA record lookup
Each candidate TLSA base domain (the original or fully CNAME-expanded Each candidate TLSA base domain (the original or fully CNAME-expanded
name of a non-MX destination or a particular MX hostname of an MX name of a non-MX destination or a particular MX hostname of an MX
destination) is in turn prefixed with service labels of the form destination) is in turn prefixed with service labels of the form
"_<port>._tcp". The resulting domain name is used to issue a DNSSEC "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
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. The different with custom routes specified by the MTA administrator in
SMTP client MUST use the appropriate number in the "_<port>" prefix which case the SMTP client MUST use the appropriate number in the
in place of "_25". If, for example, the candidate base domain is "_<port>" prefix in place of "_25". If, for example, the candidate
"mail.example.com", and the SMTP connection is to port 25, the TLSA base domain is "mail.example.com", and the SMTP connection is to port
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.mail.example.com. IN TLSA ? _25._tcp.mail.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 is tried instead.
skipping to change at page 19, line 40 skipping to change at page 19, line 40
key, one matching the currently deployed key and the other matching key, one matching the currently deployed key and the other matching
the new key scheduled to replace it. Once sufficient time has the new key scheduled to replace it. Once sufficient time has
elapsed for all DNS caches to expire the previous TLSA RRset and elapsed for all DNS caches to expire the previous TLSA RRset and
related signature RRsets, the server may be reconfigured to use the related signature RRsets, the server may be reconfigured to use the
new private key and associated public key certificate. Once the new private key and associated public key certificate. Once the
server is using the new key, the TLSA RR that matches the retired key server is using the new key, the TLSA RR that matches the retired key
can be removed from DNS, leaving only the RR that matches the new can be removed from DNS, leaving only the RR that matches the new
key. key.
TLSA records published for SMTP servers SHOULD, in most cases, be TLSA records published for SMTP servers SHOULD, in most cases, be
"DANE-EE(3) DANE(SPKI) SHA2-256(1)" records. Since all DANE "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
implementations are required to support SHA2-256, this record works implementations are required to support SHA2-256, this record works
for all clients and need not change across certificate renewals with for all clients and need not change across certificate renewals with
the same key. the same key.
2.3.1.2. Certificate usage DANE-TA(2) 2.3.1.2. Certificate usage DANE-TA(2)
Some domains may prefer to avoid the operational complexity of Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing Certificate Authority to create certificates employs a common issuing Certificate Authority to create certificates
for multiple TLS services, it may be simpler to publish the issuing for multiple TLS services, it may be simpler to publish the issuing
skipping to change at page 25, line 43 skipping to change at page 25, line 43
4. Operational Considerations 4. Operational Considerations
4.1. Client Operational Considerations 4.1. Client Operational Considerations
SMTP clients may deploy opportunistic DANE TLS incrementally by SMTP clients may deploy opportunistic DANE TLS incrementally by
enabling it only for selected sites, or may occasionally need to enabling it only for selected sites, or may occasionally need to
disable opportunistic DANE TLS for peers that fail to interoperate disable opportunistic DANE TLS for peers that fail to interoperate
due to misconfiguration or software defects on either end. Unless due to misconfiguration or software defects on either end. Unless
local policy specifies that opportunistic DANE TLS is not to be used local policy specifies that opportunistic DANE TLS is not to be used
for a particular destination, client MUST NOT deliver mail via a for a particular destination, an SMTP client MUST NOT deliver mail
server whose certificate chain fails to match at least one TLSA via a server whose certificate chain fails to match at least one TLSA
record when usable TLSA records are available. record when usable TLSA records are found for that server.
4.2. Publisher Operational Considerations 4.2. Publisher Operational Considerations
SMTP servers that publish certificate usage DANE-TA(2) associations SMTP servers that publish certificate usage DANE-TA(2) associations
MUST include the TA certificate in their TLS server certificate MUST include the TA certificate in their TLS server certificate
chain, even when that TA certificate is a self-signed root chain, even when that TA certificate is a self-signed root
certificate. certificate.
TLSA Publishers must follow the digest agility guidelines in TLSA Publishers must follow the digest agility guidelines in
Section 2.3.3 and must make sure that all objects published in digest Section 2.3.3 and must make sure that all objects published in digest
 End of changes. 14 change blocks. 
29 lines changed or deleted 29 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/