< draft-ietf-dane-smtp-with-dane-14.txt		draft-ietf-dane-smtp-with-dane-15.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: August 24, 2015 Parsons		Expires: September 5, 2015 Parsons
	February 20, 2015		March 4, 2015
	SMTP security via opportunistic DANE TLS		SMTP security via opportunistic DANE TLS
	draft-ietf-dane-smtp-with-dane-14		draft-ietf-dane-smtp-with-dane-15
	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 24, 2015.		This Internet-Draft will expire on September 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 12 ¶		skipping to change at page 2, line 12 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . 6		1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
	1.3.3. Sender policy does not scale . . . . . . . . . . . . 7		1.3.3. Sender policy does not scale . . . . . . . . . . . . 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 . . . . . . . . . . . . . 8
	2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8		2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8
	2.1.1. DNS errors, bogus and indeterminate responses . . . . 8		2.1.1. DNS errors, bogus and indeterminate responses . . . . 8
	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 . . . . . . . . . . . . 11
	2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13		2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12
	2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14		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) . . . . . . . . . . . . 21		3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20
	3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21		3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21
	3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23		3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22
	3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23		3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23
	3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23		3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23
	3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24		3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
	3.2.3. Reference identifier matching . . . . . . . . . . . . 25		3.2.3. Reference identifier matching . . . . . . . . . . . . 25
	4. Server key management . . . . . . . . . . . . . . . . . . . . 25		4. Server key management . . . . . . . . . . . . . . . . . . . . 25
	5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26		5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
	6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 26		6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 26
	7. Note on DANE for Message User Agents . . . . . . . . . . . . 27		7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
	8. Interoperability considerations . . . . . . . . . . . . . . . 27		8. Interoperability considerations . . . . . . . . . . . . . . . 27
	8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 27		8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 27
	8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28		8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
	9. Operational Considerations . . . . . . . . . . . . . . . . . 28		9. Operational Considerations . . . . . . . . . . . . . . . . . 28
	9.1. Client Operational Considerations . . . . . . . . . . . . 28		9.1. Client Operational Considerations . . . . . . . . . . . . 29
	9.2. Publisher Operational Considerations . . . . . . . . . . 29		9.2. Publisher Operational Considerations . . . . . . . . . . 29
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 29		10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30		11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	13.1. Normative References . . . . . . . . . . . . . . . . . . 31		13.1. Normative References . . . . . . . . . . . . . . . . . . 31
	13.2. Informative References . . . . . . . . . . . . . . . . . 32		13.2. Informative References . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	This memo specifies a new connection security model for Message		This memo specifies a new connection security model for Message
	Transfer Agents (MTAs). This model is motivated by key features of		Transfer Agents (MTAs). This model is motivated by key features of
	inter-domain SMTP delivery, in particular the fact that the		inter-domain SMTP delivery, in particular the fact that the
	destination server is selected indirectly via DNS Mail Exchange (MX)		destination server is selected indirectly via DNS Mail Exchange (MX)
	records and that 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
	skipping to change at page 23, line 9 ¶		skipping to change at page 22, line 49 ¶
	While a selector of SPKI(1) may also be employed, the resulting TLSA		While a selector of SPKI(1) may also be employed, the resulting TLSA
	record will not specify the full trust anchor certificate content,		record will not specify the full trust anchor certificate content,
	and elements of the trust anchor certificate other than the public		and elements of the trust anchor certificate other than the public
	key become mutable. This may, for example, allow a subsidiary CA to		key become mutable. This may, for example, allow a subsidiary CA to
	issue a chain that violates the trust anchor's path length or name		issue a chain that violates the trust anchor's path length or name
	constraints.		constraints.
	3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)		3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
	As noted in the introduction, SMTP clients cannot, without relying on		Note, this section applies to MTA-to-MTA SMTP on port 25. That is,
	DNSSEC for secure MX records and DANE for STARTTLS support signaling,		to servers that are the SMTP servers for one or more destination
	perform server identity verification or prevent STARTTLS downgrade		domains. Other uses of SMTP, such as in MUA-to-MSA submission on
	attacks. The use of PKIX CAs offers no added security since an		ports 587 or 465 are out of scope for this document. Where those
	attacker capable of compromising DNSSEC is free to replace any PKIX-		other uses also employ TLS opportunistically and/or depend on DNSSEC
	TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient		as a result of DNS-based discovery of service location, the relevant
	non-PKIX certificate usage.		specifications should, as appropriate, arrive at similar conclusions.
	SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-		As noted in Section 1.3.1 and Section 1.3.2, sending MTAs cannot,
	TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be		without relying on DNSSEC for secure MX records and DANE for STARTTLS
	configured with a suitably complete set of trusted public CAs.		support signaling, perform server identity verification or prevent
	Lacking a complete set of public CAs, clients would not be able to		STARTTLS downgrade attacks. The use of PKIX CAs offers no added
	verify the certificates of SMTP servers whose issuing root CAs are		security since an attacker capable of compromising DNSSEC is free to
	not trusted by the client.		replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records
			bearing any convenient non-PKIX certificate usage. Finally, as
			explained in Section 1.3.4, there is no list of trusted CAs agreed by
			all MTAs, and no user to "click OK" when a server's CA is not trusted
			by a client.
			Therefore, TLSA records for the port 25 SMTP service used by client
			MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or
			PKIX-EE(1). SMTP client MTAs cannot be expected to be configured
			with a suitably complete set of trusted public CAs. Lacking a
			complete set of public CAs, MTA clients would not be able to verify
			the certificates of SMTP servers whose issuing root CAs are not
			trusted by the client.
	Opportunistic DANE TLS needs to interoperate without bilateral		Opportunistic DANE TLS needs to interoperate without bilateral
	coordination of security settings between client and server systems.		coordination of security settings between client and server systems.
	Therefore, parameter choices that are fragile in the absence of		Therefore, parameter choices that are fragile in the absence of
	bilateral coordination are unsupported. Nothing is lost since the		bilateral coordination are unsupported. Nothing is lost since the
	PKIX certificate usages cannot aid SMTP TLS security, they can only		PKIX certificate usages cannot aid SMTP TLS security, they can only
	impede SMTP TLS interoperability.		impede SMTP TLS interoperability.
	SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)		SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
	or PKIX-EE(1) is undefined. SMTP clients should generally treat such		or PKIX-EE(1) is undefined. SMTP clients should generally treat such
	skipping to change at page 29, line 29 ¶		skipping to change at page 29, line 33 ¶
	failure to achieve the requisite security level is logged as a		failure to achieve the requisite security level is logged as a
	warning and delivery proceeds at a reduced security level. Unless		warning and delivery proceeds at a reduced security level. Unless
	local policy specifies "audit only" or that opportunistic DANE TLS is		local policy specifies "audit only" or that opportunistic DANE TLS is
	not to be used for a particular destination, an SMTP client MUST NOT		not to be used for a particular destination, an SMTP client MUST NOT
	deliver mail via a server whose certificate chain fails to match at		deliver mail via a server whose certificate chain fails to match at
	least one TLSA record when usable TLSA records are found for that		least one TLSA record when usable TLSA records are found for that
	server.		server.
	9.2. Publisher Operational Considerations		9.2. Publisher Operational Considerations
			As explained in Section 3.1.3 server operators SHOULD NOT publish
			TLSA records for their MTAs (port 25 SMTP) with certificate usages
			PKIX-TA(0) or PKIX-EE(1).
			Some MTAs enable STARTTLS selectively. For example they might only
			support STARTTLS with clients that have previously demonstrated
			"proper MTA behavior", for example by retrying the delivery of
			deferred messages (greylisting). If such an MTA publishes DANE TLSA
			records, sending MTAs that implement this specification will not
			attempt the initial cleartext SMTP transaction needed to establish
			the "proper MTA behavior", because they cannot establish the required
			channel security. Server operators MUST NOT implement selective
			STARTTLS if they also want to support DANE TLSA.
	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. With some SMTP server software it is not possible to
			include root CA certificates in the server chain. Such servers need
			to either publish DANE-TA(2) records for an intermediate certificate
			or to use DANE-EE(3).
	TLSA Publishers MUST follow the guidelines in the "TLSA Publisher		TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
	Requirements" section of [I-D.ietf-dane-ops].		Requirements" section of [I-D.ietf-dane-ops].
	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] under "DANE DNS Record Size Guidelines".		found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
	TLSA Publishers SHOULD follow the TLSA record TTL and signature		TLSA Publishers SHOULD follow the TLSA record TTL and signature
	lifetime recommendations found in [I-D.ietf-dane-ops] under		lifetime recommendations found in [I-D.ietf-dane-ops] under
	"Operational Considerations".		"Operational Considerations".
End of changes. 15 change blocks.
	29 lines changed or deleted		58 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/