draft-ietf-uta-smtp-tlsrpt-06.txt		draft-ietf-uta-smtp-tlsrpt-07.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: December 01, 2017 Comcast, Inc		Expires: February 1, 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 31, 2017		July 31, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-06		draft-ietf-uta-smtp-tlsrpt-07
	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 [RFC3207], DANE		between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
	[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due		[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
	to misconfiguration or active attack, leading to undelivered messages		to misconfiguration or active attack, leading to undelivered messages
	or delivery over unencrypted or unauthenticated channels. This		or delivery over unencrypted or unauthenticated channels. This
	document describes a reporting mechanism and format by which sending		document describes a reporting mechanism and format by which sending
	systems can share statistics and specific information about potential		systems can share statistics and specific information about potential
	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 26, 2017.		This Internet-Draft will expire on February 1, 2018.
	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 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4		2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
	3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4		3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5		3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6
	3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6		3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6
	3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6		3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6
	4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6		4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7		4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7
	4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7		4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7
	4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7		4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7
	4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7		4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7
	4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7
	4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7		4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7
	4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8		4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
	4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8
	4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9		4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9
	4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9		4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9
	5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12
	5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 13		5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 14		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15		6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15
	6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15		6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3. application/tlsrpt+* Media Types . . . . . . . . . . . . 15		6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 15
	6.4. STARTTLS Validation Result Types . . . . . . . . . . . . 16		6.4. application/tlsrpt+gz Media Type . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18
	8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 18
	8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 18		8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19
	9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 18		8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19
	10. Normative References . . . . . . . . . . . . . . . . . . . . 20		8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19
			10. Normative References . . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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 is based on "Opportunistic Security" (OS) [RFC7435], which		design is based on "Opportunistic Security" (OS) [RFC7435], which
	maintains interoperability with clients that do not support STARTTLS		maintains interoperability with clients that do not support STARTTLS
	but means that any attacker who can delete parts of the SMTP session		but means that any attacker who can delete parts of the SMTP session
	(such as the "250 STARTTLS" response) or redirect the entire SMTP		(such as the "250 STARTTLS" response) or redirect the entire SMTP
	session (perhaps by overwriting the resolved MX record of the		session (perhaps by overwriting the resolved MX record of the
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 20 ¶
	The formal definition of the "_smtp-tlsrpt" TXT record, defined using		The formal definition of the "_smtp-tlsrpt" TXT record, defined using
	[RFC5234], is as follows:		[RFC5234], is as follows:
	tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua		tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua
	[field-delim [tlsrpt-extensions]]		[field-delim [tlsrpt-extensions]]
	field-delim = %x3B ; ";"		field-delim = %x3B ; ";"
	tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52		tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52
	%x50 %x54 %x76 %x31 ; "v=TSRPTv1"		%x50 %x54 %x76 %x31 ; "v=TLSRPTv1"
	tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..."		tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..."
	tlsrpt-uri = URI		tlsrpt-uri = URI
	; "URI" is imported from [@!RFC3986]; commas (ASCII		; "URI" is imported from [@!RFC3986]; commas (ASCII
	; 0x2C) and exclamation points (ASCII 0x21)		; 0x2C) and exclamation points (ASCII 0x21)
	; MUST be encoded; the numeric portion MUST fit		; MUST be encoded; the numeric portion MUST fit
	; within an unsigned 64-bit integer		; within an unsigned 64-bit integer
	tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)		tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 20 ¶
	"v=TLSRPTv1;rua=mailto:reports@example.com"		"v=TLSRPTv1;rua=mailto:reports@example.com"
	3.1.2. Report using HTTPS		3.1.2. Report using HTTPS
	_smtp-tlsrpt.example.com. IN TXT \		_smtp-tlsrpt.example.com. IN TXT \
	"v=TLSRPTv1; \		"v=TLSRPTv1; \
	rua=https://reporting.example.com/v1/tlsrpt"		rua=https://reporting.example.com/v1/tlsrpt"
	4. Reporting Schema		4. Reporting Schema
	The report is composed as a plain text file encoded in the JSON		The report is composed as a plain text file encoded in the I-JSON
	format ([RFC7159]).		format ([RFC7493]).
	Aggregate reports contain the following fields:		Aggregate reports contain the following fields:
	o Report metadata:		o Report metadata:
	* The organization responsible for the report		* The organization responsible for the report
	* Contact information for one or more responsible parties for the		* Contact information for one or more responsible parties for the
	contents of the report		contents of the report
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 15 ¶
	4.3.4. Transient Failures		4.3.4. Transient Failures
	Transient errors due to too-busy network, TCP timeouts, etc. are not		Transient errors due to too-busy network, TCP timeouts, etc. are not
	required to be reported.		required to be reported.
	4.4. JSON Report Schema		4.4. JSON Report Schema
	The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.		The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.
	Section 3)		Section 3)
	{		{
	"organization-name": organization-name,		"organization-name": organization-name,
	"date-range": {		"date-range": {
	"start-datetime": date-time,		"start-datetime": date-time,
	"end-datetime": date-time		"end-datetime": date-time
	},		},
	"contact-info": email-address,		"contact-info": email-address,
	"report-id": report-id,		"report-id": report-id,
	"policy": {		"policy": {
	"policy-type": policy-type,		"policy-type": policy-type,
	"policy-string": policy-string,		"policy-string": policy-string,
	"policy-domain": domain,		"policy-domain": domain,
	"mx-host": mx-host-pattern		"mx-host": mx-host-pattern
	},		},
	"summary": {		"summary": {
	"success-aggregate": total-successful-session-count,		"total-successful-session-count": total-successful-session-count,
	"failure-aggregate:" total-failure-session-count		"total-failure-session-count:" total-failure-session-count
	}		}
	"failure-details": [		"failure-details": [
	{		{
	"result-type": result-type,		"result-type": result-type,
	"sending-mta-ip": ip-address,		"sending-mta-ip": ip-address,
	"receiving-mx-hostname": receiving-mx-hostname,		"receiving-mx-hostname": receiving-mx-hostname,
	"receiving-mx-helo": receiving-mx-helo,		"receiving-mx-helo": receiving-mx-helo,
	"session-count": failed-session-count,		"failed-session-count": failed-session-count,
	"additional-information": additional-info-uri,		"additional-information": additional-info-uri,
	"failure-reason-code": "Text body"		"failure-reason-code": "failure-reason-code"
	}		}
	]		]
	}		}
	JSON Report Format		JSON Report Format
	o "organization-name": The name of the organization responsible for		o "organization-name": The name of the organization responsible for
	the report. It is provided as a string.		the report. It is provided as a string.
	o "date-time": The date-time indicates the start- and end-times for		o "date-time": The date-time indicates the start- and end-times for
	the report range. It is provided as a string formatted according		the report range. It is provided as a string formatted according
	to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The		to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The
	report should be for a full UTC day, 0000-2400.		report should be for a full UTC day, 0000-2400.
	o "email-address": The contact information for a responsible party		o "email-address": The contact information for a responsible party
	of the report. It is provided as a string formatted according to		of the report. It is provided as a string formatted according to
	Section 3.4.1, "Addr-Spec", of [RFC5322].		Section 3.4.1, "Addr-Spec", of [RFC5321].
	o "report-id": A unique identifier for the report. Report authors		o "report-id": A unique identifier for the report. Report authors
	may use whatever scheme they prefer to generate a unique		may use whatever scheme they prefer to generate a unique
	identifier. It is provided as a string.		identifier. It is provided as a string.
	o "policy-type": The type of policy that was applied by the sending		o "policy-type": The type of policy that was applied by the sending
	domain. Presently, the only three valid choices are "tlsa",		domain. Presently, the only three valid choices are "tlsa",
	"sts", and the literal string "no-policy-found". It is provided		"sts", and the literal string "no-policy-found". It is provided
	as a string.		as a string.
	o "policy-string": The JSON string serialization ([RFC7159] section		o "policy-string": The JSON string serialization ([RFC7159] section
	7) of the policy, whether TLSA record ([RFC6698] section 2.3) or		7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
	MTA-STS policy.		MTA-STS policy.
	o "domain": The Policy Domain is the domain against which the MTA-		o "domain": The Policy Domain is the domain against which the MTA-
	STS or DANE policy is defined.		STS or DANE policy is defined. In the case of Internationalized
			Domain Names ([RFC5891]), the domain is the Punycode-encoded
			A-label ([RFC3492]) and not the U-label.
	o "mx-host-pattern": The pattern of MX hostnames from the applied		o "mx-host-pattern": The pattern of MX hostnames from the applied
	policy. It is provided as a string, and is interpreted in the		policy. It is provided as a string, and is interpreted in the
	same manner as the "Checking of Wildcard Certificates" rules in		same manner as the "Checking of Wildcard Certificates" rules in
	Section 6.4.3 of [RFC6125].		Section 6.4.3 of [RFC6125].
	o "result-type": A value from Section 4.3, "Result Types", above.		o "result-type": A value from Section 4.3, "Result Types", above.
			In the case of Internationalized Domain Names ([RFC5891]), the
			domain is the Punycode-encoded A-label ([RFC3492]) and not the
			U-label.
	o "ip-address": The IP address of the sending MTA that attempted the		o "ip-address": The IP address of the sending MTA that attempted the
	STARTTLS connection. It is provided as a string representation of		STARTTLS connection. It is provided as a string representation of
	an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal		an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or
	notation.		colon-hexadecimal notation.
	o "receiving-mx-hostname": The hostname of the receiving MTA MX		o "receiving-mx-hostname": The hostname of the receiving MTA MX
	record with which the sending MTA attempted to negotiate a		record with which the sending MTA attempted to negotiate a
	STARTTLS connection.		STARTTLS connection.
	o "receiving-mx-helo": (optional) The HELO or EHLO string from the		o "receiving-mx-helo": (optional) The HELO or EHLO string from the
	banner announced during the reported session.		banner announced during the reported session.
	o "success-aggregate": The aggregate number (integer) of		o "total-successful-session-count": The aggregate number (integer)
	successfully negotiated TLS-enabled connections to the receiving		of successfully negotiated TLS-enabled connections to the
	site.		receiving site.
	o "failure-aggregate": The aggregate number (integer) of failures to		o "total-failure-session-count": The aggregate number (integer) of
	negotiate an TLS-enabled connection to the receiving site.		failures to negotiate an TLS-enabled connection to the receiving
			site.
	o "session-count": The number of (attempted) sessions that match the		o "failed-session-count": The number of (attempted) sessions that
	relevant "result-type" for this section.		match the relevant "result-type" for this section.
	o "additional-info-uri": An optional URI pointing to additional		o "additional-info-uri": An optional URI [RFC3986] pointing to
	information around the relevant "result-type". For example, this		additional information around the relevant "result-type". For
	URI might host the complete certificate chain presented during an		example, this URI might host the complete certificate chain
	attempted STARTTLS session.		presented during an attempted STARTTLS session.
	o "failure-reason-code": A text field to include an TLS-related		o "failure-reason-code": A text field to include an TLS-related
	error code or error message.		error code or error message.
			For report purposes, an IPv4 Address is defined as: IPv4address =
			dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT
			; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34
			DIGIT ; 200-249 / "25" %x30-35 ; 250-255
	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 typically constructed using the following ABNF:		The filename is typically constructed using the following 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 ; imported from [@!RFC5322]		sender = domain ; imported from [@!RFC5321]
	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
	skipping to change at page 12, line 34 ¶		skipping to change at page 13, line 13 ¶
	a new media type defined called "application/tlsrpt+json". If		a new media type defined called "application/tlsrpt+json". If
	compressed, the report should use the media type "application/		compressed, the report should use the media type "application/
	tlsrpt+gzip".		tlsrpt+gzip".
	In addition, the following two new top level message header fields		In addition, the following two new top level message header fields
	are defined:		are defined:
	TLS-Report-Domain: Receiver-Domain		TLS-Report-Domain: Receiver-Domain
	TLS-Report-Submitter: Sender-Domain		TLS-Report-Submitter: Sender-Domain
	These message headers would allow for easy searching for all reports		These message headers MUST be included and should allow for easy
	submitted by a report domain or a particular submitter, for example		searching for all reports submitted by a report domain or a
	in IMAP:		particular submitter, for example in IMAP [RFC3501]:
	"s SEARCH HEADER "TLS-Report-Domain" "example.com""		"s SEARCH HEADER "TLS-Report-Domain" "example.com""
	It is presumed that the aggregate reporting address will be equipped		It is presumed that the aggregate reporting address will be equipped
	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.		prescribed media type and filename, and ignore the rest.
	The [RFC5322].Subject field for individual report submissions SHOULD		The [RFC5322].Subject field for individual report submissions SHOULD
	conform to the following ABNF:		conform to the following ABNF:
	tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"		tlsrpt-subject = %s"Report" FWS ; "Report"
	%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"		%s"Domain:" FWS ; "Domain:"
	domain-name 1*FWS ; from RFC 6376		domain-name FWS ; per RFC6376
	%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"		%s"Submitter:" FWS ; "Submitter:"
	1*FWS domain-name 1*FWS		domain-name FWS ; per RFC6376
	%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"		%s"Report-ID:" FWS ; "Report-ID:
	msg-id ; from RFC 5322		"<" id-left "@" id-right ">" ; per RFC5322
			[CFWS] ; per RFC5322 (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
	Policy Domain "example.net" from the Sending MTA		Policy Domain "example.net" from the Sending MTA
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 24 ¶
	6. IANA Considerations		6. IANA Considerations
	The following are the IANA considerations discussed in this document.		The following are the IANA considerations discussed in this document.
	6.1. Message headers		6.1. Message headers
	Below is the Internet Assigned Numbers Authority (IANA) Permanent		Below is the Internet Assigned Numbers Authority (IANA) Permanent
	Message Header Field registration information per [RFC3864].		Message Header Field registration information per [RFC3864].
	Header field name: TLS-Report-Domain		Header field name: TLS-Report-Domain
	Applicable protocol: smtp		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
	Header field name: TLS-Report-Submitter		Header field name: TLS-Report-Submitter
	Applicable protocol: smtp		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 registers a new parameter "report-type="tlsrpt"" under
	"multipart/report" top-level media type for use with [RFC6522].		"multipart/report" top-level media type for use with [RFC6522].
	The media type suitable for use as a report-type is defined in the		The media type suitable for use as a report-type is defined in the
	following section.		following section.
	6.3. application/tlsrpt+* Media Types		6.3. application/tlsrpt+json Media Type
	This document registers multiple media types, listed in Table 1		This document registers multiple media types, beginning with Table 1
	below.		below.
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	| Type | Subtype | File extn | Specification |		| Type | Subtype | File extn | Specification |
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	| application | tlsrpt+json | .json | Section 5.3 |		| application | tlsrpt+json | .json | Section 5.3 |
	| application | tlsrpt+gzip | .gz | Section 5.3 |
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	Table 1: SMTP TLS Reporting Media Types		Table 1: SMTP TLS Reporting Media Type
	Type name: application		Type name: application
	Subtype name: This documents registers multiple subtypes, as listed
	in Table 1.		Subtype name: tlsrpt+json
	Required parameters: n/a		Required parameters: n/a
	Optional parameters: n/a		Optional parameters: n/a
	Encoding considerations: Encoding considerations are identical to		Encoding considerations: Encoding considerations are identical to
	those specified for the "application/json" media type. See		those specified for the "application/json" media type. See
	[RFC7159].		[RFC7493].
	Security considerations: Security considerations relating to SMTP TLS		Security considerations: Security considerations relating to SMTP TLS
	Reporting are discussed in Section 7.		Reporting are discussed in Section 7.
	Interoperability considerations: This document specifies format of		Interoperability considerations: This document specifies format of
	conforming messages and the interpretation thereof.		conforming messages and the interpretation thereof.
	Published specification: This document is the specification for these		Published specification: Section 5.3 of this document.
	media types; see Table 1 for the section documenting each media type.
	Applications that use this media type: Mail User Agents (MUA) and		Applications that use this media type: Mail User Agents (MUA) and
	Mail Transfer Agents.		Mail Transfer Agents.
	Additional information:		Additional information:
	Magic number(s): n/a		Magic number(s): n/a
	File extension(s): As listed in Table 1.		File extension(s): ".json"
	Macintosh file type code(s): n/a		Macintosh file type code(s): n/a
	Person & email address to contact for further information: See		Person & email address to contact for further information: See
	Authors' Addresses section.		Authors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: n/a		Restrictions on usage: n/a
	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.4. STARTTLS Validation Result Types		6.4. application/tlsrpt+gz Media Type
			+-------------+----------------+-------------+-------------------+
			| Type | Subtype | File extn | Specification |
			+-------------+----------------+-------------+-------------------+
			| application | tlsrpt+gzip | .gz | Section 5.3 |
			+-------------+----------------+-------------+-------------------+
			Table 2: SMTP TLS Reporting Media Type
			Type name: application
			Subtype name: tlsrpt+gzip
			Required parameters: n/a
			Optional parameters: n/a
			Encoding considerations: Encoding considerations are identical to
			those specified for the "application/json" media type. See
			[RFC7493].
			Security considerations: Security considerations relating to SMTP TLS
			Reporting are discussed in Section 7.
			Interoperability considerations: This document specifies format of
			conforming messages and the interpretation thereof.
			Published specification: Section 5.3 of this document.
			Applications that use this media type: Mail User Agents (MUA) and
			Mail Transfer Agents.
			Additional information:
			Magic number(s): n/a
			File extension(s): ".gz"
			Macintosh file type code(s): n/a
			Person & email address to contact for further information: See
			Authors' Addresses section.
			Intended usage: COMMON
			Restrictions on usage: n/a
			Author: See Authors' Addresses section.
			Change controller: Internet Engineering Task Force
			(mailto:iesg@ietf.org).
			6.5. 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 |
	+-------------------------------+		+-------------------------------+
	| "starttls-not-supported" |		| "starttls-not-supported" |
	| "certificate-host-mismatch" |		| "certificate-host-mismatch" |
	| "certificate-expired" |		| "certificate-expired" |
	| "tlsa-invalid" |		| "tlsa-invalid" |
	| "dnssec-invalid" |		| "dnssec-invalid" |
	| "sts-policy-invalid" |		| "sts-policy-invalid" |
	| "sts-webpki-invalid" |		| "sts-webpki-invalid" |
	| "validation-failure" |		| "validation-failure" |
	+-------------------------------+		+-------------------------------+
	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 without the		Types." New result types can be added to this registry using "Expert
	need to update this document.		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
	existence of this reporting channel:		existence of this reporting channel:
	o Flooding of the Aggregate report URI (rua) endpoint: An attacker		o Flooding of the Aggregate report URI (rua) endpoint: An attacker
	could flood the endpoint with excessive reporting traffic and		could flood the endpoint with excessive reporting traffic and
	skipping to change at page 19, line 14 ¶		skipping to change at page 20, line 14 ¶
	{		{
	"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.com",		"contact-info": "sts-reporting@company-x.com",
	"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",		"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
	"policy": {		"policy": {
	"policy-type": "sts",		"policy-type": "sts",
	"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\"*.mail.company-y.com\"], \"max_age\": 86400 }",		"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }",
	"policy-domain": "company-y.com",		"policy-domain": "company-y.com",
	"mx-host": "*.mail.company-y.com"		"mx-host": ".mail.company-y.com"
	},		},
	"summary": {		"summary": {
	"success-aggregate": 5326,		"total-successful-session-count": 5326,
	"failure-aggregate": 303		"total-failure-session-count": 303
	}		}
	"failure-details": [{		"failure-details": [{
	"result-type": "certificate-expired",		"result-type": "certificate-expired",
	"sending-mta-ip": "98.136.216.25",		"sending-mta-ip": "98.136.216.25",
	"receiving-mx-hostname": "mx1.mail.company-y.com",		"receiving-mx-hostname": "mx1.mail.company-y.com",
	"session-count": 100		"failed-session-count": 100
	}, {		}, {
	"result-type": "starttls-not-supported",		"result-type": "starttls-not-supported",
	"sending-mta-ip": "98.22.33.99",		"sending-mta-ip": "98.22.33.99",
	"receiving-mx-hostname": "mx2.mail.company-y.com",		"receiving-mx-hostname": "mx2.mail.company-y.com",
	"session-count": 200,		"failed-session-count": 200,
	"additional-information": "hxxps://reports.company-x.com/		"additional-information": "hxxps://reports.company-x.com/
	report_info?id=5065427c-23d3#StarttlsNotSupported"		report_info?id=5065427c-23d3#StarttlsNotSupported"
	}, {		}, {
	"result-type: "validation-failure",		"result-type: "validation-failure",
	"sending-mta-ip": "47.97.15.2",		"sending-mta-ip": "47.97.15.2",
	"receiving-mx-hostname: "mx-backup.mail.company-y.com",		"receiving-mx-hostname: "mx-backup.mail.company-y.com",
	"session-count": 3,		"failed-session-count": 3,
	"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"		"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
	}]		}]
	}		}
	Figure: Example JSON report for a messages from Company-X to		Figure: Example JSON report for a messages from Company-X to
	Company-Y, where 100 sessions were attempted to Company Y servers		Company-Y, where 100 sessions were attempted to Company Y servers
	with an expired certificate and 200 sessions were attempted to		with an expired certificate and 200 sessions were attempted to
	Company Y servers that did not successfully respond to the "STARTTLS"		Company Y servers that did not successfully respond to the "STARTTLS"
	command. Additionally 3 sessions failed due to		command. Additionally 3 sessions failed due to
	"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".		"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
	skipping to change at page 20, line 24 ¶		skipping to change at page 21, line 24 ¶
	<http://www.rfc-editor.org/info/rfc2818>.		<http://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, <http://www.rfc-editor.org/info/rfc3207>.		February 2002, <http://www.rfc-editor.org/info/rfc3207>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<http://www.rfc-editor.org/info/rfc3339>.		<http://www.rfc-editor.org/info/rfc3339>.
			[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
			for Internationalized Domain Names in Applications
			(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
			<http://www.rfc-editor.org/info/rfc3492>.
			[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
			4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
			<http://www.rfc-editor.org/info/rfc3501>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<http://www.rfc-editor.org/info/rfc3864>.		<http://www.rfc-editor.org/info/rfc3864>.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66, RFC
			3986, DOI 10.17487/RFC3986, January 2005,
			<http://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
	RFC5234, January 2008,		RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
			[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
			DOI 10.17487/RFC5321, October 2008,
			<http://www.rfc-editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
	10.17487/RFC5322, October 2008,		10.17487/RFC5322, October 2008,
	<http://www.rfc-editor.org/info/rfc5322>.		<http://www.rfc-editor.org/info/rfc5322>.
			[RFC5891] Klensin, J., "Internationalized Domain Names in
			Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/
			RFC5891, August 2010,
			<http://www.rfc-editor.org/info/rfc5891>.
			[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
			Address Text Representation", RFC 5952, DOI 10.17487/
			RFC5952, August 2010,
			<http://www.rfc-editor.org/info/rfc5952>.
	[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'		[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
	URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,		URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
	<http://www.rfc-editor.org/info/rfc6068>.		<http://www.rfc-editor.org/info/rfc6068>.
	[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, <http://www.rfc-editor.org/info/rfc6125>.		2011, <http://www.rfc-editor.org/info/rfc6125>.
	skipping to change at page 21, line 27 ¶		skipping to change at page 23, line 10 ¶
	[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, <http://www.rfc-editor.org/info/rfc7469>.		2015, <http://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,
	<http://www.rfc-editor.org/info/rfc7489>.		<http://www.rfc-editor.org/info/rfc7489>.
			[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI
			10.17487/RFC7493, March 2015,
			<http://www.rfc-editor.org/info/rfc7493>.
	Authors' Addresses		Authors' Addresses
	Daniel Margolis		Daniel Margolis
	Google, Inc		Google, Inc
	Email: dmargolis (at) google.com		Email: dmargolis (at) google.com
	Alexander Brotman		Alexander Brotman
	Comcast, Inc		Comcast, Inc
End of changes. 48 change blocks.
	99 lines changed or deleted		194 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/