draft-ietf-uta-smtp-tlsrpt-02.txt		draft-ietf-uta-smtp-tlsrpt-03.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: June 18, 2017 Comcast, Inc		Expires: August 19, 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
	December 15, 2016		February 15, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-02		draft-ietf-uta-smtp-tlsrpt-03
	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 SMTP MTA STS (TODO: Add ref). These protocols can
	fail due to misconfiguration or active attack, leading to undelivered		fail due to misconfiguration or active attack, leading to undelivered
	messages or delivery over unencrypted or unauthenticated channels.		messages or delivery over unencrypted or unauthenticated channels.
	This document describes a reporting mechanism and format by which		This document describes a reporting mechanism and format by which
	sending systems can share statistics and specific information about		sending systems can share statistics and specific information about
	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 June 18, 2017.		This Internet-Draft will expire on August 19, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 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".
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA		SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA
	failures.		failures.
	o "ruf": Future use. (There may also be a need for enabling more		o "ruf": Future use. (There may also be a need for enabling more
	detailed "forensic" reporting during initial stages of a		detailed "forensic" reporting during initial stages of a
	deployment. To address this, the authors consider the possibility		deployment. To address this, the authors consider the possibility
	of an optional additional "forensic reporting mode" in which more		of an optional additional "forensic reporting mode" in which more
	details--such as certificate chains and MTA banners--may be		details--such as certificate chains and MTA banners--may be
	reported.)		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 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	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": {
End of changes. 13 change blocks.
	13 lines changed or deleted		13 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/