SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-12
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8460.
|
|
---|---|---|---|
Authors | Daniel Margolis , Alex Brotman , Binu Ramakrishnan , Janet Jones , Mark Risher | ||
Last updated | 2017-12-04 | ||
Replaces | draft-brotman-smtp-tlsrpt | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-17)
by Joel Halpern
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Consensus: Waiting for Write-Up | |
Document shepherd | Leif Johansson | ||
IESG | IESG state | Became RFC 8460 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | Leif Johansson <leifj@sunet.se> |
draft-ietf-uta-smtp-tlsrpt-12
quot; 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. 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. 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]. Header field name: TLS-Report-Domain Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): this one Header field name: TLS-Report-Submitter Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): this one Margolis, et al. Expires June 7, 2018 [Page 16] Internet-Draft SMTP-TLSRPT December 2017 6.2. Report Type This document registers a new parameter "report-type="tlsrpt"" under "multipart/report" top-level media type for use with [RFC6522]. The media type suitable for use as a report-type is defined in the following section. 6.3. application/tlsrpt+json Media Type This document registers multiple media types, beginning with Table 1 below. +-------------+----------------+-------------+-------------------+ | Type | Subtype | File extn | Specification | +-------------+----------------+-------------+-------------------+ | application | tlsrpt+json | .json | Section 5.3 | +-------------+----------------+-------------+-------------------+ Table 1: SMTP TLS Reporting Media Type Type name: application Subtype name: tlsrpt+json Required parameters: n/a Optional parameters: n/a Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7493]. Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: Section 5.3 of this document. Applications that use this media type: Mail User Agents (MUA) and Mail Transfer Agents. Additional information: Margolis, et al. Expires June 7, 2018 [Page 17] Internet-Draft SMTP-TLSRPT December 2017 Magic number(s): n/a File extension(s): ".json" Macintosh file type code(s): n/a Person & email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: n/a Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 6.4. application/tlsrpt+gzip Media Type +-------------+----------------+-------------+-------------------+ | Type | Subtype | File extn | Specification | +-------------+----------------+-------------+-------------------+ | application | tlsrpt+gzip | .gz | Section 5.3 | +-------------+----------------+-------------+-------------------+ Table 2: SMTP TLS Reporting Media Type Type name: application Subtype name: tlsrpt+gzip Required parameters: n/a Optional parameters: n/a Encoding considerations: Binary Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: Section 5.3 of this document. Applications that use this media type: Mail User Agents (MUA) and Mail Transfer Agents. Margolis, et al. Expires June 7, 2018 [Page 18] Internet-Draft SMTP-TLSRPT December 2017 Additional information: Magic number(s): n/a File extension(s): ".gz" Macintosh file type code(s): n/a Person & email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: n/a Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 6.5. STARTTLS Validation Result Types This document creates a new registry, "STARTTLS Validation Result Types". The initial entries in the registry are: +-------------------------------+ | Result Type | +-------------------------------+ | "starttls-not-supported" | | "certificate-host-mismatch" | | "certificate-expired" | | "tlsa-invalid" | | "dnssec-invalid" | | "sts-policy-invalid" | | "sts-webpki-invalid" | | "validation-failure" | +-------------------------------+ The above entries are described in section Section 4.3, "Result Types." New result types can be added to this registry using "Expert Review" IANA registration policy. 7. Security Considerations SMTP TLS Reporting provides transparency into misconfigurations or attempts to intercept or tamper with mail between hosts who support STARTTLS. There are several security risks presented by the existence of this reporting channel: Margolis, et al. Expires June 7, 2018 [Page 19] Internet-Draft SMTP-TLSRPT December 2017 o Flooding of the Aggregate report URI (rua) endpoint: An attacker could flood the endpoint with excessive reporting traffic and prevent the receiving domain from accepting additional reports. This type of Denial-of-Service attack would limit visibility into STARTTLS failures, leaving the receiving domain blind to an ongoing attack. o Untrusted content: An attacker could inject malicious code into the report, opening a vulnerability in the receiving domain. Implementers are advised to take precautions against evaluating the contents of the report. o Report snooping: An attacker could create a bogus TLSRPT record to receive statistics about a domain the attacker does not own. Since an attacker able to poison DNS is already able to receive counts of SMTP connections (and, absent DANE or MTA-STS policies, actual SMTP message payloads), this does not present a significant new vulnerability. o Reports as DDoS: TLSRPT allows specifying destinations for the reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls the Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks; the need for this is greater with DMARC, however, because DMARC allows an attacker to trigger reports to a target from an innocent third party by sending that third party mail (which triggers a report from the third party to the target). In the case of TLSRPT, the attacker would have to induce the third party to send the attacker mail in order to trigger reports from the third party to the victim; this reduces the risk of such an attack and the need for a verification mechanism. Finally, because TLSRPT is intended to help administrators discover man-in-the-middle attacks against transport-layer encryption, including attacks designed to thwart negotiation of encrypted connections (by downgrading opportunistic encryption or, in the case of MTA-STS, preventing discovery of a new MTA-STS policy), we must also consider the risk that an adversary who can induce such a downgrade attack can also prevent discovery of the TLSRPT TXT record (and thus prevent discovery of the successful downgrade attack). Administrators are thus encouraged to deploy TLSRPT TXT records with a large TTL (reducing the window for successful attacks against DNS resolution of the record) or to deploy DNSSEC on the deploying zone. Margolis, et al. Expires June 7, 2018 [Page 20] Internet-Draft SMTP-TLSRPT December 2017 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>. [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, <https://www.rfc-editor.org/info/rfc3986>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [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, <https://www.rfc-editor.org/info/rfc5280>. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>. Margolis, et al. Expires June 7, 2018 [Page 21] Internet-Draft SMTP-TLSRPT December 2017 [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>. [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <https://www.rfc-editor.org/info/rfc6068>. [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, <https://www.rfc-editor.org/info/rfc6125>. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>. [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/info/rfc6522>. [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, <https://www.rfc-editor.org/info/rfc6698>. [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, <https://www.rfc-editor.org/info/rfc7231>. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>. [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>. Margolis, et al. Expires June 7, 2018 [Page 22] Internet-Draft SMTP-TLSRPT December 2017 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, <https://www.rfc-editor.org/info/rfc3207>. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>. [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>. [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>. 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 \ "v=TLSRPTv1; \ rua=https://reporting.example.com/v1/tlsrpt" Appendix B. Example JSON Report Margolis, et al. Expires June 7, 2018 [Page 23] Internet-Draft SMTP-TLSRPT December 2017 { "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.example", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "policies": [{ "policy": { "policy-type": "sts", "policy-string": "version: STSv1\r\nmode: report\r\n mx: .mail.company-y.example\r\nmax_age: 86400", "policy-domain": "company-y.example", "mx-host": ".mail.company-y.example" }, "summary": { "total-successful-session-count": 5326, "total-failure-session-count": 303 }, "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", "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-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 servers that did not successfully respond to the "STARTTLS" command. Margolis, et al. Expires June 7, 2018 [Page 24] Internet-Draft SMTP-TLSRPT December 2017 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) Alexander Brotman Comcast, Inc Email: alex_brotman (at) comcast (dot com) Binu Ramakrishnan Yahoo!, Inc Email: rbinu (at) yahoo-inc (dot com) Janet Jones Microsoft, Inc Email: janet.jones (at) microsoft (dot com) Mark Risher Google, Inc Email: risher (at) google (dot com) Margolis, et al. Expires June 7, 2018 [Page 25]