< draft-ietf-dane-smtp-with-dane-01.txt   draft-ietf-dane-smtp-with-dane-02.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Experimental W.H. Hardaker Intended status: Experimental W. Hardaker
Expires: April 24, 2014 Parsons Expires: April 24, 2014 Parsons
October 21, 2013 October 21, 2013
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-01 draft-ietf-dane-smtp-with-dane-02
Abstract Abstract
This memo describes a protocol for opportunistic TLS security based This memo describes a protocol for opportunistic TLS security based
on the DANE TLSA DNS record. The protocol is downgrade resistant on the DANE TLSA DNS record. The protocol is downgrade resistant
when the SMTP client supports DANE TLSA and the server domain when the SMTP client supports DANE TLSA and the server domain
publishes TLSA records for its MX hosts. This enables an incremental publishes TLSA records for its MX hosts. This enables an incremental
transition of the Internet email backbone (MTA to MTA SMTP traffic) transition of the Internet email backbone (MTA to MTA SMTP traffic)
to TLS encrypted and authenticated delivery. to TLS encrypted and authenticated delivery.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3 1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5 2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5
2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5 2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Non-MX destinations . . . . . . . . . . . . . . . . . 6 2.1.1. Non-MX destinations . . . . . . . . . . . . . . . . . 6
2.1.2. MX resolution . . . . . . . . . . . . . . . . . . . . 7 2.1.2. MX resolution . . . . . . . . . . . . . . . . . . . . 7
2.1.3. TLSA record lookup . . . . . . . . . . . . . . . . . 9 2.1.3. TLSA record lookup . . . . . . . . . . . . . . . . . 9
2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 10 2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 10
2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 11 2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 10
2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12 2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12
3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 14 3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 14
4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 15 4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Lacking verified DNS and "Server Name Indication" (SNI), there has Lacking verified DNS and "Server Name Indication" (SNI), there has
historically been no scalable way for SMTP server operators to deploy historically been no scalable way for SMTP server operators to deploy
certificates with a client-trusted subject name. It's only with the certificates with a client-trusted subject name. It's only with the
deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX
becomes possible between parties that have not already established an becomes possible between parties that have not already established an
identity convention out-of-band. identity convention out-of-band.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
will also be authenticated and thus immune to eavesdropping or will also be authenticated and thus immune to eavesdropping or
tampering (unless DNSSEC itself is compromised). tampering (unless DNSSEC itself is compromised).
Typically, the next-hop destination will be the domain part of the Typically, the next-hop destination will be the domain part of the
recipient address, which is then subject to MX resolution. The next- recipient address, which is then subject to MX resolution. The next-
hop destination may also be configured by the MTA administrator to be hop destination may also be configured by the MTA administrator to be
a next-hop destination host (explicitly exempt from MX resolution), a next-hop destination host (explicitly exempt from MX resolution),
or a next-hop destination domain (subject to MX resolution) which or a next-hop destination domain (subject to MX resolution) which
takes the place of the domain part of the recipient address. takes the place of the domain part of the recipient address.
The protocol in this memo is "opportunistic". Absent "secure" The protocol in this memo is "opportunistic"; it should be used
(DNSSEC validated) TLSA records, mail delivery should generally fall whenever possible but communication should continue when it is not
back to pre-DANE opportunistic TLS. The SMTP client may be available. Absent "secure" (DNSSEC validated) TLSA records, mail
configured to require DANE verified delivery for some or all delivery should fall back to pre-DANE opportunistic TLS. The SMTP
destinations, in which case absent "secure" TLSA records delivery client MAY be configured to require DANE verified delivery for some
will be deferred. or all destinations, in which case mail delivery will be deferred
when "secure" TLSA records are absent.
Below we explain how to determine for a given next-hop destination Below we explain how to determine for a given next-hop destination
the associated SMTP servers, the TLSA base domain and TLSA records. the associated SMTP servers, the TLSA base domain and TLSA records.
2.1.1. Non-MX destinations 2.1.1. Non-MX destinations
As mentioned above, the next-hop destination domain may in some cases As mentioned above, the next-hop destination domain may in some cases
be exempt from MX lookups. In addition, MX lookups for the next-hop be exempt from MX lookups. In addition, MX lookups for the next-hop
domain may yield no results. In either case, the destination server domain may yield no results. In either case, the destination server
for such a domain is determined by looking up the corresponding A or for such a domain is determined by looking up the corresponding A or
AAAA records. AAAA records.
When "bogus" records are encountered either during CNAME expansion, When "bogus" records are encountered either during CNAME expansion,
or when retrieving the associated TLSA RRset, the SMTP client MUST or when retrieving the associated TLSA RRset, the SMTP client MUST
proceed as if the next-hop domain were unreachable. Delivery should proceed as if the next-hop domain were unreachable. Delivery should
either be deferred or may be attempted via any fallback next-hop either be deferred or may be attempted via any fallback next-hop
(which may also employ opportunistic DANE TLS) configured by the SMTP configured by the SMTP client administrator. Fallback next-hop
client administrator. Proceeding with the original next-hop despite destinations may also employ opportunistic DANE TLS. Proceeding with
"bogus" DNS responses would destroy protection against downgrade the original next-hop despite "bogus" DNS responses would destroy
attacks. protection against downgrade attacks.
Following [RFC5321] Section 5.1, if the A or AAAA lookup of the Following [RFC5321] Section 5.1, if the A or AAAA lookup of the
initial name yields a CNAME, we replace it with the resulting name as initial name yields a CNAME, we replace it with the resulting name as
if it were the initial name and perform a lookup again using the new if it were the initial name and perform a lookup again using the new
name. This replacement is performed recursively, although MTAs name. This replacement is performed recursively, although MTAs
typically support only limited recursion in CNAME expansion. We typically support only limited recursion in CNAME expansion. We
consider the following cases: consider the following cases:
Non-CNAME: The next-hop destination domain is not a CNAME alias. Non-CNAME: The next-hop destination domain is not a CNAME alias.
The lookup key for the DNSSEC validated TLSA records is obtained The lookup key for the DNSSEC validated TLSA records is obtained
 End of changes. 7 change blocks. 
15 lines changed or deleted 16 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/