draft-ietf-uta-smtp-tlsrpt-08.txt		draft-ietf-uta-smtp-tlsrpt-09.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: February 16, 2018 Comcast, Inc		Expires: March 9, 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
	August 15, 2017		September 5, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-08		draft-ietf-uta-smtp-tlsrpt-09
	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 February 16, 2018.		This Internet-Draft will expire on March 9, 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 37 ¶		skipping to change at page 2, line 37 ¶
	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 . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
	5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14		5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
	5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 15		5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15		6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15		6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 16		6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
	6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 17		6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
	6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18		6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19		8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 20
	8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19		8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 20
	8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19		8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 20
	9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19		9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	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 20 ¶		skipping to change at page 5, line 20 ¶
	specified email address ([RFC6068]). When sending failure reports		specified email address ([RFC6068]). When sending failure reports
	via SMTP, sending MTAs MUST deliver reports despite any TLS-		via SMTP, sending MTAs MUST deliver reports despite any TLS-
	related failures. This may mean that the reports are delivered in		related failures. This may mean that the reports are delivered in
	the clear. Additionally, reports sent via SMTP MUST contain a		the clear. Additionally, reports sent via SMTP MUST contain a
	valid DKIM [RFC6376] signature by the reporting domain. Reports		valid DKIM [RFC6376] signature by the reporting domain. Reports
	lacking such a signature MUST be ignored by the recipient.		lacking such a signature MUST be ignored by the recipient.
	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 1*(field-delim tlsrpt-field)
	[field-delim [tlsrpt-extensions]]		[field-delim]
	field-delim = %x3B ; ";"		field-delim = *WSP ";" *WSP
	tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52		tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-rua
	%x50 %x54 %x76 %x31 ; "v=TLSRPTv1"		tlsrpt-extension ; record is required.
	tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP		tlsrpt-version = %s"v=TLSRPTv1"
	tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) ; "rua=..."
			tlsrpt-rua = %s"rua="
			tlsrpt-uri *(*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
	; within an unsigned 64-bit integer
	tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
	[field-delim]
	; extension fields
	tlsrpt-extension = tlsrpt-ext-name *WSP "=" *WSP tlsrpt-ext-value		tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
	tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")		tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")
	tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding		tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding
	; "=", ";", SP, and		; "=", ";", SP, and
	; control chars		; control chars
	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. Parsers		MUST assume the recipient domain does not implement TLSRPT. If the
	MUST accept TXT records which are syntactically valid (i.e. valid		resulting TXT record contains multiple strings, then the record MUST
	key-value pairs seprated by semi-colons) and implementing a superset		be treated as if those strings are concatenated together without
	of this specification, in which case unknown fields SHALL be ignored.		adding spaces.
			Parsers MUST accept TXT records which are syntactically valid (i.e.
			valid key-value pairs separated by semi-colons) and implementing a
			superset of this specification, in which case unknown fields SHALL be
			ignored.
	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 I-JSON		The report is composed as a plain text file encoded in the I-JSON
	format ([RFC7493]).		format ([RFC7493]).
	Aggregate reports contain the following fields:		Aggregate reports contain the following fields:
	o Report metadata:		o Report metadata:
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 47 ¶
	Note that, when sending failure reports via SMTP, sending MTAs MUST		Note that, when sending failure reports via SMTP, sending MTAs MUST
	NOT honor MTA-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/tlsrpt+gzip", and		report SHOULD use the media type "application/tlsrpt+gzip", and
	"application/tlsrpt+json" otherwise (see section Section 6, "IANA		"application/tlsrpt+json" otherwise (see section Section 6, "IANA
	Considerations").		Considerations").
			A reporting entity SHOULD expect a "successful" response from the
			accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
			Other codes could indicate a delivery failure, and may be retried as
			per local policy. The receiving system is not expected to process
			reports at receipt time, and MAY store them for processing at a later
			time.
	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
	method, a sender SHOULD attempt redelivery for up to 24hrs after the		method, a sender SHOULD attempt redelivery for up to 24hrs after the
	initial attempt. As previously stated the reports are optional, so		initial attempt. As previously stated the reports are optional, so
	while it is ideal to attempt redelivery, it is not required. If		while it is ideal to attempt redelivery, it is not required. If
	multiple retries are attempted, ideally they would be on a		multiple retries are attempted, ideally they would be on a
	logarithmic scale.		logarithmic scale.
	5.6. Metadata Variances		5.6. Metadata Variances
	skipping to change at page 20, line 43 ¶		skipping to change at page 21, line 43 ¶
	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",
	"failed-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-
	Company-Y, where 100 sessions were attempted to Company Y servers		Y, where 100 sessions were attempted to Company Y servers with an
	with an expired certificate and 200 sessions were attempted to		expired certificate and 200 sessions were attempted to Company Y
	Company Y servers that did not successfully respond to the "STARTTLS"		servers that did not successfully respond to the "STARTTLS" command.
	command. Additionally 3 sessions failed due to		Additionally 3 sessions failed due to
	"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".		"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2818>.		editor.org/info/rfc2818>.
	[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>.		<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode		[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications		for Internationalized Domain Names in Applications
	(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,		(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<http://www.rfc-editor.org/info/rfc3492>.		<https://www.rfc-editor.org/info/rfc3492>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66,
	3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<https://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,
	RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5234>.		editor.org/info/rfc5234>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5321>.		editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5322>.		editor.org/info/rfc5322>.
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/		Applications (IDNA): Protocol", RFC 5891,
	RFC5891, August 2010,		DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5891>.		editor.org/info/rfc5891>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6		[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952, DOI 10.17487/		Address Text Representation", RFC 5952,
	RFC5952, August 2010,		DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5952>.		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>.		<https://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, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,		[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", STD 76,		"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
	RFC 6376, DOI 10.17487/RFC6376, September 2011,		RFC 6376, DOI 10.17487/RFC6376, September 2011,
	<http://www.rfc-editor.org/info/rfc6376>.		<https://www.rfc-editor.org/info/rfc6376>.
	[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for		[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
	the Reporting of Mail System Administrative Messages", STD		the Reporting of Mail System Administrative Messages",
	73, RFC 6522, DOI 10.17487/RFC6522, January 2012,		STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
	<http://www.rfc-editor.org/info/rfc6522>.		<https://www.rfc-editor.org/info/rfc6522>.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
	2012, <http://www.rfc-editor.org/info/rfc6698>.		2012, <https://www.rfc-editor.org/info/rfc6698>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <https://www.rfc-editor.org/info/rfc7159>.
	[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI		[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
	10.17487/RFC7493, March 2015,		DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc7493>.		editor.org/info/rfc7493>.
	10.2. Informative References		10.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, <http://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,
	<http://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
	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, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc3864>.		editor.org/info/rfc3864>.
			[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
			DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
			editor.org/info/rfc7231>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <http://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	[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, <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,
	<http://www.rfc-editor.org/info/rfc7489>.		<https://www.rfc-editor.org/info/rfc7489>.
	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. 41 change blocks.
	98 lines changed or deleted		112 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/