draft-ietf-uta-smtp-tlsrpt-12.txt   draft-ietf-uta-smtp-tlsrpt-13.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: June 7, 2018 Comcast, Inc Expires: June 7, 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
December 4, 2017 December 4, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-12 draft-ietf-uta-smtp-tlsrpt-13
Abstract Abstract
A number of protocols exist for establishing encrypted channels A number of protocols exist for establishing encrypted channels
between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
MTA-STS. These protocols can fail due to misconfiguration or active MTA-STS. These protocols can fail due to misconfiguration or active
attack, leading to undelivered messages or delivery over unencrypted attack, leading to undelivered messages or delivery over unencrypted
or unauthenticated channels. This document describes a reporting or unauthenticated channels. This document describes a reporting
mechanism and format by which sending systems can share statistics mechanism and format by which sending systems can share statistics
and specific information about potential failures with recipient and specific information about potential failures with recipient
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 12 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 23 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 24
A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 23 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 24
A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 23 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 24
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 23 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 38 skipping to change at page 5, line 38
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-field = tlsrpt-rua / ; Note that the
tlsrpt-extension ; tlsrpt-rua record is tlsrpt-extension ; tlsrpt-rua record is
; required. ; required.
tlsrpt-version = %s"v=TLSRPTv1" tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-rua = %s"rua=" tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI tlsrpt-uri = URI
; "URI" is imported from [@!RFC3986]; ; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation ; commas (ASCII 0x2C) and exclamation
; points (ASCII 0x21) MUST be encoded ; points (ASCII 0x21) MUST be encoded
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
DIGIT / "_" / "-" / ".") DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control ; chars excluding "=", ";", SP, and control
skipping to change at page 13, line 10 skipping to change at page 13, line 10
5.1. Report Filename 5.1. Report Filename
The filename is RECOMMENDED to be constructed using the following The filename is RECOMMENDED to be constructed using the following
ABNF: ABNF:
filename = sender "!" policy-domain "!" begin-timestamp filename = sender "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension "!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT) unique-id = 1*(ALPHA / DIGIT)
sender = domain ; From the [@!RFC5321] that is used sender = domain ; From the [RFC5321] that is used
; as the domain for the `contact-info` ; as the domain for the `contact-info`
; address in the report body ; address in the report body
policy-domain = domain policy-domain = domain
begin-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained ; indicating start of the time range contained
; in the report ; in the report
skipping to change at page 14, line 15 skipping to change at page 14, line 15
Inside it, there are two parts: The first part is human readable, Inside it, there are two parts: The first part is human readable,
typically "text/plain", and the second part is machine readable with typically "text/plain", and the second part is machine readable with
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-Submitter: Sender- "TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender-
Domain" The "TLS-Report-Submitter" value MUST match the value found Domain"
in the filename and the [RFC5321] domain from the "contact-info" from
the report body. These message headers MUST be included and should The "TLS-Report-Submitter" value MUST match the value found in the
allow for easy searching for all reports submitted by a report domain filename and the [RFC5321] domain from the "contact-info" from the
or a particular submitter, for example in IMAP [RFC3501]: report body. These message headers MUST be included and should allow
for easy searching for all reports submitted by a report domain or a
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. These prescribed media type and filename, and ignore the rest. These
additional headers SHOULD be included in the DKIM [RFC6376] signature additional headers SHOULD be included in the DKIM [RFC6376] signature
for the message. for the message.
The [RFC5322].Subject field for report submissions SHOULD conform to The [RFC5322].Subject field for report submissions SHOULD conform to
the following ABNF: the following ABNF:
tlsrpt-subject = %s"Report" FWS ; "Report" tlsrpt-subject = %s"Report" FWS ; "Report"
%s"Domain:" FWS ; "Domain:" %s"Domain:" FWS ; "Domain:"
domain-name FWS ; per RFC6376 domain-name FWS ; per [RFC6376]
%s"Submitter:" FWS ; "Submitter:" %s"Submitter:" FWS ; "Submitter:"
domain-name FWS ; per RFC6376 domain-name FWS ; per [RFC6376]
%s"Report-ID:" FWS ; "Report-ID: %s"Report-ID:" FWS ; "Report-ID:
"<" id-left "@" id-right ">" ; per RFC5322 "<" id-left "@" id-right ">" ; per [RFC5322]
[CFWS] ; per RFC5322 [CFWS] ; per [RFC5322]
; (as with FWS) ; (as with FWS)
The first domain-name indicates the DNS domain name about which the The first domain-name indicates the DNS domain name about which the
report was generated. The second domain-name indicates the DNS report was generated. The second domain-name indicates the DNS
domain name representing the Sending MTA generating the report. The domain name representing the Sending MTA generating the report. The
purpose of the Report-ID: portion of the field is to enable the purpose of the Report-ID: portion of the field is to enable the
Policy Domain to identify and ignore duplicate reports that might be Policy Domain to identify and ignore duplicate reports that might be
sent by a Sending MTA. sent by a Sending MTA.
For instance, this is a possible Subject field for a report to the For instance, this is a possible Subject field for a report to the
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]:
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>
5.3.1. Example Report 5.3.1. Example Report
From: tlsrpt@mail.sender.example.com From: tlsrpt@mail.sender.example.com
Date: Fri, May 09 2017 16:54:30 -0800 Date: Fri, May 09 2017 16:54:30 -0800
To: mts-sts-tlsrpt@example.net To: mts-sts-tlsrpt@example.net
Subject: Report Domain: example.net Subject: Report Domain: example.net
 End of changes. 11 change blocks. 
19 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/