--- 1/draft-ietf-uta-smtp-tlsrpt-12.txt 2017-12-04 08:13:11.023321586 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-13.txt 2017-12-04 08:13:11.075322817 -0800 @@ -5,21 +5,21 @@ Expires: June 7, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc December 4, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-12 + draft-ietf-uta-smtp-tlsrpt-13 Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and MTA-STS. These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient @@ -77,38 +77,38 @@ 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 - 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 + 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 23 - Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 23 - A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 23 - A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 23 - Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 24 + A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 24 + A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 24 + Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design is based on "Opportunistic Security" (OS) [RFC7435], which maintains interoperability with clients that do not support STARTTLS but means that any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the @@ -215,21 +215,21 @@ tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-extension ; tlsrpt-rua record is ; required. tlsrpt-version = %s"v=TLSRPTv1" tlsrpt-rua = %s"rua=" tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) tlsrpt-uri = URI - ; "URI" is imported from [@!RFC3986]; + ; "URI" is imported from [RFC3986]; ; commas (ASCII 0x2C) and exclamation ; points (ASCII 0x21) MUST be encoded tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding "=", ";", SP, and control @@ -532,21 +532,21 @@ 5.1. Report Filename The filename is RECOMMENDED to be constructed using the following ABNF: filename = sender "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension 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` ; address in the report body policy-domain = domain begin-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating start of the time range contained ; in the report @@ -586,57 +586,61 @@ Inside it, there are two parts: The first part is human readable, typically "text/plain", and the second part is machine readable with a new media type defined called "application/tlsrpt+json". If compressed, the report should use the media type "application/ tlsrpt+gzip". In addition, the following two new top level message header fields are defined: "TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender- - Domain" The "TLS-Report-Submitter" value MUST match the value found - in the filename and the [RFC5321] domain from the "contact-info" from - the 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]: + Domain" + + The "TLS-Report-Submitter" value MUST match the value found in the + filename and the [RFC5321] domain from the "contact-info" from the + 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"" It is presumed that the aggregate reporting address will be equipped to process new message header fields and extract MIME parts with the prescribed media type and filename, and ignore the rest. These additional headers SHOULD be included in the DKIM [RFC6376] signature for the message. The [RFC5322].Subject field for report submissions SHOULD conform to the following ABNF: tlsrpt-subject = %s"Report" FWS ; "Report" %s"Domain:" FWS ; "Domain:" - domain-name FWS ; per RFC6376 + domain-name FWS ; per [RFC6376] %s"Submitter:" FWS ; "Submitter:" - domain-name FWS ; per RFC6376 + domain-name FWS ; per [RFC6376] %s"Report-ID:" FWS ; "Report-ID: - "<" id-left "@" id-right ">" ; per RFC5322 - [CFWS] ; per RFC5322 + "<" id-left "@" id-right ">" ; per [RFC5322] + [CFWS] ; per [RFC5322] ; (as with FWS) The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Sending MTA generating the report. 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 sent by a Sending MTA. For instance, this is a possible Subject field for a report to the Policy Domain "example.net" from the Sending MTA "mail.sender.example.com". It is line-wrapped as allowed by + [RFC5322]: + Subject: Report Domain: example.net Submitter: mail.sender.example.com Report-ID: <735ff.e317+bf22029@mailexample.net> 5.3.1. Example Report From: tlsrpt@mail.sender.example.com Date: Fri, May 09 2017 16:54:30 -0800 To: mts-sts-tlsrpt@example.net Subject: Report Domain: example.net