--- 1/draft-ietf-uta-smtp-tlsrpt-14.txt 2018-02-19 16:13:15.714350281 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-15.txt 2018-02-19 16:13:15.770351610 -0800 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: July 30, 2018 Comcast, Inc +Expires: August 23, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - January 26, 2018 + February 19, 2018 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-14 + draft-ietf-uta-smtp-tlsrpt-15 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 @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 30, 2018. + This Internet-Draft will expire on August 23, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,25 +73,25 @@ 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 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.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 + 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 @@ -433,20 +433,21 @@ "summary": { "total-successful-session-count": total-successful-session-count, "total-failure-session-count": total-failure-session-count }, "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, + "receiving-ip": receiving-ip, "failed-session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": failure-reason-code } ] } ] } JSON Report Format @@ -467,24 +468,35 @@ may use whatever scheme they prefer to generate a unique identifier. It is provided as a string. o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string. o "policy-string": A string representation of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: - TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13 - 6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version: - STSv1\nmode: report\nmx: mx1.example.com\nmx: \ - mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678"" + + For DANE TLSA policies, a JSON array array of strings each + representing the RDATA of a single TLSA resource record as a space- + separated list of its four TLSA fields (in RFC6698 Section 2.2) + presentation form with no internal spaces or grouping parentheses: + + ["3 0 1 + 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", + 3 0 1 + 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"] + + MTA-STS (array of JSON strings): + + ["version: STSv1","mode: report","mx: mx1.example.com","mx: + mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"] o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. In the case of Internationalized Domain Names ([RFC5891]), the domain MUST consist of the Punycode- encoded A-labels ([RFC3492]) and not the U-labels. o "mx-host-pattern": The pattern of MX hostnames from the applied policy. It is provided as a string, and is interpreted in the same manner as the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125]. In the case of Internationalized @@ -558,29 +570,32 @@ begin-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating start of the time range contained ; in the report end-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating end of the time range contained ; in the report - extension = "json" + extension = "json" / "json.gz" + + The extension MUST be "json" for a plain JSON file, or "json.gz" for + a JSON file compressed using GZIP. "unique-id" allows an optional unique ID generated by the Sending MTA to distinguish among multiple reports generated simultaneously by different sources within the same Policy Domain. For example, this - is a possible filename for the gzip file of a report to the Policy - Domain "example.net" from the Sending MTA "mail.sender.example.com": + is a possible filename for a compressed report to the Policy Domain + "example.net" from the Sending MTA "mail.sndr.example.com": - "mail.sender.example.com!example.net!1470013207!1470186007!001.json" + "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz" 5.2. Compression The report SHOULD be subjected to GZIP compression for both email and HTTPS transport. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); compressing the file increases the chances of acceptance of the report at some compute cost. 5.3. Email Transport @@ -590,22 +605,23 @@ "multipart/report" with a new parameter "report-type="tlsrpt"". 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" + "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]: "s SEARCH HEADER "TLS-Report-Domain" "example.com"" It is presumed that the aggregate reporting address will be equipped @@ -664,52 +680,49 @@ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is an aggregate TLS report from mail.sender.example.com ------=_NextPart_000_024E_01CC9B0A.AFE54C00 Content-Type: application/tlsrpt+gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mail.sender.example!example.com! - 1013662812!1013749130.gz" + 1013662812!1013749130.json.gz" ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- ... Note that, when sending failure reports via SMTP, sending MTAs MUST NOT honor MTA-STS or DANE TLSA failures. 5.4. HTTPS Transport The report MAY be delivered by POST to HTTPS. If compressed, the report SHOULD use the media type "application/tlsrpt+gzip", and - The report MAY be delivered by POST to HTTPS. When doing so, the - report should use the media-type "application/tlsrpt" (see section - Section 6, "IANA Considerations"). If the reporting entity - compresses the report, that should be noted in the Content-Type - "conversions" field: - - Content-Type: application/tlsrpt; conversions=gzip Content-Type: - application/tlsrpt; conversions=none Content-Type: application/tlsrpt - - The second and third items in the list are equivalent. + "application/tlsrpt+json" otherwise (see section Section 6, "IANA + 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. + Alternately, if a receiving system offers "Accept-Encoding" value of + "gzip", the sending system MAY use "Content-Encoding: gzip" as an + HTTP header as appropriate. This can be used in place of delivering + a compressed file as the payload. + 5.5. Delivery Retry In the event of a delivery failure, regardless of the delivery method, a sender SHOULD attempt redelivery for up to 24hrs after the initial attempt. As previously stated the reports are optional, so while it is ideal to attempt redelivery, it is not required. If multiple retries are attempted, ideally they SHOULD be done with exponential backoff. 5.6. Metadata Variances @@ -1077,22 +1090,22 @@ "organization-name": "Company-X", "date-range": { "start-datetime": "2016-04-01T00:00:00Z", "end-datetime": "2016-04-01T23:59:59Z" }, "contact-info": "sts-reporting@company-x.example", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "policies": [{ "policy": { "policy-type": "sts", - "policy-string": "version: STSv1\r\nmode: report\r\n - mx: .mail.company-y.example\r\nmax_age: 86400", + "policy-string": ["version: STSv1","mode: report", + "mx: .mail.company-y.example","max_age: 86400"], "policy-domain": "company-y.example", "mx-host": ".mail.company-y.example" }, "summary": { "total-successful-session-count": 5326, "total-failure-session-count": 303 }, "failure-details": [{ "result-type": "certificate-expired", "sending-mta-ip": "98.136.216.25",