draft-ietf-uta-mta-sts-05.txt		draft-ietf-uta-mta-sts-06.txt
	Using TLS in Applications D. Margolis		Using TLS in Applications D. Margolis
	Internet-Draft M. Risher		Internet-Draft M. Risher
	Intended status: Standards Track Google, Inc		Intended status: Standards Track Google, Inc
	Expires: November 4, 2017 B. Ramakrishnan		Expires: December 01, 2017 B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	A. Brotman		A. Brotman
	Comcast, Inc		Comcast, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc
	May 3, 2017		May 31, 2017
	SMTP MTA Strict Transport Security (MTA-STS)		SMTP MTA Strict Transport Security (MTA-STS)
	draft-ietf-uta-mta-sts-05		draft-ietf-uta-mta-sts-06
	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 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 November 4, 2017.		This Internet-Draft will expire on November 26, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 10, line 16 ¶		skipping to change at page 10, line 16 ¶
	the case of temporary message delivery failures (as discussed in		the case of temporary message delivery failures (as discussed in
	[RFC5321] section 4.5.4.1).		[RFC5321] section 4.5.4.1).
	6. Operational Considerations		6. Operational Considerations
	6.1. Policy Updates		6.1. Policy Updates
	Updating the policy requires that the owner make changes in two		Updating the policy requires that the owner make changes in two
	places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and		places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
	at the corresponding HTTPS endpoint. As a result, recipients should		at the corresponding HTTPS endpoint. As a result, recipients should
	thus expect a policy will continue to be used by senders until both		expect a policy will continue to be used by senders until both the
	the HTTPS and TXT endpoints are updated and the TXT record's TTL has		HTTPS and TXT endpoints are updated and the TXT record's TTL has
	passed.		passed.
	In other words, a sender who is unable to successfully deliver a		In other words, a sender who is unable to successfully deliver a
	message while applying a cache of the recipient's now-outdated policy		message while applying a cache of the recipient's now-outdated policy
	may be unable to discover that a new policy exists until the DNS TTL		may be unable to discover that a new policy exists until the DNS TTL
	has passed. Recipients should therefore ensure that old policies		has passed. Recipients should therefore ensure that old policies
	continue to work for message delivery during this period of time, or		continue to work for message delivery during this period of time, or
	risk message delays.		risk message delays.
			Recipients should also prefer to update the HTTPS policy body before
			updating the TXT record; this ordering avoids the risk that senders,
			seeing a new TXT record, mistakenly cache the old policy from HTTPS.
	7. IANA Considerations		7. IANA Considerations
	A new .well-known URI will be registered in the Well-Known URIs		A new .well-known URI will be registered in the Well-Known URIs
	registry as described below:		registry as described below:
	URI Suffix: mta-sts.json Change Controller: IETF		URI Suffix: mta-sts.json Change Controller: IETF
	8. Security Considerations		8. Security Considerations
	SMTP MTA Strict Transport Security attempts to protect against an		SMTP MTA Strict Transport Security attempts to protect against an
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 30 ¶
	// Attempt to open an SMTP connection with STARTTLS with the MX.		// Attempt to open an SMTP connection with STARTTLS with the MX.
	}		}
	func certMatches(connection, policy) {		func certMatches(connection, policy) {
	// Assume a handy function to return CN and DNS-ID SANs.		// Assume a handy function to return CN and DNS-ID SANs.
	for san in getDnsIdSansAndCnFromCert(connection) {		for san in getDnsIdSansAndCnFromCert(connection) {
	for mx in policy.mx {		for mx in policy.mx {
	// Return if the server certificate from "connection" matches the "mx" host.		// Return if the server certificate from "connection" matches the "mx" host.
	if san[0] == '*' {		if san[0] == '*' {
	// Invalid wildcard!		// Invalid wildcard!
	if san[1] != '.' return false		if san[1] != '.' continue
	san = san[1:]		san = san[1:]
	}		}
	if san[0] == '.' && HasSuffix(mx, san) {		if san[0] == '.' && HasSuffix(mx, san) {
	return true		return true
	}		}
	if mx[0] == '.' && HasSuffix(san, mx) {		if mx[0] == '.' && HasSuffix(san, mx) {
	return true		return true
	}		}
	if mx == san {		if mx == san {
	return true		return true
End of changes. 7 change blocks.
	7 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/