Diff: draft-ietf-uta-mta-sts-18.txt - draft-ietf-uta-mta-sts-19.txt

	draft-ietf-uta-mta-sts-18.txt		draft-ietf-uta-mta-sts-19.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 21, 2018 B. Ramakrishnan		Expires: November 24, 2018 B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	A. Brotman		A. Brotman
	Comcast, Inc		Comcast, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc

	May 20, 2018		May 23, 2018

	SMTP MTA Strict Transport Security (MTA-STS)		SMTP MTA Strict Transport Security (MTA-STS)

	draft-ietf-uta-mta-sts-18		draft-ietf-uta-mta-sts-19

	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

	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.

	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 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 November 21, 2018.		This Internet-Draft will expire on November 24, 2018.

	Copyright Notice		Copyright Notice

	Copyright (c) 2018 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

	(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.

	Table of Contents		Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶

	sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)		sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
	; chars excluding "=", ";", and control chars		; chars excluding "=", ";", and control chars

	The TXT record MUST begin with sts-version field, and the order of		The TXT record MUST begin with sts-version field, and the order of
	other fields is not significant. If multiple TXT records for "_mta-		other fields is not significant. If multiple TXT records for "_mta-
	sts" are returned by the resolver, records which do not begin with		sts" are returned by the resolver, records which do not begin with
	"v=STSv1;" are discarded. If the number of resulting records is not		"v=STSv1;" are discarded. If the number of resulting records is not
	one, senders MUST assume the recipient domain does not have an		one, senders MUST assume the recipient domain does not have an
	available MTA-STS policy and skip the remaining steps of policy		available MTA-STS policy and skip the remaining steps of policy

	discovery. (Note that lack of an available policy does not signal		discovery. (Note that absence of a usable TXT record is not by
	opting out of MTA-STS altogether if the sender has a previously		itself sufficient to remove a sender's previously cached policy for
	cached policy for the recipient domain, as discussed in Section 5.1,		the Policy Domain, as discussed in Section 5.1, "Policy Application
	"Policy Application Control Flow".) If the resulting TXT record		Control Flow".) If the resulting TXT record contains multiple
	contains multiple strings, then the record MUST be treated as if		strings, then the record MUST be treated as if those strings are
	those strings are concatenated together without adding spaces.		concatenated together without adding spaces.

	3.2. MTA-STS Policies		3.2. MTA-STS Policies

	The policy itself is a set of key/value pairs (similar to [RFC5322]		The policy itself is a set of key/value pairs (similar to [RFC5322]
	header fields) served via the HTTPS GET method from the fixed		header fields) served via the HTTPS GET method from the fixed
	[RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by		[RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by
	the Policy Host. The Policy Host DNS name is constructed by		the Policy Host. The Policy Host DNS name is constructed by
	prepending "mta-sts" to the Policy Domain.		prepending "mta-sts" to the Policy Domain.


	Thus for a Policy Domain of "example.com" the path is "https://mta-		Thus for a Policy Domain of "example.com" the ful URL is
	sts.example.com/.well-known/mta-sts.txt".		"https://mta-sts.example.com/.well-known/mta-sts.txt".

	When fetching a policy, senders SHOULD validate that the media type		When fetching a policy, senders SHOULD validate that the media type
	is "text/plain" to guard against cases where webservers allow		is "text/plain" to guard against cases where webservers allow
	untrusted users to host non-text content (typically, HTML or images)		untrusted users to host non-text content (typically, HTML or images)
	at a user-defined path. All parameters other than charset=utf-8 or		at a user-defined path. All parameters other than charset=utf-8 or
	charset=us-ascii are ignored. Additional "Content-Type" parameters		charset=us-ascii are ignored. Additional "Content-Type" parameters
	are also ignored.		are also ignored.

	This resource contains the following CRLF-separated key/value pairs:		This resource contains the following CRLF-separated key/value pairs:


	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	A receiving candidate MX host is valid according to an applied MTA-		A receiving candidate MX host is valid according to an applied MTA-
	STS policy if the MX record name matches one or more of the "mx"		STS policy if the MX record name matches one or more of the "mx"
	fields in the applied policy. Matching is identical to the rules		fields in the applied policy. Matching is identical to the rules
	given in [RFC6125], with restriction that the wildcard character "*"		given in [RFC6125], with restriction that the wildcard character "*"
	may only be used to match the entire left-most label in the presented		may only be used to match the entire left-most label in the presented
	identifier. Thus the mx pattern "*.example.com" matches		identifier. Thus the mx pattern "*.example.com" matches
	"mail.example.com" but not "example.com" or "foo.bar.example.com".		"mail.example.com" but not "example.com" or "foo.bar.example.com".

	4.2. Recipient MTA Certificate Validation		4.2. Recipient MTA Certificate Validation


	The certificate presented by the receiving MTA MUST chain to a root		The certificate presented by the receiving MTA MUST not be expired,
	CA that is trusted by the sending MTA and be non-expired. The		and MUST chain to a root CA that is trusted by the sending MTA. The
	certificate MUST have a subject alternative name (SAN, [RFC5280])		certificate MUST have a subject alternative name (SAN, [RFC5280])
	with a DNS-ID ([RFC6125]) matching the host name, per the rules given		with a DNS-ID ([RFC6125]) matching the host name, per the rules given
	in [RFC6125]. The MX's certificate MAY also be checked for		in [RFC6125]. The MX's certificate MAY also be checked for
	revocation via OCSP [RFC6960], CRLs [RFC6818], or some other		revocation via OCSP [RFC6960], CRLs [RFC6818], or some other
	mechanism.		mechanism.

	5. Policy Application		5. Policy Application

	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

	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	_mta-sts.user.example. IN CNAME _mta-sts.provider.example.		_mta-sts.user.example. IN CNAME _mta-sts.provider.example.

	Policy:		Policy:

	> GET /.well-known/mta-sts.txt Host: mta-sts.user.example		> GET /.well-known/mta-sts.txt Host: mta-sts.user.example
	< HTTP/1.1 200 OK # Response proxies content from		< HTTP/1.1 200 OK # Response proxies content from
	# https://mta-sts.provider.example		# https://mta-sts.provider.example

	Note that in all such cases, the policy endpoint ("https://mta-		Note that in all such cases, the policy endpoint ("https://mta-
	sts.user.example/.well-known/mta-sts.txt" in this example) must still		sts.user.example/.well-known/mta-sts.txt" in this example) must still

	present a certificate valid for the Policy Domain ("user.example"),		present a certificate valid for the Policy Host ("mta-
	and not for that of the provider ("provider.example").		sts.user.example"), and not for that host at the provider's domain
			("mta-sts.provider.example").

	Note that while sending MTAs MUST NOT use HTTP caching when fetching		Note that while sending MTAs MUST NOT use HTTP caching when fetching
	policies via HTTPS, such caching may nonetheless be useful to a		policies via HTTPS, such caching may nonetheless be useful to a
	reverse proxy configured as described in this section. An HTTPS		reverse proxy configured as described in this section. An HTTPS
	policy endpoint expecting to be proxied for multiple hosted domains--		policy endpoint expecting to be proxied for multiple hosted domains--
	as with a large mail hosting provider or similar--may wish to		as with a large mail hosting provider or similar--may wish to
	indicate an HTTP Cache-Control "max-age" response directive (as		indicate an HTTP Cache-Control "max-age" response directive (as
	specified in [RFC7234]) of 60 seconds as a reasonable value to save		specified in [RFC7234]) of 60 seconds as a reasonable value to save
	reverse proxies an unnecessarily high-rate of proxied policy		reverse proxies an unnecessarily high-rate of proxied policy
	fetching.		fetching.

	skipping to change at page 20, line 45 ¶		skipping to change at page 20, line 45 ¶
	Klaus Umbach 1&1 Mail & Media Development & Technology GmbH		Klaus Umbach 1&1 Mail & Media Development & Technology GmbH
	klaus.umbach@1und1.de		klaus.umbach@1und1.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-20 (work in progress), May 2018.		tlsrpt-21 (work in progress), May 2018.

	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.

	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,

	DOI 10.17487/RFC2818, May 2000, <https://www.rfc-		DOI 10.17487/RFC2818, May 2000,
	editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.

	[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over		[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,		Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
	February 2002, <https://www.rfc-editor.org/info/rfc3207>.		February 2002, <https://www.rfc-editor.org/info/rfc3207>.

	[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>.

	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,

	DOI 10.17487/RFC5246, August 2008, <https://www.rfc-		DOI 10.17487/RFC5246, August 2008,
	editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.

	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.

	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,

	DOI 10.17487/RFC5321, October 2008, <https://www.rfc-		DOI 10.17487/RFC5321, October 2008,
	editor.org/info/rfc5321>.		<https://www.rfc-editor.org/info/rfc5321>.

	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,

	DOI 10.17487/RFC5785, April 2010, <https://www.rfc-		DOI 10.17487/RFC5785, April 2010,
	editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.

	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,

	DOI 10.17487/RFC6066, January 2011, <https://www.rfc-		DOI 10.17487/RFC6066, January 2011,
	editor.org/info/rfc6066>.		<https://www.rfc-editor.org/info/rfc6066>.

	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	2011, <https://www.rfc-editor.org/info/rfc6125>.		2011, <https://www.rfc-editor.org/info/rfc6125>.

	[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		RFC 7405, DOI 10.17487/RFC7405, December 2014,

	skipping to change at page 22, line 23 ¶		skipping to change at page 22, line 23 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	12.2. Informative References		12.2. Informative References

	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<https://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/info/rfc4033>.

	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,

	DOI 10.17487/RFC5322, October 2008, <https://www.rfc-		DOI 10.17487/RFC5322, October 2008,
	editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.

	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891,		Applications (IDNA): Protocol", RFC 5891,

	DOI 10.17487/RFC5891, August 2010, <https://www.rfc-		DOI 10.17487/RFC5891, August 2010,
	editor.org/info/rfc5891>.		<https://www.rfc-editor.org/info/rfc5891>.

	[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key		[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January		(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
	2013, <https://www.rfc-editor.org/info/rfc6818>.		2013, <https://www.rfc-editor.org/info/rfc6818>.

	[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,		[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
	Galperin, S., and C. Adams, "X.509 Internet Public Key		Galperin, S., and C. Adams, "X.509 Internet Public Key
	Infrastructure Online Certificate Status Protocol - OCSP",		Infrastructure Online Certificate Status Protocol - OCSP",
	RFC 6960, DOI 10.17487/RFC6960, June 2013,		RFC 6960, DOI 10.17487/RFC6960, June 2013,
	<https://www.rfc-editor.org/info/rfc6960>.		<https://www.rfc-editor.org/info/rfc6960>.

	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.

	[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via		[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
	Opportunistic DNS-Based Authentication of Named Entities		Opportunistic DNS-Based Authentication of Named Entities
	(DANE) Transport Layer Security (TLS)", RFC 7672,		(DANE) Transport Layer Security (TLS)", RFC 7672,

	DOI 10.17487/RFC7672, October 2015, <https://www.rfc-		DOI 10.17487/RFC7672, October 2015,
	editor.org/info/rfc7672>.		<https://www.rfc-editor.org/info/rfc7672>.

	Appendix A. MTA-STS example record & policy		Appendix A. MTA-STS example record & policy

	The owner of "example.com" wishes to begin using MTA-STS with a		The owner of "example.com" wishes to begin using MTA-STS with a
	policy that will solicit reports from senders without affecting how		policy that will solicit reports from senders without affecting how
	the messages are processed, in order to verify the identity of MXs		the messages are processed, in order to verify the identity of MXs
	that handle mail for "example.com", confirm that TLS is correctly		that handle mail for "example.com", confirm that TLS is correctly
	used, and ensure that certificates presented by the recipient MX		used, and ensure that certificates presented by the recipient MX
	validate.		validate.


End of changes. 20 change blocks.
	37 lines changed or deleted		38 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/