--- 1/draft-ietf-uta-smtp-tlsrpt-13.txt 2018-01-26 07:14:29.230244499 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-14.txt 2018-01-26 07:14:29.294246014 -0800 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: June 7, 2018 Comcast, Inc +Expires: July 30, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - December 4, 2017 + January 26, 2018 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-13 + draft-ietf-uta-smtp-tlsrpt-14 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 @@ -28,37 +28,37 @@ misconfigurations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://datatracker.ietf.org/drafts/current/. + 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 7, 2018. + This Internet-Draft will expire on July 30, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + 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 - (https://trustee.ietf.org/license-info) in effect on the date of + (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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -77,21 +77,21 @@ 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.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 - 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16 + 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 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 @@ -366,25 +366,31 @@ 4.3.2. Policy Failures 4.3.2.1. DANE-specific Policy Failures o "tlsa-invalid": This indicates a validation error in the TLSA record associated with a DANE policy. None of the records in the RRset were found to be valid. o "dnssec-invalid": This would indicate that no valid records were returned from the recursive resolver. The request returned with - SERVFAIL for the requested TLSA record. It should be noted that - if the reporter's systems are having problems resolving - destination DNS records due to DNSSEC failures, it's possible they - will also be unable to resolve the TLSRPT record, therefore these - types of reports may be rare. + SERVFAIL for the requested TLSA record. + + o "dane-required": This indicates that the sending system is + configured to require DANE TLSA records for all the MX hosts of + the destination domain, but no DNSSEC-validated TLSA records were + present for the MX host that is the subject of the report. + Mandatory DANE for SMTP is described in section 6 of [RFC7672]. + + Such policies may be created by mutual agreement between two + organizations that frequently exchange sensitive content via + email. 4.3.2.2. MTA-STS-specific Policy Failures o "sts-policy-invalid": This indicates a validation error for the overall MTA-STS policy. o "sts-webpki-invalid": This indicates that the MTA-STS policy could not be authenticated using PKIX validation. 4.3.3. General Failures @@ -461,52 +467,56 @@ 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. IN TLSA ( 3 0 1 \ - 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D - )"" MTA-STS: ""version: STSv1\nmode: report\nmx: - mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup- - example.com\nmax_age: 12345678"" + 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"" 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 is the Punycode-encoded - A-label ([RFC3492]) and not the U-label. + 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 - Domain Names ([RFC5891]), the domain is the Punycode-encoded - A-label ([RFC3492]) and not the U-label. + Domain Names ([RFC5891]), the domain MUST consist of the Punycode- + encoded A-labels ([RFC3492]) and not the U-labels. 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 (see below) or IPv6 ([RFC5952]) 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 "receiving-ip": The destination IP address that was using when + creating the outbound session. It is provided as a string + representation of an IPv4 (see below) or IPv6 ([RFC5952]) address + in dot-decimal or colon-hexadecimal notation. + o "total-successful-session-count": The aggregate number (integer) of successfully negotiated TLS-enabled connections to the receiving site. o "total-failure-session-count": The aggregate number (integer) of failures to negotiate a TLS-enabled connection to the receiving site. o "failed-session-count": The number of (attempted) sessions that match the relevant "result-type" for this section. @@ -548,33 +558,29 @@ 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" / "json.gz" - - The extension MUST be "json" for a plain JSON file, or "json.gz" for - a JSON file compressed using GZIP. + extension = "json" "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": - "mail.sender.example.com!example.net!1470013207!1470186007!001.json.g - z" + "mail.sender.example.com!example.net!1470013207!1470186007!001.json" 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 @@ -673,46 +678,53 @@ ------=_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 - "application/tlsrpt+json" otherwise (see section Section 6, "IANA - Considerations"). + 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. 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. 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 would be on a - logarithmic scale. + multiple retries are attempted, ideally they SHOULD be done with + exponential backoff. 5.6. Metadata Variances As stated above, there are a variable number of ways to declare - information about the data therein. If it should be the case that - these objects were to disagree, then the report data contained within - the JSON body MUST be considered the authoritative source for those - data elements. + information about the data therein. If any of items declared via + subject or filename disagree with the report, the report MUST be + considered the authoritative source. 6. IANA Considerations The following are the IANA considerations discussed in this document. 6.1. Message headers Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. @@ -916,70 +928,70 @@ a large TTL (reducing the window for successful attacks against DNS resolution of the record) or to deploy DNSSEC on the deploying zone. 8. References 8.1. Normative References [I-D.ietf-uta-mta-sts] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA- - STS)", draft-ietf-uta-mta-sts-11 (work in progress), - November 2017. + STS)", draft-ietf-uta-mta-sts-14 (work in progress), + January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . + DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . + DOI 10.17487/RFC5234, January 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, - DOI 10.17487/RFC5321, October 2008, - . + DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - DOI 10.17487/RFC5322, October 2008, - . + DOI 10.17487/RFC5322, October 2008, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, - DOI 10.17487/RFC5891, August 2010, - . + DOI 10.17487/RFC5891, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, - DOI 10.17487/RFC5952, August 2010, - . + DOI 10.17487/RFC5952, August 2010, . [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 @@ -995,59 +1007,65 @@ STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, . [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 2012, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, - DOI 10.17487/RFC7231, June 2014, - . + DOI 10.17487/RFC7231, June 2014, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, - DOI 10.17487/RFC7493, March 2015, - . + DOI 10.17487/RFC7493, March 2015, . 8.2. Informative References [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, - DOI 10.17487/RFC3864, September 2004, - . + DOI 10.17487/RFC3864, September 2004, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . + [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via + Opportunistic DNS-Based Authentication of Named Entities + (DANE) Transport Layer Security (TLS)", RFC 7672, + DOI 10.17487/RFC7672, October 2015, . + Appendix A. Example Reporting Policy A.1. Report using MAILTO _smtp-tlsrpt.mail.example.com. IN TXT \ "v=TLSRPTv1;rua=mailto:reports@example.com" A.2. Report using HTTPS _smtp-tlsrpt.mail.example.com. IN TXT \ @@ -1077,26 +1095,28 @@ }, "failure-details": [{ "result-type": "certificate-expired", "sending-mta-ip": "98.136.216.25", "receiving-mx-hostname": "mx1.mail.company-y.example", "failed-session-count": 100 }, { "result-type": "starttls-not-supported", "sending-mta-ip": "98.22.33.99", "receiving-mx-hostname": "mx2.mail.company-y.example", + "receiving-ip": "192.168.14.72", "failed-session-count": 200, "additional-information": "https://reports.company-x.example/ report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported " }, { "result-type": "validation-failure", "sending-mta-ip": "47.97.15.2", + "receiving-ip": "10.72.84.12", "receiving-mx-hostname": "mx-backup.mail.company-y.example", "failed-session-count": 3, "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" }] }] } Figure: Example JSON report for a messages from Company-X to Company- Y, where 100 sessions were attempted to Company Y servers with an expired certificate and 200 sessions were attempted to Company Y @@ -1094,40 +1114,39 @@ "failed-session-count": 3, "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" }] }] } Figure: Example JSON report for a messages from Company-X to Company- Y, where 100 sessions were attempted to Company Y servers with an expired certificate and 200 sessions were attempted to Company Y servers that did not successfully respond to the "STARTTLS" command. - Additionally 3 sessions failed due to "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". Authors' Addresses Daniel Margolis Google, Inc - Email: dmargolis (at) google (dot com) + Email: dmargolis@google.com Alexander Brotman Comcast, Inc - Email: alex_brotman (at) comcast (dot com) + Email: alex_brotman@comcast.com Binu Ramakrishnan Yahoo!, Inc - Email: rbinu (at) yahoo-inc (dot com) + Email: rbinu@oath.com Janet Jones Microsoft, Inc - Email: janet.jones (at) microsoft (dot com) + Email: janet.jones@microsoft.com Mark Risher Google, Inc - Email: risher (at) google (dot com) + Email: risher@google.com