< draft-ietf-dane-smtp-with-dane-03.txt		draft-ietf-dane-smtp-with-dane-04.txt >
	DANE V. Dukhovni		DANE V. Dukhovni
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Standards Track W.H. Hardaker		Intended status: Standards Track W.H. Hardaker
	Expires: May 28, 2014 Parsons		Expires: May 28, 2014 Parsons
	November 24, 2013		November 24, 2013
	SMTP security via opportunistic DANE TLS		SMTP security via opportunistic DANE TLS
	draft-ietf-dane-smtp-with-dane-03		draft-ietf-dane-smtp-with-dane-04
	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 15, line 4 ¶		skipping to change at page 14, line 47 ¶
	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		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		While [RFC6698] specifies multiple digest algorithms, it does not
	strongest shared algorithm, and thereby avoind exposure to any		explicitly specify a protocol by which the SMTP client and TLSA
	deprecated weaker algorithms that are published out of		record publisher can agree on the strongest shared algorithm. Such a
	interoperability concerns, but should if possible be ignored. We		protocol would allow the client and server to avoid exposure to any
	specify such a protocol below.		deprecated weaker algorithms that are published for campatibilty with
			less capable clients, but should if possible be ignored. We specify
			such a protocol below.
	Suppose that a DANE TLS client authenticating TLS server considers		Suppose that a DANE TLS client authenticating TLS server considers
	digest algorithm X stronger than digest algorithm Y. Suppose further		digest algorithm X stronger than digest algorithm Y. Suppose further
	that that a server's TLSA RRset contains some records with X as the		that that a server's TLSA RRset contains some records with X as the
	digest algorithm. Suppose that for every raw public key or		digest algorithm. Suppose that for every raw public key or
	certificate object that is included in the server's TLSA RRset in		certificate object that is included in the server's TLSA RRset in
	digest form, whenever that object appears with digest Y (with some		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) it also appears with digest X (with the same
	usage and selector). In that case our client can safely ignore TLSA		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 weaker digest Y, because it suffices to check the
	records with the stronger algorithm X.		records with the stronger algorithm X.
	We take the simplest appraoch and mandate that all published TLSA		We take the simplest appraoch and mandate that all published TLSA
	RRsets conform to the above assumptions. Then clients can		RRsets conform to the above assumptions. Then clients can
	unconditionally ignore all but the (equal) strongest digest records		unconditionally ignore all but the (equal) strongest digest records
	with a given usage and selector.		with a given usage and selector. The ordering of digest algorithms
			by strength is entirely up to the client. Only the future will tell
	Records with a matching type of "0", that publish the verbatim object		which algoritms might be weakened by new attacks and when.
	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		Therefore, server operators MUST ensure that for any given usage and
	selector, ALL objects with certificate association data with that		selector, ALL objects with certificate association data with that
	usage and selector that are published with a digest matching type are		usage and selector that are published with a digest matching type are
	published with the SAME SET of digests (non-zero matching types). In		published with the SAME SET of digests (non-zero matching types). In
	other words, for each usage and selector, the records with non-zero		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		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.		and a fixed set of digests that apply uniformly to all the objects.
			Records with a matching type of "0", that publish the full 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.
	SMTP clients SHOULD use digest algorithm agility when processing the		SMTP clients SHOULD use digest algorithm agility when processing the
	DANE TLSA records of an SMTP server. Algorithm agility is to be		DANE TLSA records of an SMTP server. Algorithm agility is to be
	applied after first discarding any unusable or malformed records		applied after first discarding any unusable or malformed records
	(unsupported digest algorithm, or incorrect digest length). Thus,		(unsupported digest algorithm, or incorrect digest length). Thus,
	for each usage and selector, the client SHOULD only process any		for each usage and selector, the client SHOULD only process any
	usable records with a matching type of "0" and any usable records		usable records with a matching type of "0" and any usable records
	whose digest is the strongest among usable records with the same		whose digest is believed to be the strongest among usable records
	usage and selector.		with the same usage and selector.
	The main impact of this requirement is on key rotation, when the TLSA		The main impact of this requirement is on key rotation, when the TLSA
	RRset is pre-populated with digests of new certificates or public		RRset is pre-populated with digests of new certificates or public
	keys, before these replace their predecessors. Were the newly		keys, before these replace or augment their predecessors. Were the
	introduced RRs to include previously unused digest algorithms,		newly introduced RRs to include previously unused digest algorithms,
	clients that employ this protocol could potentially ignore all the		clients that employ this protocol could potentially ignore all the
	digests corresponding to the currently deployed certificates causing		digests corresponding to the currently deployed certificates causing
	connectivity issues until new keys or certificates are fielded.		connectivity issues until the new keys or certificates are deployed.
	Similarly, publishing new records with fewer digests could cause		Similarly, publishing new records with fewer digests could cause
	problems once the new keys are deployed.		problems once the new keys are deployed.
	Therefore, server operators SHOULD follow the following rule. When		Server operators SHOULD follow the following rules. When adding or
	adding or removing objects from the TLSA RRset (e.g. during key		removing objects from the TLSA RRset (e.g. during key rotation), DO
	rotation), DO NOT change the set of digests used, change just the		NOT change the set of digests used, change just the list of objects.
	list of objects. When changing the set of digests used, change only		When changing the set of digests used, change only the set of
	the digests, and generate a new RRset in which all the existing		digests, and generate a new RRset in which all the current objects
	objects are re-published with the new set of digests.		are re-published with the new set of digests.
	The client-side of this "digest algorithm agility" protocol is		The client-side of this "digest algorithm agility" protocol is
	enabled by default in the first DANE for SMTP implementation. For		enabled by default in the first DANE for SMTP implementation. For
	key rotation to work non-disruptively server operators MUST ensure		key rotation to work non-disruptively server operators MUST ensure
	that their TLSA records conform with the above specification.		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
End of changes. 8 change blocks.
	24 lines changed or deleted		28 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/