--- 1/draft-ietf-uta-smtp-tlsrpt-07.txt 2017-08-15 10:13:11.527733813 -0700 +++ 2/draft-ietf-uta-smtp-tlsrpt-08.txt 2017-08-15 10:13:11.575734961 -0700 @@ -1,25 +1,25 @@ Using TLS in Applications D. Margolis Internet-Draft Google, Inc Intended status: Standards Track A. Brotman -Expires: February 1, 2018 Comcast, Inc +Expires: February 16, 2018 Comcast, Inc B. Ramakrishnan Yahoo!, Inc J. Jones Microsoft, Inc M. Risher Google, Inc - July 31, 2017 + August 15, 2017 SMTP TLS Reporting - draft-ietf-uta-smtp-tlsrpt-07 + draft-ietf-uta-smtp-tlsrpt-08 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 February 1, 2018. + This Internet-Draft will expire on February 16, 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 @@ -79,33 +79,35 @@ 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15 + 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15 - 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 15 - 6.4. application/tlsrpt+gz Media Type . . . . . . . . . . . . 17 + 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 16 + 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 17 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19 - 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 @@ -174,45 +176,51 @@ 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 Section 4, - "Reporting Schema", for more information). Two URI schemes are - supported: "mailto" and "https". + 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. + ([RFC2818]) 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. + 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. The formal definition of the "_smtp-tlsrpt" TXT record, defined using [RFC5234], is as follows: tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua [field-delim [tlsrpt-extensions]] field-delim = %x3B ; ";" tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52 %x50 %x54 %x76 %x31 ; "v=TLSRPTv1" - tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..." + tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP + tlsrpt-uri *(*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 @@ -263,41 +271,43 @@ * A unique identifier for the report * The reporting date range for the report o Policy, consisting of: * One of the following policy types: (1) The MTA-STS policy applied (as a string) (2) The DANE TLSA record applied (as a string, with each RR entry of the RRset listed and separated by a semicolon) (3) The literal string "no-policy-found", if - neither a TLSA nor MTA-STS policy could be found. + neither a DANE nor MTA-STS policy could be found. * The domain for which the policy is applied * The MX host * 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. 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. + 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 4.2.1. Success Count o "success-count": This indicates that the sending MTA was able to 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 @@ -345,21 +355,25 @@ 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. + 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. 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 @@ -443,26 +457,25 @@ MTA-STS policy. 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. 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]. + 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. o "result-type": A value from Section 4.3, "Result Types", above. - In the case of Internationalized Domain Names ([RFC5891]), the - domain is the Punycode-encoded A-label ([RFC3492]) and not the - U-label. 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. @@ -482,32 +495,33 @@ 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. 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 + 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. 5.1. Report Filename - The filename is typically constructed using the following ABNF: + The filename is RECOMMENDED to be constructed using the following + ABNF: filename = sender "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension unique-id = 1*(ALPHA / DIGIT) sender = domain ; imported from [@!RFC5321] policy-domain = domain @@ -560,24 +574,26 @@ TLS-Report-Submitter: Sender-Domain These message headers MUST be included and should allow for easy searching for all reports submitted by a report domain or a particular submitter, for example in IMAP [RFC3501]: "s SEARCH HEADER "TLS-Report-Domain" "example.com"" It is presumed that the aggregate reporting address will be equipped to process new message header fields and extract MIME parts with the - prescribed media type and filename, and ignore the rest. + prescribed media type and filename, and ignore the rest. These + additional headers SHOULD be included in the DKIM [RFC6376] signature + for the message. - The [RFC5322].Subject field for individual report submissions SHOULD - conform to the following ABNF: + The [RFC5322].Subject field for report submissions SHOULD conform to + the following ABNF: tlsrpt-subject = %s"Report" FWS ; "Report" %s"Domain:" FWS ; "Domain:" domain-name FWS ; per RFC6376 %s"Submitter:" FWS ; "Submitter:" domain-name FWS ; per RFC6376 %s"Report-ID:" FWS ; "Report-ID: "<" id-left "@" id-right ">" ; per RFC5322 [CFWS] ; per RFC5322 (as with FWS) @@ -631,32 +647,40 @@ ------=_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 + report SHOULD use the media type "application/tlsrpt+gzip", and "application/tlsrpt+json" otherwise (see section Section 6, "IANA Considerations"). 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. + 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]. @@ -720,48 +744,45 @@ 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+gz Media Type +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: Encoding considerations are identical to - those specified for the "application/json" media type. See - [RFC7493]. + 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 @@ -874,82 +897,71 @@ "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "policy": { "policy-type": "sts", "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_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/ report_info?id=5065427c-23d3#StarttlsNotSupported" }, { - "result-type: "validation-failure", + "result-type": "validation-failure", "sending-mta-ip": "47.97.15.2", - "receiving-mx-hostname: "mx-backup.mail.company-y.com", + "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 "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". -10. Normative References +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, . - [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, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . - [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, - . - [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, . @@ -975,51 +987,71 @@ 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, . + [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, . [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, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 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, . + + [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, + . + [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, . - [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI - 10.17487/RFC7493, March 2015, - . - Authors' Addresses Daniel Margolis Google, Inc Email: dmargolis (at) google.com Alexander Brotman Comcast, Inc