--- 1/draft-ietf-uta-smtp-tlsrpt-16.txt 2018-03-05 06:14:11.835428005 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-17.txt 2018-03-05 06:14:11.887429236 -0800 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: September 5, 2018 Comcast, Inc +Expires: September 6, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - March 4, 2018 + March 5, 2018 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-16 + draft-ietf-uta-smtp-tlsrpt-17 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 September 5, 2018. + This Internet-Draft will expire on September 6, 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 @@ -465,23 +465,23 @@ o "report-id": A unique identifier for the report. Report authors 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 - follow in the next section. + o "policy-string": An encoding of the applied policy as a JSON array + of strings, whether TLSA record ([RFC6698] section 2.3) or MTA-STS + policy. Examples follow in the next section. 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 @@ -535,32 +535,39 @@ Part of the report body includes the policy that is applied when attemping relay to the destination. For DANE TLSA policies, a JSON array of strings each representing the RDATA of a single TLSA resource record as a space-separated list of its four TLSA fields; the fields are in presentation format (defined in RFC6698 Section 2.2) with no internal spaces or grouping parentheses: - ["3 0 1 - 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", - 3 0 1 - 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"] + [ + "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", + "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234" + ] - For the MTA-STS policy, an array of JSON string will represent the + For the MTA-STS policy, an array of JSON strings that represents the policy that is declared by the receiving site, including any errors - that may be present. Note that if there are multiple MX records, - they are not included as an array. + that may be present. Note that where there are multiple "mx" values, + they must be listed as separate "mx" elements in the policy array, + rather as a single nested "mx" sub-array. - ["version: STSv1","mode: report","mx: mx1.example.com","mx: - mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"] + [ + "version: STSv1", + "mode: report", + "mx: mx1.example.com", + "mx: mx2.example.com", + "mx: mx.backup-example.com", + "max_age: 12345678" + ] 5. Report Delivery Reports can be delivered either as an email message via SMTP or via HTTP POST. 5.1. Report Filename The filename is RECOMMENDED to be constructed using the following ABNF: