--- 1/draft-ietf-uta-smtp-tlsrpt-02.txt 2017-02-15 07:13:15.533361991 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-03.txt 2017-02-15 07:13:15.569362839 -0800 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: June 18, 2017 Comcast, Inc +Expires: August 19, 2017 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - December 15, 2016 + February 15, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-02 + draft-ietf-uta-smtp-tlsrpt-03 Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and SMTP MTA STS (TODO: Add ref). 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 @@ -35,25 +35,25 @@ 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 June 18, 2017. + This Internet-Draft will expire on August 19, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -162,23 +162,23 @@ o The Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] contains an XML-based reporting format for aggregate and detailed email delivery errors. 3. Reporting Policy A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone, as TXT records (similar to DMARC - policies) under the name "_smtp-tlsrpt". For example, for the Policy + policies) under the name "smtp-tlsrpt". For example, for the Policy Domain "example.com", the recipient's TLSRPT policy can be retrieved - from "_smtp-tlsrpt.example.com". + from "smtp-tlsrpt.example.com". Policies consist of the following directives: o "v": This value MUST be equal to "TLSRPTv1". o "rua": A URI specifying the endpoint to which aggregate information about policy failures should be sent (see the section _Reporting_ _Schema_ for more information). Two URI schemes are supported: "mailto" and "https". @@ -190,51 +190,51 @@ SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA failures. o "ruf": Future use. (There may also be a need for enabling more detailed "forensic" reporting during initial stages of a deployment. To address this, the authors consider the possibility of an optional additional "forensic reporting mode" in which more details--such as certificate chains and MTA banners--may be reported.) - 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: tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53 %x52 %x50 %x54 %x76 %x31 tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri tlsrpt-uri = URI ; "URI" is imported from [@!RFC3986]; commas (ASCII ; 0x2C) and exclamation points (ASCII 0x21) ; MUST be encoded; the numeric portion MUST fit ; within an unsigned 64-bit integer - 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 discarded. If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT. 3.1. Example Reporting Policy 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" 3.1.2. Report using HTTPS - _smtp-tlsrpt.example.com. IN TXT \ + smtp-tlsrpt.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 4. Reporting Schema The report is composed as a plain text file encoded in the JSON format ([RFC7159]). Aggregate reports contain the following fields: @@ -509,26 +509,26 @@ DMARC [RFC7489] defines an elegant solution for verifying delegation; however, since the attacker had less ability to generate large reports than with DMARC failures, and since the reports are generated by the sending MTA, such a delegation mechanism is left for a future version of this specification. 8. Appendix 1: Example Reporting Policy 8.1. Report using MAILTO - _smtp-tlsrpt.mail.example.com. IN TXT \ + smtp-tlsrpt.mail.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:reports@example.com" 8.2. Report using HTTPS - _smtp-tlsrpt.mail.example.com. IN TXT \ + smtp-tlsrpt.mail.example.com. IN TXT \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 9. Appendix 2: JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) { "organization-name": organization-name, "date-range": {