--- 1/draft-ietf-uta-smtp-tlsrpt-04.txt 2017-05-04 09:13:12.604300504 -0700 +++ 2/draft-ietf-uta-smtp-tlsrpt-05.txt 2017-05-04 09:13:12.636301267 -0700 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: October 5, 2017 Comcast, Inc +Expires: November 4, 2017 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - April 3, 2017 + May 3, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-04 + draft-ietf-uta-smtp-tlsrpt-05 Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and 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 potential @@ -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 5, 2017. + This Internet-Draft will expire on November 4, 2017. Copyright Notice 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 @@ -60,44 +60,44 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 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. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6 - 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 6 - 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6 + 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 + 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7 - 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 7 + 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 8 - 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 8 + 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 9 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 9 + 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 10 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10 - 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 10 + 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 11 - 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 11 + 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 12 + 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 12 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12 9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12 - 10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 14 + 10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 @@ -148,75 +148,90 @@ o Policy Domain: The domain against which an MTA-STS or DANE Policy is defined. o Sending MTA: The MTA initiating the delivery of an email message. 2. Related Technologies o This document is intended as a companion to the specification for SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). - o The Public Key Pinning Extension for HTTP [RFC7469] contains a - JSON-based definition for reporting individual pin validation - failures. - - o The Domain-based Message Authentication, Reporting, and - Conformance (DMARC) [RFC7489] contains an XML-based reporting - format for aggregate and detailed email delivery errors. + o SMTP-TLSRPT defines a mechanism for sending domains that are + compatible with MTA-STS or DANE to share success and failure + statistics with recipient domains. DANE is defined in [RFC6698] + and MTA-STS is defined in [TODO] 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 Domain "example.com", the recipient's TLSRPT policy can be retrieved 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 + information about policy failures should be sent (see Section 4, + "Reporting Schema", for more information). Two URI schemes are supported: "mailto" and "https". - * In the case of "https", reports should be submitted via POST + o 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 deliver reports despite any TLS-related - failures. This may mean that the reports are delivered in the - clear. + o In the case of "mailto", reports should be submitted to the + specified email address ([RFC6068]). When sending failure reports + via SMTP, sending MTAs MUST deliver reports despite any TLS- + related failures. This may mean that the reports are delivered in + the clear. The formal definition of the "_smtp-tlsrpt" TXT record, defined using [RFC5234], is as follows: - tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua + tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua + [field-delim [tlsrpt-extensions]] - tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53 - %x52 %x50 %x54 %x76 %x31 + field-delim = %x3B ; ";" - tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri + tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52 + %x50 %x54 %x76 %x31 ; "v=TSRPTv1" + + tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..." 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 + tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension) + [field-delim] + ; extension fields + + tlsrpt-extension = tlsrpt-ext-name *WSP "=" *WSP 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 chars + 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. + MUST assume the recipient domain does not implement TLSRPT. Parsers + MUST accept TXT records which are syntactically valid (i.e. valid + key-value pairs seprated by semi-colons) and implementing a superset + of this specification, in which case unknown fields SHALL be ignored. 3.1. Example Reporting Policy 3.1.1. Report using MAILTO _smtp-tlsrpt.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:reports@example.com" 3.1.2. Report using HTTPS @@ -277,21 +293,21 @@ successfully negotiate a policy-compliant TLS connection, and serves to provide a "heartbeat" to receiving domains that reporting is functional and tabulating correctly. This field contains an aggregate count of successful connections for the reporting system. 4.2.2. Failure Count o "failure-count": This indicates that the sending MTA was unable to successfully establish a connection with the receiving platform. - The "Result Types" section will elaborate on the failed + Section 4.3, "Result Types", will elaborate on the failed negotiation attempts. This field contains an aggregate count of failed connections. 4.3. Result Types The list of result types will start with the minimal set below, and is expected to grow over time based on real-world experience. The initial set is: 4.3.1. Negotiation Failures @@ -406,21 +422,22 @@ chances of acceptance of the report at some compute cost. 5.3. Email Transport The report MAY be delivered by email. No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest. If compressed, the report should use the media type "application/ - gzip" if compressed (see [RFC6713]), and "text/json" otherwise. + gzip" if compressed (see [RFC6713]), and "application/json" + otherwise. The [RFC5322].Subject field for individual report submissions SHOULD conform to the following ABNF: tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" domain-name 1*FWS ; from RFC 6376 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" @@ -442,21 +459,21 @@ Submitter: mail.sender.example.com Report-ID: <735ff.e317+bf22029@mailexample.net> 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/gzip" (see [RFC6713]), - and "text/json" otherwise. + and "application/json" otherwise. 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, they should be on a logarithmic scale. @@ -566,66 +582,66 @@ 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": The string serialization of the policy, whether - TLSA record or MTA-STS policy. Any linefeeds from the original - policy MUST be replaced with [SP]. TODO: Help with specifics. + o "policy-string": The JSON string serialization ([RFC7159] section + 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or + MTA-STS policy. - o "domain": The Policy Domain upon which the policy was applied. - For messages sent to "user@example.com" this field would contain - "example.com". It is provided as a string. + o "domain": The Policy Domain is the domain against which the MTA- + STS or DANE policy is defined. 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]. - o "result-type": A value from the _Result Types_ section above. + o "result-type": A value from Section 4.3, "Result Types", above. o "ip-address": The IP address of the sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal notation. o "receiving-mx-hostname": The hostname of the receiving MTA MX record with which the sending MTA attempted to negotiate a STARTTLS connection. o "receiving-mx-helo": (optional) The HELO or EHLO string from the banner announced during the reported session. o "success-aggregate": The aggregate number (integer) of - successfully negotiated SSL-enabled connections to the receiving + successfully negotiated TLS-enabled connections to the receiving site. o "failure-aggregate": The aggregate number (integer) of failures to - negotiate an SSL-enabled connection to the receiving site. + negotiate an TLS-enabled connection to the receiving site. o "session-count": The number of (attempted) sessions that match the relevant "result-type" for this section. o "additional-info-uri": An optional URI pointing to additional information around the relevant "result-type". For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session. - o "failure-reason-code": A text field to include an SSL-related + o "failure-reason-code": A text field to include an TLS-related error code or error message. 10. Appendix 3: Example JSON Report + { "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.com", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "policy": { "policy-type": "sts", @@ -686,20 +702,24 @@ [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, . + [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' + URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, + . + [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 of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August