< draft-ietf-dane-smtp-with-dane-02.txt		draft-ietf-dane-smtp-with-dane-03.txt >
	DANE V. Dukhovni		DANE V. Dukhovni
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Experimental W. Hardaker		Intended status: Standards Track W.H. Hardaker
	Expires: April 24, 2014 Parsons		Expires: May 28, 2014 Parsons
	October 21, 2013		November 24, 2013
	SMTP security via opportunistic DANE TLS		SMTP security via opportunistic DANE TLS
	draft-ietf-dane-smtp-with-dane-02		draft-ietf-dane-smtp-with-dane-03
	Abstract		Abstract
	This memo describes a protocol for opportunistic TLS security based		This memo describes a protocol for opportunistic TLS security based
	on the DANE TLSA DNS record. The protocol is downgrade resistant		on the DANE TLSA DNS record. The protocol is downgrade resistant
	when the SMTP client supports DANE TLSA and the server domain		when the SMTP client supports DANE TLSA and the server domain
	publishes TLSA records for its MX hosts. This enables an incremental		publishes TLSA records for its MX hosts. This enables an incremental
	transition of the Internet email backbone (MTA to MTA SMTP traffic)		transition of the Internet email backbone (MTA to MTA SMTP traffic)
	to TLS encrypted and authenticated delivery.		to TLS encrypted and authenticated delivery.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 24, 2014.		This Internet-Draft will expire on May 28, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . . . . . . . . . . . 11
	2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 10		2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 11
	2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12		2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12
	3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 14		2.2.3. Digest algorithm agility . . . . . . . . . . . . . . 14
	4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 15		3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 16
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	7. Normative References . . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		7. Normative References . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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 3, line 13 ¶		skipping to change at page 3, line 23 ¶
	validated TLSA records.		validated TLSA records.
	The Transport Layer Security (TLS [RFC5246]) protocol enables secure		The Transport Layer Security (TLS [RFC5246]) protocol enables secure
	TCP communication. In the context of this memo, channel security is		TCP communication. In the context of this memo, channel security is
	assumed to be provided by TLS. Used without authentication, TLS		assumed to be provided by TLS. Used without authentication, TLS
	protects only against eavesdropping. With authentication, TLS also		protects only against eavesdropping. With authentication, TLS also
	protects against man-in-the-middle (MITM) attacks.		protects against man-in-the-middle (MITM) attacks.
	1.2. SMTP Channel Security		1.2. SMTP Channel Security
	The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop		The Simple Mail Transfer Protocol (SMTP) ([RFC5321]) is multi-hop
	store & forward, while TLS security is hop-by-hop. The number of		store & forward, while TLS security is hop-by-hop. The number of
	hops from the sender's Mail User Agent to the recipient mailbox is		hops from the sender's Mail User Agent to the recipient mailbox is
	rarely less than 2 and is often higher. Some hops may be TLS		rarely less than 2 and is often higher. Some hops may be TLS
	protected, some may not. The same SMTP TCP endpoint can serve both		protected, some may not. The same SMTP TCP endpoint can serve both
	TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS		TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS
	command ([RFC3207]). DNS MX records abstract the next-hop transport		command ([RFC3207]). DNS MX records abstract the next-hop transport
	end-point. SMTP addresses are not transport addresses and are		end-point. SMTP addresses are not transport addresses and are
	security agnostic. Unlike HTTP, there is no URI scheme for email		security agnostic. Unlike HTTP, there is no URI scheme for email
	addresses to designate whether the SMTP server should be contacted		addresses to designate whether the SMTP server should be contacted
	with or without security.		with or without security.
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 42 ¶
	The SMTP client MUST NOT perform certificate usage name checks with		The SMTP client MUST NOT perform certificate usage name checks with
	certificate usage "3", since with usage "3" the server is		certificate usage "3", since with usage "3" the server is
	authenticated directly by matching the TLSA RRset to its certificate		authenticated directly by matching the TLSA RRset to its certificate
	or public key without resort to any issuing authority. The		or public key without resort to any issuing authority. The
	certificate content is ignored except in so far as it is used to		certificate content is ignored except in so far as it is used to
	match the certificate or public key (ASN.1 object or its digest) with		match the certificate or public key (ASN.1 object or its digest) with
	the TLSA RRset.		the TLSA RRset.
	To ensure that the server sends the right certificate chain, the SMTP		To ensure that the server sends the right certificate chain, the SMTP
	client MUST send the TLS SNI extension containing the TLSA base		client MUST send the TLS SNI extension containing the TLSA base
	domain. Since DANE-aware clients are obligated to send SNI		domain. This precludes the use of SSLv2-compatible SSL HELLO by the
	information, which requires at least TLS 1.0, SMTP servers for which		SMTP client. The minimum SSL/TLS version for SMTP clients performing
	DANE TLSA records are published MUST support TLS 1.0 or later with		DANE authentication is SSLv3.
	any client authorized to use the service.
	Each SMTP server MUST present a certificate chain (see [RFC2246]		Each SMTP server MUST present a certificate chain (see [RFC2246]
	Section 7.4.2) that matches at least one of the TLSA records. The		Section 7.4.2) that matches at least one of the TLSA records. The
	server MAY rely on SNI to determine which certificate chain to		server MAY rely on SNI to determine which certificate chain to
	present to the client. Clients that don't send SNI information may		present to the client. Clients that don't send SNI information may
	not see the expected certificate chain.		not see the expected certificate chain.
	If the server's TLSA RRset includes records with a matching type		If the server's TLSA RRset includes records with a matching type
	indicating a digest record (i.e., a value other than "0"), the		indicating a digest record (i.e., a value other than "0"), the
	SHA-256 digest of any object SHOULD be provided along with any other		SHA-256 digest of any object SHOULD be provided along with any other
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 22 ¶
	If the server's TLSA records match the server's default certificate		If the server's TLSA records match the server's default certificate
	chain, the server need not support SNI. The server need not include		chain, the server need not support SNI. The server need not include
	the extension in its TLS HELLO, simply returning a matching		the extension in its TLS HELLO, simply returning a matching
	certificate chain is sufficient. Servers MUST NOT enforce the use of		certificate chain is sufficient. Servers MUST NOT enforce the use of
	SNI by clients, if the client sends no SNI extension, or sends an SNI		SNI by clients, if the client sends no SNI extension, or sends an SNI
	extension for an unsupported domain the server MUST simply use its		extension for an unsupported domain the server MUST simply use its
	default certificate chain. The client may be using unauthenticated		default certificate chain. The client may be using unauthenticated
	opportunistic TLS and may not expect any particular certificate from		opportunistic TLS and may not expect any particular certificate from
	the server.		the server.
	The client may even offer to use anonymous TLS ciphersuites and		The SMTP client MAY include anonymous TLS ciphersuites in its SSL
	servers SHOULD support these. No security is gained by sending a		HELO. MX hosts that receive email from the Internet MUST
	certificate the client is willing to ignore. Indeed support for		interoperate with opportunistic TLS SMTP clients. If they advertise
	anonymous ciphersuites in the server makes audit trails more useful		support for STARTTLS in their SMTP EHLO response, they MUST NOT fail
	when the chosen ciphersuite is logged, as this will in many cases		to complete the TLS handshake merely because the SMTP client offered
	record which clients did not care to authenticate the server. (The		some ciphersuites that do not provide for server authentication.
	Postfix SMTP server supports anonymous TLS ciphersuites by default,
			While server operators are under no obligation to implement or enable
			anonymous ciphers, no security is gained by sending certificates
			clients are willing to ignore. Indeed support for anonymous
			ciphersuites in the server makes audit trails more useful when the
			chosen ciphersuite is logged, as this will in many cases record which
			clients did not care to authenticate the server. For example, the
			Postfix SMTP server enables anonymous TLS ciphersuites by default,
	and the Postfix SMTP client offers these at its highest preference		and the Postfix SMTP client offers these at its highest preference
	when server authentication is not applicable).		when server authentication is not applicable.
	With opportunistic DANE TLS, both the TLS support implied by the		With opportunistic DANE TLS, both the TLS support implied by the
	presence of DANE TLSA records and the verification parameters		presence of DANE TLSA records and the verification parameters
	necessary to authenticate the TLS peer are obtained together,		necessary to authenticate the TLS peer are obtained together,
	therefore authentication via this protocol is expected to be less		therefore authentication via this protocol is expected to be less
	prone to connection failure caused by incompatible configuration of		prone to connection failure caused by incompatible configuration of
	the client and server.		the client and server.
			2.2.3. Digest algorithm agility
			While [RFC6698] specifies multiple digest algorithms it does not
			explicitly specify a protocol by which the publisher can agree on the
			strongest shared algorithm, and thereby avoind exposure to any
			deprecated weaker algorithms that are published out of
			interoperability concerns, but should if possible be ignored. We
			specify such a protocol below.
			Suppose that a DANE TLS client authenticating TLS server considers
			digest algorithm X stronger than digest algorithm Y. Suppose further
			that that a server's TLSA RRset contains some records with X as the
			digest algorithm. Suppose that for every raw public key or
			certificate object that is included in the server's TLSA RRset in
			digest form, whenever that object appears with digest Y (with some
			usage and selector) it also appears with digest X (with the same
			usage and selector). In that case our client can safely ignore TLSA
			records with the weaker digest Y, because it suffices to check the
			records with the stronger algorithm X.
			We take the simplest appraoch and mandate that all published TLSA
			RRsets conform to the above assumptions. Then clients can
			unconditionally ignore all but the (equal) strongest digest records
			with a given usage and selector.
			Records with a matching type of "0", that publish the verbatim object
			value play no role in digest algorithm agility. They neither preempt
			the processing of records that employ digests, nor are they ignored
			in the presence of any digest records.
			Therefore, server operators MUST ensure that for any given usage and
			selector, ALL objects with certificate association data with that
			usage and selector that are published with a digest matching type are
			published with the SAME SET of digests (non-zero matching types). In
			other words, for each usage and selector, the records with non-zero
			matching types will be a cross-product of a set of underlying objects
			and a fixed set of digests that apply uniformly to all the objects.
			SMTP clients SHOULD use digest algorithm agility when processing the
			DANE TLSA records of an SMTP server. Algorithm agility is to be
			applied after first discarding any unusable or malformed records
			(unsupported digest algorithm, or incorrect digest length). Thus,
			for each usage and selector, the client SHOULD only process any
			usable records with a matching type of "0" and any usable records
			whose digest is the strongest among usable records with the same
			usage and selector.
			The main impact of this requirement is on key rotation, when the TLSA
			RRset is pre-populated with digests of new certificates or public
			keys, before these replace their predecessors. Were the newly
			introduced RRs to include previously unused digest algorithms,
			clients that employ this protocol could potentially ignore all the
			digests corresponding to the currently deployed certificates causing
			connectivity issues until new keys or certificates are fielded.
			Similarly, publishing new records with fewer digests could cause
			problems once the new keys are deployed.
			Therefore, server operators SHOULD follow the following rule. When
			adding or removing objects from the TLSA RRset (e.g. during key
			rotation), DO NOT change the set of digests used, change just the
			list of objects. When changing the set of digests used, change only
			the digests, and generate a new RRset in which all the existing
			objects are re-published with the new set of digests.
			The client-side of this "digest algorithm agility" protocol is
			enabled by default in the first DANE for SMTP implementation. For
			key rotation to work non-disruptively server operators MUST ensure
			that their TLSA records conform with the above specification.
	3. Opportunistic TLS for Submission		3. Opportunistic TLS for Submission
	Prior to [RFC6409], the SMTP submission protocol was a poster-child		Prior to [RFC6409], the SMTP submission protocol was a poster-child
	for PKIX TLS. The MUA typically connects to one or more submission		for PKIX TLS. The MUA typically connects to one or more submission
	servers explicitly configured by the user. There is no indirection		servers explicitly configured by the user. There is no indirection
	via insecure MX records, and unlike web browsers, there is no need to		via insecure MX records, and unlike web browsers, there is no need to
	authenticate a large set of TLS servers. Once TLS is enabled for the		authenticate a large set of TLS servers. Once TLS is enabled for the
	desired submission server or servers, provided the server certificate		desired submission server or servers, provided the server certificate
	is correctly maintained, the MUA is able to reliably use TLS to		is correctly maintained, the MUA is able to reliably use TLS to
	authenticate the submission server.		authenticate the submission server.
End of changes. 10 change blocks.
	26 lines changed or deleted		101 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/