draft-ietf-uta-smtp-tlsrpt-20.txt		draft-ietf-uta-smtp-tlsrpt-21.txt
	Using TLS in Applications D. Margolis		Using TLS in Applications D. Margolis
	Internet-Draft Google, Inc		Internet-Draft Google, Inc
	Intended status: Standards Track A. Brotman		Intended status: Standards Track A. Brotman
	Expires: November 3, 2018 Comcast, Inc		Expires: November 21, 2018 Comcast, Inc
	B. Ramakrishnan		B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc
	M. Risher		M. Risher
	Google, Inc		Google, Inc
	May 2, 2018		May 20, 2018
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-20		draft-ietf-uta-smtp-tlsrpt-21
	Abstract		Abstract
	A number of protocols exist for establishing encrypted channels		A number of protocols exist for establishing encrypted channels
	between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and		between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
	MTA-STS. These protocols can fail due to misconfiguration or active		MTA-STS. These protocols can fail due to misconfiguration or active
	attack, leading to undelivered messages or delivery over unencrypted		attack, leading to undelivered messages or delivery over unencrypted
	or unauthenticated channels. This document describes a reporting		or unauthenticated channels. This document describes a reporting
	mechanism and format by which sending systems can share statistics		mechanism and format by which sending systems can share statistics
	and specific information about potential failures with recipient		and specific information about potential failures with recipient
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 3, 2018.		This Internet-Draft will expire on November 21, 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		(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 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4		2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
	3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4		3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 7		3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 7
	3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7		3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7
	3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7		3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7
	4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7		4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8		4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8
	4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8		4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8		4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8		4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 9
	4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 9
	4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 9		4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
	4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9		4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 10
	4.3.3. General Failures . . . . . . . . . . . . . . . . . . 10		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
	4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10		4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 11
	4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10		4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 11
	4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13		4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 14
	5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 16
	5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16		5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 17
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 18
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 19
	5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18		5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 19
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18		6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 19
	6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 18		6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 19
	6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 19		6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 20
	6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 20		6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 21
	6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 21		6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 23
	6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 22		6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 24
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 22		7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
	8.1. Normative References . . . . . . . . . . . . . . . . . . 24		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8.2. Informative References . . . . . . . . . . . . . . . . . 26		9.1. Normative References . . . . . . . . . . . . . . . . . . 26
	Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 27		9.2. Informative References . . . . . . . . . . . . . . . . . 28
	A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 27		9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 27		Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 29
	Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 27		A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 29
			Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and		The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
	hosts to establish secure SMTP sessions over TLS. The protocol		hosts to establish secure SMTP sessions over TLS. The protocol
	design uses an approach that has come to be known as "Opportunistic		design uses an approach that has come to be known as "Opportunistic
	Security" (OS) [RFC7435]. This method maintains interoperability		Security" (OS) [RFC7435]. This method maintains interoperability
	with clients that do not support STARTTLS, but means that any		with clients that do not support STARTTLS, but means that any
	attacker could potentially eavesdrop on a session. An attacker could		attacker could potentially eavesdrop on a session. An attacker could
	perform a downgrade or interception attack by deleting parts of the		perform a downgrade or interception attack by deleting parts of the
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 24 ¶
	[BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all		[BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	We also define the following terms for further use in this document:		We also define the following terms for further use in this document:
	o MTA-STS Policy: A mechanism by which administrators can specify		o MTA-STS Policy: A mechanism by which administrators can specify
	the expected TLS availability, presented identity, and desired		the expected TLS availability, presented identity, and desired
	actions for a given email recipient domain. MTA-STS is defined in		actions for a given email recipient domain. MTA-STS is defined in
	[I-D.ietf-uta-mta-sts].		[I-D.ietf-uta-mta-sts].
	o DANE Policy: A mechanism by which administrators can specify		o DANE Policy: A mechanism by which administrators can use DNSSEC to
	constraints to be used to validate certificates presented by an		commit an MTA to support STARTTLS and to publish criteria to be
	MTA. DANE is defined in [RFC6698] and [RFC7672].		used to validate its presented certificates. DANE for SMTP is
			defined in [RFC7672], with the base specification in [RFC6698]
			(updated in [RFC7671].
	o TLSRPT Policy: A policy specifying the endpoint to which sending		o TLSRPT Policy: A policy specifying the endpoint to which sending
	MTAs should deliver reports.		MTAs should deliver reports.
	o Policy Domain: The domain against which an MTA-STS or DANE Policy		o Policy Domain: The domain against which an MTA-STS or DANE Policy
	is defined. This should be the same as the recipient envelope		is defined. For MTA-STS this is typically the same as the
	domain [RFC5321], such as if the message were going to		envelope recipient domain [RFC5321], but when mail is routed to a
	"alice@example.com', the policy domain would be "example.com".		"smarthost" gateway by local policy, the "smarthost" domain name
			is used instead. For DANE the Policy Domain is the "TLSA base
			domain" of the receiving SMTP server as described in RFC7672 [1]
			and RFC6698 [2].
	o Sending MTA: The MTA initiating the relay of an email message.		o Sending MTA: The MTA initiating the relay of an email message.
	o Aggregate Report URI (rua): A comma-separated list of locations		o Aggregate Report URI (rua): A comma-separated list of locations
	where the report is to be submitted.		where the report is to be submitted.
	2. Related Technologies		2. Related Technologies
	o This document is intended as a companion to the specification for		o This document is intended as a companion to the specification for
	SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts].		SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts].
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	field-delim = *WSP ";" *WSP		field-delim = *WSP ";" *WSP
	tlsrpt-field = tlsrpt-rua / ; Note that the		tlsrpt-field = tlsrpt-rua / ; Note that the
	tlsrpt-extension ; tlsrpt-rua record is		tlsrpt-extension ; tlsrpt-rua record is
	; required.		; required.
	tlsrpt-version = %s"v=TLSRPTv1"		tlsrpt-version = %s"v=TLSRPTv1"
	tlsrpt-rua = %s"rua="		tlsrpt-rua = %s"rua="
	tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)		tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
	tlsrpt-uri = URI		tlsrpt-uri = URI
	; "URI" is imported from [RFC3986];		; "URI" is imported from [RFC3986];
	; commas (ASCII 0x2C), exclamation		; commas (ASCII 0x2C), exclamation
	; points (ASCII 0x21), and semicolons		; points (ASCII 0x21), and semicolons
	; (ASCII 0x3B) MUST be encoded		; (ASCII 0x3B) MUST be encoded
	tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value		tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
	tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /		tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
	DIGIT / "_" / "-" / ".")		DIGIT / "_" / "-" / ".")
	tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)		tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
	; chars excluding "=", ";", SP, and control		; chars excluding "=", ";", SP, and control
	; chars		; chars
	If multiple TXT records for "_smtp._tls" are returned by the		If multiple TXT records for "_smtp._tls" are returned by the
	resolver, records which do not begin with "v=TLSRPTv1;" are		resolver, records which do not begin with "v=TLSRPTv1;" are
	discarded. If the number of resulting records is not one, senders		discarded. If the number of resulting records is not one, senders
	MUST assume the recipient domain does not implement TLSRPT. If the		MUST assume the recipient domain does not implement TLSRPT. If the
	resulting TXT record contains multiple strings (as described in		resulting TXT record contains multiple strings (as described in
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	would contain multiple entries. Each entry would have its own set of		would contain multiple entries. Each entry would have its own set of
	infomation pertaining to that failure type.		infomation pertaining to that failure type.
	4.1. Report Time-frame		4.1. Report Time-frame
	The report SHOULD cover a full day, from 0000-2400 UTC. This should		The report SHOULD cover a full day, from 0000-2400 UTC. This should
	allow for easier correlation of failure events. To avoid a Denial of		allow for easier correlation of failure events. To avoid a Denial of
	Service against the system processing the reports, the reports should		Service against the system processing the reports, the reports should
	be delivered after some delay, perhaps several hours.		be delivered after some delay, perhaps several hours.
			As an example, a sending site might want to introduce a random delay
			of up to four hours:
			func generate_sleep_delay() {
			min_delay = 1
			max_delay = 14400
			rand = random(min_delay,max_delay)
			return rand
			}
			func generate_report(policy_domain) {
			do_rpt_work(policy_domain)
			send_rpt(policy_domain)
			}
			func generate_tlsrpt() {
			sleep(generate_sleep_delay())
			for policy_domain in list_of_tlsrpt_enabled_domains {
			generate_report(policy_domain)
			}
			}
			A sending site might wish to introduce a random delay per destination
			site, up to four hours:
			func generate_sleep_delay() {
			min_delay = 1
			max_delay = 14400
			rand = random(min_delay,max_delay)
			return rand
			}
			func generate_report(policy_domain) {
			sleep(generate_sleep_delay())
			do_rpt_work(policy_domain)
			send_rpt(policy_domain)
			}
			func generate_tlsrpt() {
			for policy_domain in list_of_tlsrpt_enabled_domains {
			generate_report(policy_domain)
			}
			}
	4.2. Delivery Summary		4.2. Delivery Summary
	4.2.1. Success Count		4.2.1. Success Count
	o "total-successful-session-count": This indicates that the sending		o "total-successful-session-count": This indicates that the sending
	MTA was able to successfully negotiate a policy-compliant TLS		MTA was able to successfully negotiate a policy-compliant TLS
	connection, and serves to provide a "heartbeat" to receiving		connection, and serves to provide a "heartbeat" to receiving
	domains that reporting is functional and tabulating correctly.		domains that reporting is functional and tabulating correctly.
	This field contains an aggregate count of successful connections		This field contains an aggregate count of successful connections
	for the reporting system.		for the reporting system.
	skipping to change at page 14, line 10 ¶		skipping to change at page 15, line 10 ¶
	]		]
	For MTA-STS policies, this is an array of JSON strings that		For MTA-STS policies, this is an array of JSON strings that
	represents the policy that is declared by the receiving site,		represents the policy that is declared by the receiving site,
	including any errors that may be present. Note that where there are		including any errors that may be present. Note that where there are
	multiple "mx" values, they must be listed as separate "mx" elements		multiple "mx" values, they must be listed as separate "mx" elements
	in the policy array, rather as a single nested "mx" sub-array.		in the policy array, rather as a single nested "mx" sub-array.
	[		[
	"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: 604800"
	]		]
	5. Report Delivery		5. Report Delivery
	Reports can be delivered either as an email message via SMTP or via		Reports can be delivered either as an email message via SMTP or via
	HTTP POST.		HTTP POST.
	5.1. Report Filename		5.1. Report Filename
	The filename is RECOMMENDED to be constructed using the following		The filename is RECOMMENDED to be constructed using the following
	ABNF:		ABNF:
	filename = sender "!" policy-domain "!" begin-timestamp		filename = sender "!" policy-domain "!" begin-timestamp
	"!" end-timestamp [ "!" unique-id ] "." extension		"!" end-timestamp [ "!" unique-id ] "." extension
	unique-id = 1*(ALPHA / DIGIT)		unique-id = 1*(ALPHA / DIGIT)
	sender = domain ; From the [RFC5321] that is used		sender = domain ; From the [RFC5321] that is used
	; as the domain for the `contact-info`		; as the domain for the `contact-info`
	; address in the report body		; address in the report body
	policy-domain = domain		policy-domain = domain
	begin-timestamp = 1*DIGIT		begin-timestamp = 1*DIGIT
	; seconds since 00:00:00 UTC January 1, 1970		; seconds since 00:00:00 UTC January 1, 1970
	; indicating start of the time range contained		; indicating start of the time range contained
	; in the report		; in the report
	end-timestamp = 1*DIGIT		end-timestamp = 1*DIGIT
	; seconds since 00:00:00 UTC January 1, 1970		; seconds since 00:00:00 UTC January 1, 1970
	; indicating end of the time range contained		; indicating end of the time range contained
	; in the report		; in the report
	extension = "json" / "json.gz"		extension = "json" / "json.gz"
	The extension MUST be "json" for a plain JSON file, or "json.gz" for		The extension MUST be "json" for a plain JSON file, or "json.gz" for
	a JSON file compressed using GZIP.		a JSON file compressed using GZIP.
	"unique-id" allows an optional unique ID generated by the Sending MTA		"unique-id" allows an optional unique ID generated by the Sending MTA
	to distinguish among multiple reports generated simultaneously by		to distinguish among multiple reports generated simultaneously by
	different sources within the same Policy Domain. For example, this		different sources within the same Policy Domain. For example, this
	is a possible filename for a compressed report to the Policy Domain		is a possible filename for a compressed report to the Policy Domain
	"example.net" from the Sending MTA "mail.sndr.example.com":		"example.net" from the Sending MTA "mail.sndr.example.com":
	skipping to change at page 16, line 10 ¶		skipping to change at page 17, line 10 ¶
	to process new message header fields and extract MIME parts with the		to process new message header fields and extract MIME parts with the
	prescribed media type and filename, and ignore the rest. These		prescribed media type and filename, and ignore the rest. These
	additional headers SHOULD be included in the DKIM [RFC6376] signature		additional headers SHOULD be included in the DKIM [RFC6376] signature
	for the message.		for the message.
	The [RFC5322].Subject field for report submissions SHOULD conform to		The [RFC5322].Subject field for report submissions SHOULD conform to
	the following ABNF:		the following ABNF:
	tlsrpt-subject = %s"Report" FWS ; "Report"		tlsrpt-subject = %s"Report" FWS ; "Report"
	%s"Domain:" FWS ; "Domain:"		%s"Domain:" FWS ; "Domain:"
	domain-name FWS ; per [RFC6376]		domain-name FWS ; per [RFC6376]
	%s"Submitter:" FWS ; "Submitter:"		%s"Submitter:" FWS ; "Submitter:"
	domain-name FWS ; per [RFC6376]		domain-name FWS ; per [RFC6376]
	%s"Report-ID:" FWS ; "Report-ID:		%s"Report-ID:" FWS ; "Report-ID:
	"<" id-left "@" id-right ">" ; per [RFC5322]		"<" id-left "@" id-right ">" ; per [RFC5322]
	[CFWS] ; per [RFC5322]		[CFWS] ; per [RFC5322]
	; (as with FWS)		; (as with FWS)
	The first domain-name indicates the DNS domain name about which the		The first domain-name indicates the DNS domain name about which the
	report was generated. The second domain-name indicates the DNS		report was generated. The second domain-name indicates the DNS
	domain name representing the Sending MTA generating the report. The		domain name representing the Sending MTA generating the report. The
	purpose of the Report-ID: portion of the field is to enable the		purpose of the Report-ID: portion of the field is to enable the
	Policy Domain to identify and ignore duplicate reports that might be		Policy Domain to identify and ignore duplicate reports that might be
	sent by a Sending MTA.		sent by a Sending MTA.
	For instance, this is a possible Subject field for a report to the		For instance, this is a possible Subject field for a report to the
	skipping to change at page 18, line 46 ¶		skipping to change at page 19, line 46 ¶
	Specification document(s): this one		Specification document(s): this one
	Header field name: TLS-Report-Submitter		Header field name: TLS-Report-Submitter
	Applicable protocol: mail		Applicable protocol: mail
	Status: standard		Status: standard
	Author/Change controller: IETF		Author/Change controller: IETF
	Specification document(s): this one		Specification document(s): this one
	6.2. Report Type		6.2. Report Type
	This document registers a new parameter "report-type="tlsrpt"" under		This document creates a new registry for "report-type" parameter to
	"multipart/report" top-level media type for use with [RFC6522].		the Content-Type header field for the "multipart/report" top-level
			media type defined in [RFC6522].
	The media type suitable for use as a report-type is defined in the		The registry name is "Report Type Registry", and the procedure for
	following section.		updating the registry will be "Specification Required".
			An entry in this registry should contain:
			o the report-type being registered
			o one or more registered media-types that can be used with this
			report-type
			o the document containing the registration action
			o an optional comment
			The initial entries are:
			Report-Type: tlsrpt
			Media Type: application/tlsrpt+gzip, application/tlsrpt+json
			Registered By: [RFCXXXX]
			Comment: Media types suitable for use with this report-type are defined in Sections 6.4 and 6.5 of [RFCXXXX]
			Report-Type: disposition-notification
			Media Type: message/disposition-notification
			Registered By: [@?RFC8098]
			Report-Type: disposition-notification
			Media Type: message/global-disposition-notification
			Registered By: [@?RFC6533]
			Report-Type: delivery-status
			Media Type: message/delivery-status
			Registered By: [@?RFC3464]
			Report-Type: delivery-status
			Media Type: message/global-delivery-status
			Registered By: [@?RFC6533]
	6.3. +gzip Media Type Suffix		6.3. +gzip Media Type Suffix
	This document registers a new media type suffix "+gzip". The GZIP		This document registers a new media type suffix "+gzip". The GZIP
	format is a public domain, cross-platform, interoperable file storage		format is a public domain, cross-platform, interoperable file storage
	and transfer format, specified in [RFC1952]; it supports compression		and transfer format, specified in [RFC1952]; it supports compression
	and is used as the underlying representation by a variety of file		and is used as the underlying representation by a variety of file
	formats. The media type "application/gzip" has been registered for		formats. The media type "application/gzip" has been registered for
	such files. The suffix "+gzip" MAY be used with any media type whose		such files. The suffix "+gzip" MAY be used with any media type whose
	representation follows that established for "application/gzip". The		representation follows that established for "application/gzip". The
	skipping to change at page 22, line 19 ¶		skipping to change at page 24, line 14 ¶
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: Internet Engineering Task Force		Change controller: Internet Engineering Task Force
	(mailto:iesg@ietf.org).		(mailto:iesg@ietf.org).
	6.6. STARTTLS Validation Result Types		6.6. STARTTLS Validation Result Types
	This document creates a new registry, "STARTTLS Validation Result		This document creates a new registry, "STARTTLS Validation Result
	Types". The initial entries in the registry are:		Types". The initial entries in the registry are:
	+-------------------------------+		+-------------------------------+-----------+
	| Result Type |		| Result Type | Desc |
	+-------------------------------+		+-------------------------------+-----------+
	| "starttls-not-supported" |		| "starttls-not-supported" | 4.3 |
	| "certificate-host-mismatch" |		| "certificate-host-mismatch" | 4.3 |
	| "certificate-expired" |		| "certificate-expired" | 4.3 |
	| "tlsa-invalid" |		| "tlsa-invalid" | 4.3 |
	| "dnssec-invalid" |		| "dnssec-invalid" | 4.3 |
	| "dane-required" |		| "dane-required" | 4.3 |
	| "certificate-not-trusted" |		| "certificate-not-trusted" | 4.3 |
	| "sts-policy-invalid" |		| "sts-policy-invalid" | 4.3 |
	| "sts-webpki-invalid" |		| "sts-webpki-invalid" | 4.3 |
	| "validation-failure" |		| "validation-failure" | 4.3 |
	+-------------------------------+		+-------------------------------+-----------+
	The above entries are described in section Section 4.3, "Result		The above entries are described in section Section 4.3, "Result
	Types." New result types can be added to this registry using "Expert		Types." New result types can be added to this registry using "Expert
	Review" IANA registration policy.		Review" IANA registration policy.
	7. Security Considerations		7. Security Considerations
	SMTP TLS Reporting provides transparency into misconfigurations or		SMTP TLS Reporting provides transparency into misconfigurations or
	attempts to intercept or tamper with mail between hosts who support		attempts to intercept or tamper with mail between hosts who support
	STARTTLS. There are several security risks presented by the		STARTTLS. There are several security risks presented by the
	skipping to change at page 24, line 12 ¶		skipping to change at page 26, line 7 ¶
	connections (by downgrading opportunistic encryption or, in the case		connections (by downgrading opportunistic encryption or, in the case
	of MTA-STS, preventing discovery of a new MTA-STS policy), we must		of MTA-STS, preventing discovery of a new MTA-STS policy), we must
	also consider the risk that an adversary who can induce such a		also consider the risk that an adversary who can induce such a
	downgrade attack can also prevent discovery of the TLSRPT TXT record		downgrade attack can also prevent discovery of the TLSRPT TXT record
	(and thus prevent discovery of the successful downgrade attack).		(and thus prevent discovery of the successful downgrade attack).
	Administrators are thus encouraged to deploy TLSRPT TXT records with		Administrators are thus encouraged to deploy TLSRPT TXT records with
	a large TTL (reducing the window for successful application of		a large TTL (reducing the window for successful application of
	transient attacks against DNS resolution of the record) or to deploy		transient attacks against DNS resolution of the record) or to deploy
	DNSSEC on the deploying zone.		DNSSEC on the deploying zone.
	8. References		8. Privacy Considerations
	8.1. Normative References		MTAs are generally considered public knowledge, however, the
			internals of how those MTAs are configured and the users of those
			MTAs may not be as public. It should be noted that when providing a
			receiving site with information, it may reveal information about the
			sender's configuration, or even information about the senders
			themselves. Consider that by sending a report, it might disclose
			your SSL library version as the inability to negotiate a session may
			be a known incompatbility between two library versions, or perhaps
			commonly used in a operating system release that is centered in a
			certain region. The risk may be minimal, but should be considered.
			9. References
			9.1. Normative References
	[I-D.ietf-uta-mta-sts]		[I-D.ietf-uta-mta-sts]
	Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,		Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
	and J. Jones, "SMTP MTA Strict Transport Security (MTA-		and J. Jones, "SMTP MTA Strict Transport Security (MTA-
	STS)", draft-ietf-uta-mta-sts-15 (work in progress), April		STS)", draft-ietf-uta-mta-sts-17 (work in progress), May
	2018.		2018.
	[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",		[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
	RFC 1952, DOI 10.17487/RFC1952, May 1996,		RFC 1952, DOI 10.17487/RFC1952, May 1996,
	<https://www.rfc-editor.org/info/rfc1952>.		<https://www.rfc-editor.org/info/rfc1952>.
	[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, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	skipping to change at page 26, line 42 ¶		skipping to change at page 28, line 47 ¶
	[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, <https://www.rfc-
	editor.org/info/rfc7672>.		editor.org/info/rfc7672>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		9.2. Informative References
	[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>.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,		4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
	<https://www.rfc-editor.org/info/rfc3501>.		<https://www.rfc-editor.org/info/rfc3501>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	skipping to change at page 27, line 29 ¶		skipping to change at page 29, line 33 ¶
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based		[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
	Message Authentication, Reporting, and Conformance		Message Authentication, Reporting, and Conformance
	(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,		(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
	<https://www.rfc-editor.org/info/rfc7489>.		<https://www.rfc-editor.org/info/rfc7489>.
			9.3. URIs
			[1] Section 2.2.3
			[2] Section 3
	Appendix A. Example Reporting Policy		Appendix A. Example Reporting Policy
	A.1. Report using MAILTO		A.1. Report using MAILTO
	_smtp._tls.mail.example.com. IN TXT \		_smtp._tls.mail.example.com. IN TXT \
	"v=TLSRPTv1;rua=mailto:reports@example.com"		"v=TLSRPTv1;rua=mailto:reports@example.com"
	A.2. Report using HTTPS		A.2. Report using HTTPS
	_smtp._tls.mail.example.com. IN TXT \		_smtp._tls.mail.example.com. IN TXT \
	skipping to change at page 28, line 16 ¶		skipping to change at page 31, line 16 ¶
	"organization-name": "Company-X",		"organization-name": "Company-X",
	"date-range": {		"date-range": {
	"start-datetime": "2016-04-01T00:00:00Z",		"start-datetime": "2016-04-01T00:00:00Z",
	"end-datetime": "2016-04-01T23:59:59Z"		"end-datetime": "2016-04-01T23:59:59Z"
	},		},
	"contact-info": "sts-reporting@company-x.example",		"contact-info": "sts-reporting@company-x.example",
	"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",		"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
	"policies": [{		"policies": [{
	"policy": {		"policy": {
	"policy-type": "sts",		"policy-type": "sts",
	"policy-string": ["version: STSv1","mode: report",		"policy-string": ["version: STSv1","mode: testing",
	"mx: .mail.company-y.example","max_age: 86400"],		"mx: *.mail.company-y.example","max_age: 86400"],
	"policy-domain": "company-y.example",		"policy-domain": "company-y.example",
	"mx-host": ".mail.company-y.example"		"mx-host": "*.mail.company-y.example"
	},		},
	"summary": {		"summary": {
	"total-successful-session-count": 5326,		"total-successful-session-count": 5326,
	"total-failure-session-count": 303		"total-failure-session-count": 303
	},		},
	"failure-details": [{		"failure-details": [{
	"result-type": "certificate-expired",		"result-type": "certificate-expired",
	"sending-mta-ip": "2001:db8:abcd:0012::1",		"sending-mta-ip": "2001:db8:abcd:0012::1",
	"receiving-mx-hostname": "mx1.mail.company-y.example",		"receiving-mx-hostname": "mx1.mail.company-y.example",
	"failed-session-count": 100		"failed-session-count": 100
End of changes. 33 change blocks.
	99 lines changed or deleted		204 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/