--- 1/draft-ietf-uta-smtp-tlsrpt-10.txt 2017-11-09 17:13:07.983384146 -0800 +++ 2/draft-ietf-uta-smtp-tlsrpt-11.txt 2017-11-09 17:13:08.031385293 -0800 @@ -1,55 +1,55 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: April 1, 2018 Comcast, Inc +Expires: May 12, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - September 28, 2017 + November 8, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-10 + draft-ietf-uta-smtp-tlsrpt-11 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 - failures with recipient domains. Recipient domains can then use this - information to both detect potential attackers and diagnose - unintentional misconfigurations. + 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 + domains. Recipient domains can then use this information to both + detect potential attackers and diagnose unintentional + 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 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 April 1, 2018. + This Internet-Draft will expire on May 12, 2018. 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 @@ -66,49 +66,49 @@ 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 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. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 14 + 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 19 - 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 20 - 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 20 - 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 20 - 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 20 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 - 10.2. Informative References . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 21 + 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 21 + 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 21 + 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 10.2. Informative References . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the @@ -129,23 +129,23 @@ failures in routing, STARTTLS negotiation, and both DANE [RFC6698] and MTA-STS (TODO: Add ref) policy validation errors, and a standard TXT record that recipient domains can use to indicate where reports in this format should be sent. This document is intended as a companion to the specification for SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 1.1. Terminology - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in [RFC2119]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. We also define the following terms for further use in this document: o MTA-STS Policy: A definition of the expected TLS availability, behavior, and desired actions for a given domain when a sending MTA encounters problems in negotiating a secure channel. MTA-STS is defined in [TODO] o DANE Policy: A mechanism by which administrators can supply a record that can be used to validate the certificate presented by @@ -183,30 +183,31 @@ o "v": This value MUST be equal to "TLSRPTv1". o "rua": A URI specifying the endpoint to which aggregate information about policy validation results should be sent (see Section 4, "Reporting Schema", for more information). Two URI schemes are supported: "mailto" and "https". As with DMARC [RFC7489], the policy domain can specify a comma-separated list of URIs. o In the case of "https", reports should be submitted via POST - ([RFC2818]) to the specified URI. Report submitters MAY ignore + ([RFC7231]) to the specified URI. Report submitters MAY ignore certificate validation errors when submitting reports via https. 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. Additionally, reports sent via SMTP MUST contain a - valid DKIM [RFC6376] signature by the reporting domain. Reports - lacking such a signature MUST be ignored by the recipient. DKIM + related failuresand SHOULD NOT include this SMTP session in the + next report. This may mean that the reports are delivered in the + clear. Additionally, reports sent via SMTP MUST contain a valid + DKIM [RFC6376] signature by the reporting domain. Reports lacking + such a signature MUST be ignored by the recipient. DKIM signatures must not use the "l=" attribute to limit the body length used in the signature. The formal definition of the "_smtp-tlsrpt" TXT record, defined using [RFC5234] & [RFC7405], is as follows: tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) [field-delim] field-delim = *WSP ";" *WSP @@ -289,21 +291,25 @@ * An identifier for the policy (where applicable) o Aggregate counts, comprising result type, sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review further information on a failure type. Note that the failure types are non-exclusive; an aggregate report may contain overlapping "counts" of failure types when a single send - attempt encountered multiple errors. + attempt encountered multiple errors. Reporters may report multiple + applied policies (for example, an MTA-STS policy and a DANE TLSA + record for the same domain and MX); even in the case where only a + single policy was applied, the "policies" field of the report body + MUST be an array and not a singular value. 4.1. Report Time-frame The report SHOULD cover a full day, from 0000-2400 UTC. This should allow for easier correlation of failure events. To avoid a Denial of Service against the system processing the reports, the reports should be delivered after some delay, perhaps several hours. 4.2. Delivery Summary @@ -393,47 +399,51 @@ 4.3.4. Transient Failures Transient errors due to too-busy network, TCP timeouts, etc. are not required to be reported. 4.4. JSON Report Schema The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3) + { "organization-name": organization-name, "date-range": { "start-datetime": date-time, "end-datetime": date-time }, "contact-info": email-address, "report-id": report-id, + "policies": [{ "policy": { "policy-type": policy-type, "policy-string": policy-string, "policy-domain": domain, "mx-host": mx-host-pattern }, "summary": { "total-successful-session-count": total-successful-session-count, - "total-failure-session-count:" total-failure-session-count - } + "total-failure-session-count": total-failure-session-count + }, "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "failed-session-count": failed-session-count, "additional-information": additional-info-uri, - "failure-reason-code": "failure-reason-code" + "failure-reason-code": failure-reason-code + } + ] } ] } JSON Report Format o "organization-name": The name of the organization responsible for the report. It is provided as a string. o "date-time": The date-time indicates the start- and end-times for @@ -486,33 +496,33 @@ STARTTLS connection. o "receiving-mx-helo": (optional) The HELO or EHLO string from the banner announced during the reported session. 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 an TLS-enabled connection to the receiving + 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. o "additional-info-uri": An optional URI [RFC3986] 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 TLS-related - error code or error message. + o "failure-reason-code": A text field to include a TLS-related error + code or error message. For report purposes, an IPv4 Address is defined as: IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 5. Report Delivery Reports can be delivered either as an email message via SMTP or via HTTP POST. @@ -882,20 +893,32 @@ 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. + 8. Appendix 1: Example Reporting Policy 8.1. Report using MAILTO _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 \ @@ -904,174 +927,178 @@ 9. Appendix 2: 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", + "policies": [{ "policy": { "policy-type": "sts", - "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }", + "policy-string": "version: STSv1\r\nmode: report\r\nmx: .mail.company-y.com\r\nmax_age: 86400", "policy-domain": "company-y.com", "mx-host": ".mail.company-y.com" }, "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.com", "failed-session-count": 100 }, { "result-type": "starttls-not-supported", "sending-mta-ip": "98.22.33.99", "receiving-mx-hostname": "mx2.mail.company-y.com", "failed-session-count": 200, - "additional-information": "hxxps://reports.company-x.com/ + "additional-information": "https://reports.company-x.com/ report_info?id=5065427c-23d3#StarttlsNotSupported" }, { "result-type": "validation-failure", "sending-mta-ip": "47.97.15.2", "receiving-mx-hostname": "mx-backup.mail.company-y.com", "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 + 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". 10. References 10.1. 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, . - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - DOI 10.17487/RFC2818, May 2000, . + Requirement Levels", BCP 14, RFC 2119, 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, - . + 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, . + Specifications: ABNF", STD 68, RFC 5234, 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, . + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI + 10.17487/RFC5322, October 2008, + . [RFC5891] Klensin, J., "Internationalized Domain Names in - Applications (IDNA): Protocol", RFC 5891, - DOI 10.17487/RFC5891, August 2010, . + Applications (IDNA): Protocol", RFC 5891, 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, . + Address Text Representation", RFC 5952, 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 - 2011, . + 2011, . [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, - . + . [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, - . + the Reporting of Mail System Administrative Messages", 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, . + 2012, . - [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", - RFC 7405, DOI 10.17487/RFC7405, December 2014, - . + [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, . - [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, - DOI 10.17487/RFC7493, March 2015, . + [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, + . 10.2. Informative References [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, - February 2002, . + 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, . - - [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/RFC3864, September 2004, + . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, - December 2014, . + December 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April - 2015, . + 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, - . + . Authors' Addresses Daniel Margolis Google, Inc Email: dmargolis (at) google.com Alexander Brotman Comcast, Inc