--- 1/draft-ietf-uta-smtp-tlsrpt-00.txt 2016-07-09 07:16:28.001969248 -0700 +++ 2/draft-ietf-uta-smtp-tlsrpt-01.txt 2016-07-09 07:16:28.025969846 -0700 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: November 13, 2016 Comcast, Inc +Expires: January 9, 2017 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - May 13, 2016 + July 8, 2016 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-00 + draft-ietf-uta-smtp-tlsrpt-01 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,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 October 20, 2016. + This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 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 @@ -58,34 +58,34 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 4 - 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 4 + 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 + 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Result Types . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Success Type . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Routing Failures . . . . . . . . . . . . . . . . . . 6 4.1.3. Negotiation Failures . . . . . . . . . . . . . . . . 6 4.1.4. Policy Failures . . . . . . . . . . . . . . . . . . . 7 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Appendix 1: JSON Report Schema . . . . . . . . . . . . . . . 8 - 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 9 + 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 provides interoperability for clients that do not support STARTTLS but means that any attacker who can delete parts of the SMTP session @@ -152,51 +152,61 @@ "_smtp_tlsrpt". For example, for the Policy Domain "example.com", the recipient's SMTP STS policy can be retrieved from "_smtp_tlsrpt.example.com". (Future implementations may move to alternate methods of policy discovery or distribution. See the section _Future_ _Work_ for more discussion.) Policies consist of the following directives: - o "v": This value MUST be equal to "TLSRPT1". + 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". * In the case of `https`, reports should be submitted via POST ([@!RFC2818]) to the specified URI. * In the case of `mailto`, reports should be submitted to the specified email address. When sending failure reports via 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. See the section _Future_ _Work_ for more details.) + The formal definition of the "_mta_sts" TXT record, defined using + [RFC5234], is as follows: + + sts-text-record = sts-version *WSP %x3B *WSP sts-id + + sts-version = "v" *WSP "=" *WSP %x54 %x4C %x53 + %x52 %x50 %x54 %x76 %x31 + + sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) + 3.1. Example Reporting Policy 3.1.1. Report using MAILTO _smtp_tlsrpt.mail.example.com. IN TXT \ - "v=TLSRPT1;rua=mailto=reports@example.com" + "v=TLSRPTv1;rua=mailto:reports@example.com" 3.1.2. Report using HTTPS _smtp_tlsrpt.mail.example.com. IN TXT \ - "v=TLSRPT1; \ + "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" 4. Reporting Schema Aggregate reports contain the following fields: o Report metadata: * The organization responsible for the report @@ -445,34 +456,39 @@ } Example JSON report for a messages from Company-X to Company-Y, where 100 messages were attempted to Company Y servers with an expired certificate and 200 messages were attempted to Company Y servers that did not successfully respond to the STARTTLS command. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI - 10.17487/RFC5322, October 2008, + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication