draft-ietf-uta-mta-sts-12.txt		draft-ietf-uta-mta-sts-13.txt
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Intended status: Standards Track Google, Inc		Intended status: Standards Track Google, Inc
	Expires: June 7, 2018 B. Ramakrishnan		Expires: June 7, 2018 B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	A. Brotman		A. Brotman
	Comcast, Inc		Comcast, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc
	December 4, 2017		December 4, 2017
	SMTP MTA Strict Transport Security (MTA-STS)		SMTP MTA Strict Transport Security (MTA-STS)
	draft-ietf-uta-mta-sts-12		draft-ietf-uta-mta-sts-13
	Abstract		Abstract
	SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a		SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a
	mechanism enabling mail service providers to declare their ability to		mechanism enabling mail service providers to declare their ability to
	receive Transport Layer Security (TLS) secure SMTP connections, and		receive Transport Layer Security (TLS) secure SMTP connections, and
	to specify whether sending SMTP servers should refuse to deliver to		to specify whether sending SMTP servers should refuse to deliver to
	MX hosts that do not offer TLS with a trusted server certificate.		MX hosts that do not offer TLS with a trusted server certificate.
	Status of This Memo		Status of This Memo
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	The DANE TLSA record [RFC7672] is similar, in that DANE is also		The DANE TLSA record [RFC7672] is similar, in that DANE is also
	designed to upgrade unauthenticated encryption or plaintext		designed to upgrade unauthenticated encryption or plaintext
	transmission into authenticated, downgrade-resistant encrypted		transmission into authenticated, downgrade-resistant encrypted
	transmission. DANE requires DNSSEC [RFC4033] for authentication; the		transmission. DANE requires DNSSEC [RFC4033] for authentication; the
	mechanism described here instead relies on certificate authorities		mechanism described here instead relies on certificate authorities
	(CAs) and does not require DNSSEC, at a cost of risking malicious		(CAs) and does not require DNSSEC, at a cost of risking malicious
	downgrades. For a thorough discussion of this trade-off, see		downgrades. For a thorough discussion of this trade-off, see
	Section 10, "Security Considerations".		Section 10, "Security Considerations".
	In addition, MTA-STS provides an optional report-only mode, enabling		In addition, MTA-STS provides an optional testing-only mode, enabling
	soft deployments to detect policy failures; partial deployments can		soft deployments to detect policy failures; partial deployments can
	be achieved in DANE by deploying TLSA records only for some of a		be achieved in DANE by deploying TLSA records only for some of a
	domain's MXs, but such a mechanism is not possible for the per-domain		domain's MXs, but such a mechanism is not possible for the per-domain
	policies used by MTA-STS.		policies used by MTA-STS.
	The primary motivation of MTA-STS is to provide a mechanism for		The primary motivation of MTA-STS is to provide a mechanism for
	domains to ensure transport security even when deploying DNSSEC is		domains to ensure transport security even when deploying DNSSEC is
	undesirable or impractical. However, MTA-STS is designed not to		undesirable or impractical. However, MTA-STS is designed not to
	interfere with DANE deployments when the two overlap; in particular,		interfere with DANE deployments when the two overlap; in particular,
	senders who implement MTA-STS validation MUST NOT allow a "valid" or		senders who implement MTA-STS validation MUST NOT allow a "valid" or
	"report-only" MTA-STS validation to override a failing DANE		"testing"-only MTA-STS validation to override a failing DANE
	validation.		validation.
	3. Policy Discovery		3. Policy Discovery
	MTA-STS policies are distributed via HTTPS from a "well-known"		MTA-STS policies are distributed via HTTPS from a "well-known"
	[RFC5785] path served within the Policy Domain, and their presence		[RFC5785] path served within the Policy Domain, and their presence
	and current version are indicated by a TXT record at the Policy		and current version are indicated by a TXT record at the Policy
	Domain. These TXT records additionally contain a policy "id" field,		Domain. These TXT records additionally contain a policy "id" field,
	allowing sending MTAs to check the currency of a cached policy		allowing sending MTAs to check the currency of a cached policy
	without performing an HTTPS request.		without performing an HTTPS request.
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	When sending to an MX at a domain for which the sender has a valid,		When sending to an MX at a domain for which the sender has a valid,
	non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies		non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies
	the result of a policy validation failure one of two ways, depending		the result of a policy validation failure one of two ways, depending
	on the value of the policy "mode" field:		on the value of the policy "mode" field:
	1. "enforce": In this mode, sending MTAs MUST NOT deliver the		1. "enforce": In this mode, sending MTAs MUST NOT deliver the
	message to hosts which fail MX matching or certificate		message to hosts which fail MX matching or certificate
	validation.		validation.
	2. "report": In this mode, sending MTAs which also implement the		2. "testing": In this mode, sending MTAs which also implement the
	TLSRPT specification [I-D.ietf-uta-smtp-tlsrpt] merely send a		TLSRPT specification [I-D.ietf-uta-smtp-tlsrpt] merely send a
	report indicating policy application failures (so long as TLSRPT		report indicating policy application failures (so long as TLSRPT
	is also implemented by the recipient domain).		is also implemented by the recipient domain).
	3. "none": In this mode, sending MTAs should treat the policy domain		3. "none": In this mode, sending MTAs should treat the policy domain
	as though it does not have any active policy; see Section 8.3,		as though it does not have any active policy; see Section 8.3,
	"Removing MTA-STS", for use of this mode value.		"Removing MTA-STS", for use of this mode value.
	When a message fails to deliver due to an "enforce" policy, a		When a message fails to deliver due to an "enforce" policy, a
	compliant MTA MUST NOT permanently fail to deliver messages before		compliant MTA MUST NOT permanently fail to deliver messages before
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 39 ¶
	validate.		validate.
	MTA-STS policy indicator TXT RR:		MTA-STS policy indicator TXT RR:
	_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"		_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
	MTA-STS Policy file served as the response body at "https://mta-		MTA-STS Policy file served as the response body at "https://mta-
	sts.example.com/.well-known/mta-sts.txt":		sts.example.com/.well-known/mta-sts.txt":
	version: STSv1		version: STSv1
	mode: report		mode: testing
	mx: mx1.example.com		mx: mx1.example.com
	mx: mx2.example.com		mx: mx2.example.com
	mx: mx.backup-example.com		mx: mx.backup-example.com
	max_age: 12345678		max_age: 12345678
	Appendix B. Message delivery pseudocode		Appendix B. Message delivery pseudocode
	Below is pseudocode demonstrating the logic of a compliant sending		Below is pseudocode demonstrating the logic of a compliant sending
	MTA.		MTA.
End of changes. 5 change blocks.
	5 lines changed or deleted		5 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/