draft-ietf-uta-mta-sts-13.txt		draft-ietf-uta-mta-sts-14.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: June 7, 2018 B. Ramakrishnan		Expires: July 20, 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		January 16, 2018
	SMTP MTA Strict Transport Security (MTA-STS)		SMTP MTA Strict Transport Security (MTA-STS)
	draft-ietf-uta-mta-sts-13		draft-ietf-uta-mta-sts-14
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 June 7, 2018.		This Internet-Draft will expire on July 20, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 30 ¶
	MUST present a X.509 certificate which is valid for the "mta-sts"		MUST present a X.509 certificate which is valid for the "mta-sts"
	host (e.g. "mta-sts.example.com") as described below, chain to a		host (e.g. "mta-sts.example.com") as described below, chain to a
	root CA that is trusted by the sending MTA, and be non-expired. It		root CA that is trusted by the sending MTA, and be non-expired. It
	is expected that sending MTAs use a set of trusted CAs similar to		is expected that sending MTAs use a set of trusted CAs similar to
	those in widely deployed Web browsers and operating systems.		those in widely deployed Web browsers and operating systems.
	The certificate is valid for the "mta-sts" host with respect to the		The certificate is valid for the "mta-sts" host with respect to the
	rules described in [RFC6125], with the following application-specific		rules described in [RFC6125], with the following application-specific
	considerations:		considerations:
	o Matching is performed only against the DNS-ID and CN-ID		o Matching is performed only against the DNS-ID identifiers.
	identifiers.
	o DNS domain names in server certificates MAY contain the wildcard		o DNS domain names in server certificates MAY contain the wildcard
	character '*' as the complete left-most label within the		character '*' as the complete left-most label within the
	identifier.		identifier.
	The certificate MAY be checked for revocation via the Online		The certificate MAY be checked for revocation via the Online
	Certificate Status Protocol (OCSP) [RFC6960], certificate revocation		Certificate Status Protocol (OCSP) [RFC6960], certificate revocation
	lists (CRLs), or some other mechanism.		lists (CRLs), or some other mechanism.
	Policies fetched via HTTPS are only valid if the HTTP response code		Policies fetched via HTTPS are only valid if the HTTP response code
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 13 ¶
	described in "MX Certificate Validation".		described in "MX Certificate Validation".
	This section does not dictate the behavior of sending MTAs when		This section does not dictate the behavior of sending MTAs when
	policies fail to validate; see Section 5, "Policy Application" for a		policies fail to validate; see Section 5, "Policy Application" for a
	description of sending MTA behavior when policy validation fails.		description of sending MTA behavior when policy validation fails.
	4.1. MX Certificate Validation		4.1. MX Certificate Validation
	The certificate presented by the receiving MX MUST chain to a root CA		The certificate presented by the receiving MX MUST chain to a root CA
	that is trusted by the sending MTA and be non-expired. The		that is trusted by the sending MTA and be non-expired. The
	certificate MUST have a CN-ID ([RFC6125]) or subject alternative name		certificate MUST have a subject alternative name (SAN, [RFC5280])
	(SAN, [RFC5280]) with a DNS-ID matching the "mx" pattern. The MX's		with a DNS-ID matching the "mx" pattern. The MX's certificate MAY
	certificate MAY also be checked for revocation via OCSP [RFC6960],		also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or
	CRLs [RFC6818], or some other mechanism.		some other mechanism.
	Because the "mx" patterns are not hostnames, however, matching is not		Because the "mx" patterns are not hostnames, however, matching is not
	identical to other common cases of X.509 certificate authentication		identical to other common cases of X.509 certificate authentication
	(as described, for example, in [RFC6125]). Consider the example		(as described, for example, in [RFC6125]). Consider the example
	policy given above, with an "mx" pattern containing ".example.com".		policy given above, with an "mx" pattern containing ".example.com".
	In this case, if the MX server's X.509 certificate contains a SAN		In this case, if the MX server's X.509 certificate contains a SAN
	matching "*.example.com", we are required to implement "wildcard-to-		matching "*.example.com", we are required to implement "wildcard-to-
	wildcard" matching.		wildcard" matching.
	To simplify this case, we impose the following constraints on		To simplify this case, we impose the following constraints on
	wildcard certificates, identical to those in [RFC7672] section 3.2.3		wildcard certificates, identical to those in [RFC7672] section 3.2.3
	and [RFC6125] section 6.4.3: wildcards are valid in DNS-IDs or CN-		and [RFC6125] section 6.4.3: wildcards are valid in DNS-IDs, but must
	IDs, but must be the entire first label of the identifier (that is,		be the entire first label of the identifier (that is,
	"*.example.com", not "mail*.example.com"). Senders who are comparing		"*.example.com", not "mail*.example.com"). Senders who are comparing
	a "suffix" MX pattern with a wildcard identifier should thus strip		a "suffix" MX pattern with a wildcard identifier should thus strip
	the wildcard and ensure that the two sides match label-by-label,		the wildcard and ensure that the two sides match label-by-label,
	until all labels of the shorter side (if unequal length) are		until all labels of the shorter side (if unequal length) are
	consumed.		consumed.
	Note that a wildcard must match a label; an "mx" pattern of		Note that a wildcard must match a label; an "mx" pattern of
	".example.com" thus does not match a SAN of "example.com", nor does a		".example.com" thus does not match a SAN of "example.com", nor does a
	SAN of "*.example.com" match an "mx" of "example.com".		SAN of "*.example.com" match an "mx" of "example.com".
	skipping to change at page 19, line 14 ¶		skipping to change at page 19, line 14 ¶
	Markus Laber 1&1 Mail & Media Development & Technology GmbH		Markus Laber 1&1 Mail & Media Development & Technology GmbH
	markus.laber (at) 1und1 (dot de)		markus.laber (at) 1und1 (dot de)
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-uta-smtp-tlsrpt]		[I-D.ietf-uta-smtp-tlsrpt]
	Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,		Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
	and M. Risher, "SMTP TLS Reporting", draft-ietf-uta-smtp-		and M. Risher, "SMTP TLS Reporting", draft-ietf-uta-smtp-
	tlsrpt-11 (work in progress), November 2017.		tlsrpt-13 (work in progress), December 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode		[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications		for Internationalized Domain Names in Applications
	(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,		(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<https://www.rfc-editor.org/info/rfc3492>.		<https://www.rfc-editor.org/info/rfc3492>.
	skipping to change at page 22, line 36 ¶		skipping to change at page 22, line 36 ¶
	if pat[0] == '.' {		if pat[0] == '.' {
	parts = SplitN(host, '.', 2) // Split on the first '.'.		parts = SplitN(host, '.', 2) // Split on the first '.'.
	if len(parts) > 1 && parts[1] == pat[1:] {		if len(parts) > 1 && parts[1] == pat[1:] {
	return true		return true
	}		}
	}		}
	return false		return false
	}		}
	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 DNS-ID SANs.
	for san in getDnsIdSansAndCnFromCert(connection) {		for san in getDnsIdSansFromCert(connection) {
	for mx in policy.mx {		for mx in policy.mx {
	// Return if the server certificate from "connection" matches the		// Return if the server certificate from "connection" matches the
	// "mx" host.		// "mx" host.
	if san[0] == '*' {		if san[0] == '*' {
	// Invalid wildcard!		// Invalid wildcard!
	if san[1] != '.' continue		if san[1] != '.' continue
	san = san[1:]		san = san[1:]
	}		}
	if isWildcardMatch(san, mx) || isWildcardMatch(mx, san) {		if isWildcardMatch(san, mx) || isWildcardMatch(mx, san) {
	return true		return true
End of changes. 10 change blocks.
	16 lines changed or deleted		15 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/