draft-ietf-uta-smtp-tlsrpt-03.txt		draft-ietf-uta-smtp-tlsrpt-04.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: August 19, 2017 Comcast, Inc		Expires: October 5, 2017 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
	February 15, 2017		April 3, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-03		draft-ietf-uta-smtp-tlsrpt-04
	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 SMTP MTA STS (TODO: Add ref). These protocols can		[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
	fail due to misconfiguration or active attack, leading to undelivered		to misconfiguration or active attack, leading to undelivered messages
	messages or delivery over unencrypted or unauthenticated channels.		or delivery over unencrypted or unauthenticated channels. This
	This document describes a reporting mechanism and format by which		document describes a reporting mechanism and format by which sending
	sending systems can share statistics and specific information about		systems can share statistics and specific information about potential
	potential failures with recipient domains. Recipient domains can		failures with recipient domains. Recipient domains can then use this
	then use this information to both detect potential attackers and		information to both detect potential attackers and diagnose
	diagnose unintentional misconfigurations.		unintentional misconfigurations.
	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 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 August 19, 2017.		This Internet-Draft will expire on October 5, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	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 . . . . . . . . . . . . . . . . 5
	3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5		3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5
	3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5		3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5
	4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6		4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6		4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6
	4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7		4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7		4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 6
	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. Routing Failures . . . . . . . . . . . . . . . . . . 7		4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7
	4.3.2. Negotiation Failures . . . . . . . . . . . . . . . . 7		4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 7
	4.3.3. Policy Failures . . . . . . . . . . . . . . . . . . . 8		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8
	4.3.4. General Failures . . . . . . . . . . . . . . . . . . 8		4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 8
	4.3.5. Transient Failures . . . . . . . . . . . . . . . . . 8
	5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 9		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 10		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 9
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 11		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 12		8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 11
	8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 12		8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 11
	8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12		8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12
	9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12		9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12
	10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 15		10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 14
	11. Normative References . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	provides interoperability for 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
	delivery domain) can perform a downgrade or interception attack.		delivery domain) can perform a downgrade or interception attack.
	Because such "downgrade attacks" are not necessarily apparent to the		Because such "downgrade attacks" are not necessarily apparent to the
	receiving MTA, this document defines a mechanism for sending domains		receiving MTA, this document defines a mechanism for sending domains
	to report on failures at multiple parts of the MTA-to-MTA		to report on failures at multiple stages of the MTA-to-MTA
	conversation.		conversation.
	Recipient domains may also use the mechanisms defined by MTA-STS		Recipient domains may also use the mechanisms defined by MTA-STS
	(TODO: Add ref) or DANE [RFC6698] to publish additional encryption		(TODO: Add ref) or DANE [RFC6698] to publish additional encryption
	and authentication requirements; this document defines a mechanism		and authentication requirements; this document defines a mechanism
	for sending domains that are compatible with MTA-STS or DANE to share		for sending domains that are compatible with MTA-STS or DANE to share
	success and failure statistics with recipient domains.		success and failure statistics with recipient domains.
	Specifically, this document defines a reporting schema that covers		Specifically, this document defines a reporting schema that covers
	failures in routing, STARTTLS negotiation, and both DANE [RFC6698]		failures in routing, STARTTLS negotiation, and both DANE [RFC6698]
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 45 ¶
	SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).		SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).
	1.1. Terminology		1.1. Terminology
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
	document, are to be interpreted as described in [RFC2119].		document, are to be interpreted as described in [RFC2119].
	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 STS Policy: A definition of the expected TLS availability,		o MTA-STS Policy: A definition of the expected TLS availability,
	behavior, and desired actions for a given domain when a sending		behavior, and desired actions for a given domain when a sending
	MTA encounters problems in negotiating a secure channel. STS is		MTA encounters problems in negotiating a secure channel. MTA-STS
	defined in [TODO]		is defined in [TODO]
	o DANE Policy: A mechanism for enabling the administrators of domain		o DANE Policy: A mechanism by which administrators can supply a
	names to specify the keys used in that domain's TLS servers. DANE		record that can be used to validate the certificate presented by
	is defined in [RFC6698]		an MTA. DANE is defined in [RFC6698].
	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 STS or DANE Policy is		o Policy Domain: The domain against which an MTA-STS or DANE Policy
	defined.		is defined.
	o Sending MTA: The MTA initiating the delivery of an email message.		o Sending MTA: The MTA initiating the delivery of an email message.
	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 (MTA-STS, TODO: Add ref).		SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).
	o The Public Key Pinning Extension for HTTP [RFC7469] contains a		o The Public Key Pinning Extension for HTTP [RFC7469] contains a
	JSON-based definition for reporting individual pin validation		JSON-based definition for reporting individual pin validation
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	o The Domain-based Message Authentication, Reporting, and		o The Domain-based Message Authentication, Reporting, and
	Conformance (DMARC) [RFC7489] contains an XML-based reporting		Conformance (DMARC) [RFC7489] contains an XML-based reporting
	format for aggregate and detailed email delivery errors.		format for aggregate and detailed email delivery errors.
	3. Reporting Policy		3. Reporting Policy
	A domain publishes a record to its DNS indicating that it wishes to		A domain publishes a record to its DNS indicating that it wishes to
	receive reports. These SMTP TLSRPT policies are distributed via DNS		receive reports. These SMTP TLSRPT policies are distributed via DNS
	from the Policy Domain's zone, as TXT records (similar to DMARC		from the Policy Domain's zone, as TXT records (similar to DMARC
	policies) under the name "smtp-tlsrpt". For example, for the Policy		policies) under the name "_smtp-tlsrpt". For example, for the Policy
	Domain "example.com", the recipient's TLSRPT policy can be retrieved		Domain "example.com", the recipient's TLSRPT policy can be retrieved
	from "smtp-tlsrpt.example.com".		from "_smtp-tlsrpt.example.com".
	Policies consist of the following directives:		Policies consist of the following directives:
	o "v": This value MUST be equal to "TLSRPTv1".		o "v": This value MUST be equal to "TLSRPTv1".
	o "rua": A URI specifying the endpoint to which aggregate		o "rua": A URI specifying the endpoint to which aggregate
	information about policy failures should be sent (see the section		information about policy failures should be sent (see the section
	_Reporting_ _Schema_ for more information). Two URI schemes are		_Reporting_ _Schema_ for more information). Two URI schemes are
	supported: "mailto" and "https".		supported: "mailto" and "https".
	* In the case of "https", reports should be submitted via POST		* In the case of "https", reports should be submitted via POST
	([RFC2818]) to the specified URI.		([RFC2818]) to the specified URI.
	* In the case of "mailto", reports should be submitted to the		* In the case of "mailto", reports should be submitted to the
	specified email address. When sending failure reports via		specified email address. When sending failure reports via
	SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA		SMTP, sending MTAs MUST deliver reports despite any TLS-related
	failures.		failures. This may mean that the reports are delivered in the
			clear.
	o "ruf": Future use. (There may also be a need for enabling more
	detailed "forensic" reporting during initial stages of a
	deployment. To address this, the authors consider the possibility
	of an optional additional "forensic reporting mode" in which more
	details--such as certificate chains and MTA banners--may be
	reported.)
	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 %x3B tlsrpt-rua		tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua
	tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53		tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53
	%x52 %x50 %x54 %x76 %x31		%x52 %x50 %x54 %x76 %x31
	tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri		tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri
	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
	If multiple TXT records for "smtp-tlsrpt" are returned by the		If multiple TXT records for "_smtp-tlsrpt" 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.		MUST assume the recipient domain does not implement TLSRPT.
	3.1. Example Reporting Policy		3.1. Example Reporting Policy
	3.1.1. Report using MAILTO		3.1.1. Report using MAILTO
	smtp-tlsrpt.example.com. IN TXT \		_smtp-tlsrpt.example.com. IN TXT \
	"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 JSON
	format ([RFC7159]).		format ([RFC7159]).
	Aggregate reports contain the following fields:		Aggregate reports contain the following fields:
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 4 ¶
	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 JSON
	format ([RFC7159]).		format ([RFC7159]).
	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
	* A unique identifier for the report		* A unique identifier for the report
	* The reporting date range for the report		* The reporting date range for the report
	o Policy, consisting of:		o Policy, consisting of:
	* One of the following policy types: (1) The SMTP MTA STS policy		* One of the following policy types: (1) The MTA-STS policy
	applied (as a string) (2) The DANE TLSA record applied (as a		applied (as a string) (2) The DANE TLSA record applied (as a
	string) (3) The literal string "no-policy-found", if neither a		string, with each RR entry of the RRset listed and separated by
	TLSA nor MTA-STS policy could be found.		a semicolon) (3) The literal string "no-policy-found", if
			neither a TLSA nor MTA-STS policy could be found.
	* The domain for which the policy is applied		* The domain for which the policy is applied
	* The MX host		* The MX host
	* An identifier for the policy (where applicable)		* An identifier for the policy (where applicable)
	o Aggregate counts, comprising result type, sending MTA IP,		o Aggregate counts, comprising result type, sending MTA IP,
	receiving MTA hostname, session count, and an optional additional		receiving MTA hostname, session count, and an optional additional
	information field containing a URI for recipients to review		information field containing a URI for recipients to review
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 19 ¶
	The "Result Types" section will elaborate on the failed		The "Result Types" section will elaborate on the failed
	negotiation attempts. This field contains an aggregate count of		negotiation attempts. This field contains an aggregate count of
	failed connections.		failed connections.
	4.3. Result Types		4.3. Result Types
	The list of result types will start with the minimal set below, and		The list of result types will start with the minimal set below, and
	is expected to grow over time based on real-world experience. The		is expected to grow over time based on real-world experience. The
	initial set is:		initial set is:
	4.3.1. Routing Failures		4.3.1. Negotiation Failures
	o "mx-mismatch": This indicates that the MX resolved for the
	recipient domain did not match the MX constraint specified in the
	policy.
	4.3.2. Negotiation Failures
	o "starttls-not-supported": This indicates that the recipient MX did		o "starttls-not-supported": This indicates that the recipient MX did
	not support STARTTLS.		not support STARTTLS.
	o "certificate-host-mismatch": This indicates that the certificate		o "certificate-host-mismatch": This indicates that the certificate
	presented did not adhere to the constraints specified in the STS		presented did not adhere to the constraints specified in the MTA-
	or DANE policy, e.g. if the CN field did not match the hostname		STS or DANE policy, e.g. if the MX does not match any identities
	of the MX.		listed in the Subject Alternate Name (SAN) [RFC5280].
	o "certificate-expired": This indicates that the certificate has		o "certificate-expired": This indicates that the certificate has
	expired.		expired.
	o "certificate-not-trusted": This a label that covers multiple		o "certificate-not-trusted": This a label that covers multiple
	certificate related failures that include, but not limited to		certificate related failures that include, but not limited to
	errors such as untrusted/unknown CAs, certificate name contraints,		errors such as untrusted/unknown CAs, certificate name
	certificate chain errors etc. When using this declaration, the		constraints, certificate chain errors etc. When using this
	reporting MTA SHOULD utilize the "failure-reason" to provide more		declaration, the reporting MTA SHOULD utilize the "failure-reason"
	information to the receiving entity.		to provide more information to the receiving entity.
	o "validation-failure": This indicates a general failure for a		o "validation-failure": This indicates a general failure for a
	reason not matching a category above. When using this		reason not matching a category above. When using this
	declaration, the reporting MTA SHOULD utilize the "failure-reason"		declaration, the reporting MTA SHOULD utilize the "failure-reason"
	to provide more information to the receiving entity.		to provide more information to the receiving entity.
	4.3.3. Policy Failures		4.3.2. Policy Failures
	4.3.3.1. DANE-specific Policy Failures		4.3.2.1. DANE-specific Policy Failures
	o "tlsa-invalid": This indicates a validation error in the TLSA		o "tlsa-invalid": This indicates a validation error in the TLSA
	record associated with a DANE policy.		record associated with a DANE policy. None of the records in the
			RRset were found to be valid.
	o "dnssec-invalid": This indicates a failure to authenticate DNS		o "dnssec-invalid": This would indicate that no valid records were
	records for a Policy Domain with a published TLSA record.		returned from the recursive resolver. The request returned with
			SERVFAIL for the requested TLSA record.
	4.3.3.2. STS-specific Policy Failures		4.3.2.2. MTA-STS-specific Policy Failures
	o "sts-invalid": This indicates a validation error for the overall		o "sts-invalid": This indicates a validation error for the overall
	MTA-STS policy.		MTA-STS policy.
	o "webpki-invalid": This indicates that the MTA-STS policy could not		o "webpki-invalid": This indicates that the MTA-STS policy could not
	be authenticated using PKIX validation.		be authenticated using PKIX validation.
	4.3.4. General Failures		4.3.3. General Failures
	When a negotiation failure can not be categorized into one of the		When a negotiation failure can not be categorized into one of the
	"Negotiation Failures" stated above, the reporter SHOULD use the		"Negotiation Failures" stated above, the reporter SHOULD use the
	"validation-failure" category. As TLS grows and becomes more		"validation-failure" category. As TLS grows and becomes more
	complex, new mechanisms may not be easily categorized. This allows		complex, new mechanisms may not be easily categorized. This allows
	for a generic feedback category. When this category is used, the		for a generic feedback category. When this category is used, the
	reporter SHOULD also use the "failure-reason-code" to give some		reporter SHOULD also use the "failure-reason-code" to give some
	feedback to the receiving entity. This is intended to be a short		feedback to the receiving entity. This is intended to be a short
	text field, and the contents of the field should be an error code or		text field, and the contents of the field should be an error code or
	error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".		error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".
	4.3.5. 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.
	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
	skipping to change at page 10, line 43 ¶		skipping to change at page 10, line 36 ¶
	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
	"mail.sender.example.com". It is line-wrapped as allowed by		"mail.sender.example.com". It is line-wrapped as allowed by
	[RFC5322]:		[RFC5322]:
	Subject: Report Domain: example.net		Subject: Report Domain: example.net
	Submitter: mail.sender.example.com		Submitter: mail.sender.example.com
	Report-ID: <735ff.e317+bf22029@mailexample.net>		Report-ID: <735ff.e317+bf22029@mailexample.net>
	Note that, when sending failure reports via SMTP, sending MTAs MUST		Note that, when sending failure reports via SMTP, sending MTAs MUST
	NOT honor SMTP STS or DANE TLSA failures.		NOT honor MTA-STS or DANE TLSA failures.
	5.4. HTTPS Transport		5.4. HTTPS Transport
	The report MAY be delivered by POST to HTTPS. If compressed, the		The report MAY be delivered by POST to HTTPS. If compressed, the
	report should use the media type "application/gzip" (see [RFC6713]),		report should use the media type "application/gzip" (see [RFC6713]),
	and "text/json" otherwise.		and "text/json" otherwise.
	5.5. Delivery Retry		5.5. Delivery Retry
	In the event of a delivery failure, regardless of the delivery		In the event of a delivery failure, regardless of the delivery
	skipping to change at page 12, line 11 ¶		skipping to change at page 11, line 50 ¶
	DMARC [RFC7489] defines an elegant solution for verifying		DMARC [RFC7489] defines an elegant solution for verifying
	delegation; however, since the attacker had less ability to		delegation; however, since the attacker had less ability to
	generate large reports than with DMARC failures, and since the		generate large reports than with DMARC failures, and since the
	reports are generated by the sending MTA, such a delegation		reports are generated by the sending MTA, such a delegation
	mechanism is left for a future version of this specification.		mechanism is left for a future version of this specification.
	8. Appendix 1: Example Reporting Policy		8. Appendix 1: Example Reporting Policy
	8.1. Report using MAILTO		8.1. Report using MAILTO
	smtp-tlsrpt.mail.example.com. IN TXT \		_smtp-tlsrpt.mail.example.com. IN TXT \
	"v=TLSRPTv1;rua=mailto:reports@example.com"		"v=TLSRPTv1;rua=mailto:reports@example.com"
	8.2. Report using HTTPS		8.2. Report using HTTPS
	smtp-tlsrpt.mail.example.com. IN TXT \		_smtp-tlsrpt.mail.example.com. IN TXT \
	"v=TLSRPTv1; \		"v=TLSRPTv1; \
	rua=https://reporting.example.com/v1/tlsrpt"		rua=https://reporting.example.com/v1/tlsrpt"
	9. Appendix 2: JSON Report Schema		9. Appendix 2: 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,
	skipping to change at page 14, line 11 ¶		skipping to change at page 13, line 24 ¶
	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 string serialization of the policy, whether		o "policy-string": The string serialization of the policy, whether
	TLSA record or STS policy. Any linefeeds from the original policy		TLSA record or MTA-STS policy. Any linefeeds from the original
	MUST be replaced with [SP]. TODO: Help with specifics.		policy MUST be replaced with [SP]. TODO: Help with specifics.
	o "domain": The Policy Domain upon which the policy was applied.		o "domain": The Policy Domain upon which the policy was applied.
	For messages sent to "user@example.com" this field would contain		For messages sent to "user@example.com" this field would contain
	"example.com". It is provided as a string.		"example.com". It is provided as a string.
	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].
End of changes. 44 change blocks.
	82 lines changed or deleted		72 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/