idnits 2.17.1 draft-ietf-uta-smtp-tlsrpt-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2018) is 2213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 670, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-uta-mta-sts-14 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Using TLS in Applications D. Margolis 3 Internet-Draft Google, Inc 4 Intended status: Standards Track A. Brotman 5 Expires: October 6, 2018 Comcast, Inc 6 B. Ramakrishnan 7 Yahoo!, Inc 8 J. Jones 9 Microsoft, Inc 10 M. Risher 11 Google, Inc 12 April 4, 2018 14 SMTP TLS Reporting 15 draft-ietf-uta-smtp-tlsrpt-18 17 Abstract 19 A number of protocols exist for establishing encrypted channels 20 between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and 21 MTA-STS. These protocols can fail due to misconfiguration or active 22 attack, leading to undelivered messages or delivery over unencrypted 23 or unauthenticated channels. This document describes a reporting 24 mechanism and format by which sending systems can share statistics 25 and specific information about potential failures with recipient 26 domains. Recipient domains can then use this information to both 27 detect potential attackers and diagnose unintentional 28 misconfigurations. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 67 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 7 69 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7 70 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7 71 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8 73 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8 74 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8 75 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8 76 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 9 78 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9 79 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 10 80 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10 81 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10 82 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13 83 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14 85 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15 87 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16 88 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17 89 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18 90 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18 93 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 19 95 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 20 96 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 21 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 100 8.2. Informative References . . . . . . . . . . . . . . . . . 25 101 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 25 102 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 26 103 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 26 104 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 107 1. Introduction 109 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 110 hosts to establish secure SMTP sessions over TLS. The protocol 111 design uses an approach that has come to be known as "Opportunistic 112 Security" (OS) [RFC7435], which maintains interoperability with 113 clients that do not support STARTTLS but means that any attacker who 114 can delete parts of the SMTP session (such as the "250 STARTTLS" 115 response) or redirect the entire SMTP session (perhaps by overwriting 116 the resolved MX record of the delivery domain) can perform a 117 downgrade or interception attack. 119 Because such "downgrade attacks" are not necessarily apparent to the 120 receiving MTA, this document defines a mechanism for sending domains 121 to report on failures at multiple stages of the MTA-to-MTA 122 conversation. 124 Recipient domains may also use the mechanisms defined by MTA-STS 125 [I-D.ietf-uta-mta-sts] or DANE [RFC6698] to publish additional 126 encryption and authentication requirements; this document defines a 127 mechanism for sending domains that are compatible with MTA-STS or 128 DANE to share success and failure statistics with recipient domains. 130 Specifically, this document defines a reporting schema that covers 131 failures in routing, DNS resolution, STARTTLS negotiation, and both 132 DANE [RFC6698] and MTA-STS [I-D.ietf-uta-mta-sts] policy validation 133 errors, and a standard TXT record that recipient domains can use to 134 indicate where reports in this format should be sent. The report can 135 also serve as a heartbeat that systems are successfully negotiating 136 TLS during sessions as expected. 138 This document is intended as a companion to the specification for 139 SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts], as well as 140 adds reporting abilities for those implementing DANE [RFC7672]. 142 1.1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 We also define the following terms for further use in this document: 150 o MTA-STS Policy: A definition of the expected TLS availability, 151 behavior, and desired actions for a given domain when a sending 152 MTA encounters problems in negotiating a secure channel. MTA-STS 153 is defined in [I-D.ietf-uta-mta-sts]. 155 o DANE Policy: A mechanism by which administrators can supply a 156 record that can be used to validate the certificate presented by 157 an MTA. DANE is defined in [RFC6698] and [RFC7672]. 159 o TLSRPT Policy: A policy specifying the endpoint to which sending 160 MTAs should deliver reports. 162 o Policy Domain: The domain against which an MTA-STS or DANE Policy 163 is defined. 165 o Sending MTA: The MTA initiating the relay of an email message. 167 2. Related Technologies 169 o This document is intended as a companion to the specification for 170 SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts]. 172 o SMTP-TLSRPT defines a mechanism for sending domains that are 173 compatible with MTA-STS or DANE to share success and failure 174 statistics with recipient domains. DANE is defined in [RFC6698] 175 and MTA-STS is defined in [I-D.ietf-uta-mta-sts]. 177 3. Reporting Policy 179 A domain publishes a record to its DNS indicating that it wishes to 180 receive reports. These SMTP TLSRPT policies are distributed via DNS 181 from the Policy Domain's zone, as TXT records (similar to DMARC 182 policies) under the name "_smtp._tls". For example, for the Policy 183 Domain "example.com", the recipient's TLSRPT policy can be retrieved 184 from "_smtp._tls.example.com". 186 Policies consist of the following directives: 188 o "v": This value MUST be equal to "TLSRPTv1". 190 o "rua": A URI specifying the endpoint to which aggregate 191 information about policy validation results should be sent (see 192 Section 4, "Reporting Schema", for more information). Two URI 193 schemes are supported: "mailto" and "https". As with DMARC 194 [RFC7489], the policy domain can specify a comma-separated list of 195 URIs. 197 o In the case of "https", reports should be submitted via POST 198 ([RFC7231]) to the specified URI. Report submitters MAY ignore 199 certificate validation errors when submitting reports via https. 201 o In the case of "mailto", reports should be submitted to the 202 specified email address ([RFC6068]). When sending failure reports 203 via SMTP, sending MTAs MUST deliver reports despite any TLS- 204 related failures and SHOULD NOT include this SMTP session in the 205 next report. This may mean that the reports are delivered in the 206 clear. Additionally, reports sent via SMTP MUST contain a valid 207 DKIM [RFC6376] signature by the reporting domain. Reports lacking 208 such a signature MUST be ignored by the recipient. DKIM 209 signatures must not use the "l=" attribute to limit the body 210 length used in the signature. 212 The formal definition of the "_smtp._tls" TXT record, defined using 213 [RFC5234] & [RFC7405], is as follows: 215 tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) 216 [field-delim] 218 field-delim = *WSP ";" *WSP 220 tlsrpt-field = tlsrpt-rua / ; Note that the 221 tlsrpt-extension ; tlsrpt-rua record is 222 ; required. 224 tlsrpt-version = %s"v=TLSRPTv1" 226 tlsrpt-rua = %s"rua=" 227 tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) 229 tlsrpt-uri = URI 230 ; "URI" is imported from [RFC3986]; 231 ; commas (ASCII 0x2C), exclamation 232 ; points (ASCII 0x21), and semicolons 233 ; (ASCII 0x3B) MUST be encoded 235 tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value 237 tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / 238 DIGIT / "_" / "-" / ".") 240 tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) 241 ; chars excluding "=", ";", SP, and control 242 ; chars 244 If multiple TXT records for "_smtp._tls" are returned by the 245 resolver, records which do not begin with "v=TLSRPTv1;" are 246 discarded. If the number of resulting records is not one, senders 247 MUST assume the recipient domain does not implement TLSRPT. If the 248 resulting TXT record contains multiple strings, then the record MUST 249 be treated as if those strings are concatenated together without 250 adding spaces. 252 The record supports the abillity to declare more than one rua, and if 253 there exists more than one, the reporter MAY attempt to deliver to 254 each of the supported rua destinations. A receiver MAY opt to only 255 attempt delivery to one of the endpoints, however the report SHOULD 256 NOT be considered successfully delivered until one of the endpoints 257 accepts delivery of the report. If the reporter does not support one 258 of the report mechanisms, then it SHOULD NOT attempt delivery to 259 those rua destinations. 261 Parsers MUST accept TXT records which are syntactically valid (i.e. 262 valid key-value pairs separated by semi-colons) and implementing a 263 superset of this specification, in which case unknown fields SHALL be 264 ignored. 266 3.1. Example Reporting Policy 268 3.1.1. Report using MAILTO 270 _smtp._tls.example.com. IN TXT \ 271 "v=TLSRPTv1;rua=mailto:reports@example.com" 273 3.1.2. Report using HTTPS 275 _smtp._tls.example.com. IN TXT \ 276 "v=TLSRPTv1; \ 277 rua=https://reporting.example.com/v1/tlsrpt" 279 4. Reporting Schema 281 The report is composed as a plain text file encoded in the I-JSON 282 format ([RFC7493]). 284 Aggregate reports contain the following fields: 286 o Report metadata: 288 * The organization responsible for the report 290 * Contact information for one or more responsible parties for the 291 contents of the report 293 * A unique identifier for the report 295 * The reporting date range for the report 297 o Policy, consisting of: 299 * One of the following policy types: (1) The MTA-STS policy 300 applied (as a string) (2) The DANE TLSA record applied (as a 301 string, with each RR entry of the RRset listed and separated by 302 a semicolon) (3) The literal string "no-policy-found", if 303 neither a DANE nor MTA-STS policy could be found. 305 * The domain for which the policy is applied 307 * The MX host 309 o Aggregate counts, comprising result type, sending MTA IP, 310 receiving MTA hostname, session count, and an optional additional 311 information field containing a URI for recipients to review 312 further information on a failure type. 314 Note that the failure types are non-exclusive; an aggregate report 315 may contain overlapping "counts" of failure types when a single send 316 attempt encountered multiple errors. Reporters may report multiple 317 applied policies (for example, an MTA-STS policy and a DANE TLSA 318 record for the same domain and MX); even in the case where only a 319 single policy was applied, the "policies" field of the report body 320 MUST be an array and not a singular value. 322 In the case of multiple failure types, the "failure-details" array 323 would contain multiple entries. Each entry would have its own set of 324 infomation pertaining to that failure type. 326 4.1. Report Time-frame 328 The report SHOULD cover a full day, from 0000-2400 UTC. This should 329 allow for easier correlation of failure events. To avoid a Denial of 330 Service against the system processing the reports, the reports should 331 be delivered after some delay, perhaps several hours. 333 4.2. Delivery Summary 335 4.2.1. Success Count 337 o "total-successful-session-count": This indicates that the sending 338 MTA was able to successfully negotiate a policy-compliant TLS 339 connection, and serves to provide a "heartbeat" to receiving 340 domains that reporting is functional and tabulating correctly. 341 This field contains an aggregate count of successful connections 342 for the reporting system. 344 4.2.2. Failure Count 346 o "total-failure-session-count": This indicates that the sending MTA 347 was unable to successfully establish a connection with the 348 receiving platform. Section 4.3, "Result Types", will elaborate 349 on the failed negotiation attempts. This field contains an 350 aggregate count of failed connections. 352 4.3. Result Types 354 The list of result types will start with the minimal set below, and 355 is expected to grow over time based on real-world experience. The 356 initial set is: 358 4.3.1. Negotiation Failures 360 o "starttls-not-supported": This indicates that the recipient MX did 361 not support STARTTLS. 363 o "certificate-host-mismatch": This indicates that the certificate 364 presented did not adhere to the constraints specified in the MTA- 365 STS or DANE policy, e.g. if the MX hostname does not match any 366 identities listed in the Subject Alternate Name (SAN) [RFC5280]. 368 o "certificate-expired": This indicates that the certificate has 369 expired. 371 o "certificate-not-trusted": This a label that covers multiple 372 certificate related failures that include, but not limited to 373 errors such as untrusted/unknown CAs, certificate name 374 constraints, certificate chain errors etc. When using this 375 declaration, the reporting MTA SHOULD utilize the "failure-reason- 376 code" to provide more information to the receiving entity. 378 o "validation-failure": This indicates a general failure for a 379 reason not matching a category above. When using this 380 declaration, the reporting MTA SHOULD utilize the "failure-reason- 381 code" to provide more information to the receiving entity. 383 4.3.2. Policy Failures 385 4.3.2.1. DANE-specific Policy Failures 387 o "tlsa-invalid": This indicates a validation error in the TLSA 388 record associated with a DANE policy. None of the records in the 389 RRset were found to be valid. 391 o "dnssec-invalid": This would indicate that no valid records were 392 returned from the recursive resolver. The request returned with 393 SERVFAIL for the requested TLSA record. 395 o "dane-required": This indicates that the sending system is 396 configured to require DANE TLSA records for all the MX hosts of 397 the destination domain, but no DNSSEC-validated TLSA records were 398 present for the MX host that is the subject of the report. 399 Mandatory DANE for SMTP is described in section 6 of [RFC7672]. 400 Such policies may be created by mutual agreement between two 401 organizations that frequently exchange sensitive content via 402 email. 404 4.3.2.2. MTA-STS-specific Policy Failures 406 o "sts-policy-invalid": This indicates a validation error for the 407 overall MTA-STS policy. 409 o "sts-webpki-invalid": This indicates that the MTA-STS policy could 410 not be authenticated using PKIX validation. 412 4.3.3. General Failures 414 When a negotiation failure can not be categorized into one of the 415 "Negotiation Failures" stated above, the reporter SHOULD use the 416 "validation-failure" category. As TLS grows and becomes more 417 complex, new mechanisms may not be easily categorized. This allows 418 for a generic feedback category. When this category is used, the 419 reporter SHOULD also use the "failure-reason-code" to give some 420 feedback to the receiving entity. This is intended to be a short 421 text field, and the contents of the field should be an error code or 422 error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION". 424 4.3.4. Transient Failures 426 Transient errors due to too-busy network, TCP timeouts, etc. are not 427 required to be reported. 429 4.4. JSON Report Schema 431 The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. 432 Section 3) 434 { 435 "organization-name": organization-name, 436 "date-range": { 437 "start-datetime": date-time, 438 "end-datetime": date-time 439 }, 440 "contact-info": email-address, 441 "report-id": report-id, 442 "policies": [{ 443 "policy": { 444 "policy-type": policy-type, 445 "policy-string": policy-string, 446 "policy-domain": domain, 447 "mx-host": mx-host-pattern 448 }, 449 "summary": { 450 "total-successful-session-count": total-successful-session-count, 451 "total-failure-session-count": total-failure-session-count 452 }, 453 "failure-details": [ 454 { 455 "result-type": result-type, 456 "sending-mta-ip": ip-address, 457 "receiving-mx-hostname": receiving-mx-hostname, 458 "receiving-mx-helo": receiving-mx-helo, 459 "receiving-ip": receiving-ip, 460 "failed-session-count": failed-session-count, 461 "additional-information": additional-info-uri, 462 "failure-reason-code": failure-reason-code 463 } 464 ] 465 } 466 ] 467 } 469 JSON Report Format 471 o "organization-name": The name of the organization responsible for 472 the report. It is provided as a string. 474 o "date-time": The date-time indicates the start- and end-times for 475 the report range. It is provided as a string formatted according 476 to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The 477 report should be for a full UTC day, 0000-2400. 479 o "email-address": The contact information for a responsible party 480 of the report. It is provided as a string formatted according to 481 Section 3.4.1, "Addr-Spec", of [RFC5321]. 483 o "report-id": A unique identifier for the report. Report authors 484 may use whatever scheme they prefer to generate a unique 485 identifier. It is provided as a string. 487 o "policy-type": The type of policy that was applied by the sending 488 domain. Presently, the only three valid choices are "tlsa", 489 "sts", and the literal string "no-policy-found". It is provided 490 as a string. 492 o "policy-string": An encoding of the applied policy as a JSON array 493 of strings, whether TLSA record ([RFC6698] section 2.3) or MTA-STS 494 policy. Examples follow in the next section. 496 o "domain": The Policy Domain is the domain against which the MTA- 497 STS or DANE policy is defined. In the case of Internationalized 498 Domain Names ([RFC5891]), the domain MUST consist of the Punycode- 499 encoded A-labels ([RFC3492]) and not the U-labels. 501 o "mx-host-pattern": The pattern of MX hostnames from the applied 502 policy. It is provided as a string, and is interpreted in the 503 same manner as the "Checking of Wildcard Certificates" rules in 504 Section 6.4.3 of [RFC6125]. In the case of Internationalized 505 Domain Names ([RFC5891]), the domain MUST consist of the Punycode- 506 encoded A-labels ([RFC3492]) and not the U-labels. 508 o "result-type": A value from Section 4.3, "Result Types", above. 510 o "ip-address": The IP address of the sending MTA that attempted the 511 STARTTLS connection. It is provided as a string representation of 512 an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or 513 colon-hexadecimal notation. 515 o "receiving-mx-hostname": The hostname of the receiving MTA MX 516 record with which the sending MTA attempted to negotiate a 517 STARTTLS connection. 519 o "receiving-mx-helo": (optional) The HELO or EHLO string from the 520 banner announced during the reported session. 522 o "receiving-ip": The destination IP address that was using when 523 creating the outbound session. It is provided as a string 524 representation of an IPv4 (see below) or IPv6 ([RFC5952]) address 525 in dot-decimal or colon-hexadecimal notation. 527 o "total-successful-session-count": The aggregate number (integer) 528 of successfully negotiated TLS-enabled connections to the 529 receiving site. 531 o "total-failure-session-count": The aggregate number (integer) of 532 failures to negotiate a TLS-enabled connection to the receiving 533 site. 535 o "failed-session-count": The number of (attempted) sessions that 536 match the relevant "result-type" for this section. 538 o "additional-info-uri": An optional URI [RFC3986] pointing to 539 additional information around the relevant "result-type". For 540 example, this URI might host the complete certificate chain 541 presented during an attempted STARTTLS session. 543 o "failure-reason-code": A text field to include a TLS-related error 544 code or error message. 546 For report purposes, an IPv4 Address is defined as: IPv4address = 547 dec-octet "." dec-octet "." dec-octet "." dec-octet 548 dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 549 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 551 4.5. Policy Samples 553 Part of the report body includes the policy that is applied when 554 attemping relay to the destination. 556 For DANE TLSA policies, a JSON array of strings each representing the 557 RDATA of a single TLSA resource record as a space-separated list of 558 its four TLSA fields; the fields are in presentation format (defined 559 in RFC6698 Section 2.2) with no internal spaces or grouping 560 parentheses: 562 [ "3 0 1 563 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", "3 564 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234" 565 ] 567 For the MTA-STS policy, an array of JSON strings that represents the 568 policy that is declared by the receiving site, including any errors 569 that may be present. Note that where there are multiple "mx" values, 570 they must be listed as separate "mx" elements in the policy array, 571 rather as a single nested "mx" sub-array. 573 [ "version: STSv1", "mode: report", "mx: mx1.example.com", "mx: 574 mx2.example.com", "mx: mx.backup-example.com", "max_age: 12345678" ] 576 5. Report Delivery 578 Reports can be delivered either as an email message via SMTP or via 579 HTTP POST. 581 5.1. Report Filename 583 The filename is RECOMMENDED to be constructed using the following 584 ABNF: 586 filename = sender "!" policy-domain "!" begin-timestamp 587 "!" end-timestamp [ "!" unique-id ] "." extension 589 unique-id = 1*(ALPHA / DIGIT) 591 sender = domain ; From the [RFC5321] that is used 592 ; as the domain for the `contact-info` 593 ; address in the report body 595 policy-domain = domain 597 begin-timestamp = 1*DIGIT 598 ; seconds since 00:00:00 UTC January 1, 1970 599 ; indicating start of the time range contained 600 ; in the report 602 end-timestamp = 1*DIGIT 603 ; seconds since 00:00:00 UTC January 1, 1970 604 ; indicating end of the time range contained 605 ; in the report 607 extension = "json" / "json.gz" 609 The extension MUST be "json" for a plain JSON file, or "json.gz" for 610 a JSON file compressed using GZIP. 612 "unique-id" allows an optional unique ID generated by the Sending MTA 613 to distinguish among multiple reports generated simultaneously by 614 different sources within the same Policy Domain. For example, this 615 is a possible filename for a compressed report to the Policy Domain 616 "example.net" from the Sending MTA "mail.sndr.example.com": 618 "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz" 620 5.2. Compression 622 The report SHOULD be subjected to GZIP compression for both email and 623 HTTPS transport. Declining to apply compression can cause the report 624 to be too large for a receiver to process (a commonly observed 625 receiver limit is ten megabytes); compressing the file increases the 626 chances of acceptance of the report at some compute cost. 628 5.3. Email Transport 630 The report MAY be delivered by email. To make the reports machine- 631 parsable for the receivers, we define a top-level media type 632 "multipart/report" with a new parameter "report-type="tlsrpt"". 633 Inside it, there are two parts: The first part is human readable, 634 typically "text/plain", and the second part is machine readable with 635 a new media type defined called "application/tlsrpt+json". If 636 compressed, the report should use the media type "application/ 637 tlsrpt+gzip". 639 In addition, the following two new top level message header fields 640 are defined: 642 "TLS-Report-Domain: Receiver-Domain" 644 "TLS-Report-Submitter: Sender-Domain" 646 The "TLS-Report-Submitter" value MUST match the value found in the 647 [RFC5321] domain from the "contact-info" from the report body. These 648 message headers MUST be included and should allow for easy searching 649 for all reports submitted by a report domain or a particular 650 submitter, for example in IMAP [RFC3501]: 652 "s SEARCH HEADER "TLS-Report-Domain" "example.com"" 654 It is presumed that the aggregate reporting address will be equipped 655 to process new message header fields and extract MIME parts with the 656 prescribed media type and filename, and ignore the rest. These 657 additional headers SHOULD be included in the DKIM [RFC6376] signature 658 for the message. 660 The [RFC5322].Subject field for report submissions SHOULD conform to 661 the following ABNF: 663 tlsrpt-subject = %s"Report" FWS ; "Report" 664 %s"Domain:" FWS ; "Domain:" 665 domain-name FWS ; per [RFC6376] 666 %s"Submitter:" FWS ; "Submitter:" 667 domain-name FWS ; per [RFC6376] 668 %s"Report-ID:" FWS ; "Report-ID: 669 "<" id-left "@" id-right ">" ; per [RFC5322] 670 [CFWS] ; per [RFC5322] 671 ; (as with FWS) 673 The first domain-name indicates the DNS domain name about which the 674 report was generated. The second domain-name indicates the DNS 675 domain name representing the Sending MTA generating the report. The 676 purpose of the Report-ID: portion of the field is to enable the 677 Policy Domain to identify and ignore duplicate reports that might be 678 sent by a Sending MTA. 680 For instance, this is a possible Subject field for a report to the 681 Policy Domain "example.net" from the Sending MTA 682 "mail.sender.example.com". It is line-wrapped as allowed by 683 [RFC5322]: 685 Subject: Report Domain: example.net 686 Submitter: mail.sender.example.com 687 Report-ID: <735ff.e317+bf22029@mailexample.net> 689 5.3.1. Example Report 690 From: tlsrpt@mail.sender.example.com 691 Date: Fri, May 09 2017 16:54:30 -0800 692 To: mts-sts-tlsrpt@example.net 693 Subject: Report Domain: example.net 694 Submitter: mail.sender.example.com 695 Report-ID: <735ff.e317+bf22029@example.net> 696 TLS-Report-Domain: example.net 697 TLS-Report-Submitter: mail.sender.example.com 698 MIME-Version: 1.0 699 Content-Type: multipart/report; report-type="tlsrpt"; 700 boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00" 701 Content-Language: en-us 703 This is a multipart message in MIME format. 705 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 706 Content-Type: text/plain; charset="us-ascii" 707 Content-Transfer-Encoding: 7bit 709 This is an aggregate TLS report from mail.sender.example.com 711 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 712 Content-Type: application/tlsrpt+gzip 713 Content-Transfer-Encoding: base64 714 Content-Disposition: attachment; 715 filename="mail.sender.example!example.com! 716 1013662812!1013749130.json.gz" 718 720 ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- 721 ... 723 Note that, when sending failure reports via SMTP, sending MTAs MUST 724 NOT honor MTA-STS or DANE TLSA failures. 726 5.4. HTTPS Transport 728 The report MAY be delivered by POST to HTTPS. If compressed, the 729 report SHOULD use the media type "application/tlsrpt+gzip", and 730 "application/tlsrpt+json" otherwise (see section Section 6, "IANA 731 Considerations"). 733 A reporting entity SHOULD expect a "successful" response from the 734 accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. 735 Other codes could indicate a delivery failure, and may be retried as 736 per local policy. The receiving system is not expected to process 737 reports at receipt time, and MAY store them for processing at a later 738 time. 740 Alternately, if a receiving system offers "Accept-Encoding" value of 741 "gzip", the sending system MAY use "Content-Encoding: gzip" as an 742 HTTP header as appropriate. This can be used in place of delivering 743 a compressed file as the payload. 745 5.5. Delivery Retry 747 In the event of a delivery failure, regardless of the delivery 748 method, a sender SHOULD attempt redelivery for up to 24hrs after the 749 initial attempt. As previously stated the reports are optional, so 750 while it is ideal to attempt redelivery, it is not required. If 751 multiple retries are attempted, ideally they SHOULD be done with 752 exponential backoff. 754 5.6. Metadata Variances 756 As stated above, there are a variable number of ways to declare 757 information about the data therein. If any of items declared via 758 subject or filename disagree with the report, the report MUST be 759 considered the authoritative source. 761 6. IANA Considerations 763 The following are the IANA considerations discussed in this document. 765 6.1. Message headers 767 Below is the Internet Assigned Numbers Authority (IANA) Permanent 768 Message Header Field registration information per [RFC3864]. 770 Header field name: TLS-Report-Domain 771 Applicable protocol: mail 772 Status: standard 773 Author/Change controller: IETF 774 Specification document(s): this one 776 Header field name: TLS-Report-Submitter 777 Applicable protocol: mail 778 Status: standard 779 Author/Change controller: IETF 780 Specification document(s): this one 782 6.2. Report Type 784 This document registers a new parameter "report-type="tlsrpt"" under 785 "multipart/report" top-level media type for use with [RFC6522]. 787 The media type suitable for use as a report-type is defined in the 788 following section. 790 6.3. application/tlsrpt+json Media Type 792 This document registers multiple media types, beginning with Table 1 793 below. 795 +-------------+----------------+-------------+-------------------+ 796 | Type | Subtype | File extn | Specification | 797 +-------------+----------------+-------------+-------------------+ 798 | application | tlsrpt+json | .json | Section 5.3 | 799 +-------------+----------------+-------------+-------------------+ 800 Table 1: SMTP TLS Reporting Media Type 802 Type name: application 804 Subtype name: tlsrpt+json 806 Required parameters: n/a 808 Optional parameters: n/a 810 Encoding considerations: Encoding considerations are identical to 811 those specified for the "application/json" media type. See 812 [RFC7493]. 814 Security considerations: Security considerations relating to SMTP TLS 815 Reporting are discussed in Section 7. 817 Interoperability considerations: This document specifies format of 818 conforming messages and the interpretation thereof. 820 Published specification: Section 5.3 of this document. 822 Applications that use this media type: Mail User Agents (MUA) and 823 Mail Transfer Agents. 825 Additional information: 827 Magic number(s): n/a 829 File extension(s): ".json" 831 Macintosh file type code(s): n/a 833 Person & email address to contact for further information: See 834 Authors' Addresses section. 836 Intended usage: COMMON 838 Restrictions on usage: n/a 840 Author: See Authors' Addresses section. 842 Change controller: Internet Engineering Task Force 843 (mailto:iesg@ietf.org). 845 6.4. application/tlsrpt+gzip Media Type 847 +-------------+----------------+-------------+-------------------+ 848 | Type | Subtype | File extn | Specification | 849 +-------------+----------------+-------------+-------------------+ 850 | application | tlsrpt+gzip | .gz | Section 5.3 | 851 +-------------+----------------+-------------+-------------------+ 852 Table 2: SMTP TLS Reporting Media Type 854 Type name: application 856 Subtype name: tlsrpt+gzip 858 Required parameters: n/a 860 Optional parameters: n/a 862 Encoding considerations: Binary 864 Security considerations: Security considerations relating to SMTP TLS 865 Reporting are discussed in Section 7. 867 Interoperability considerations: This document specifies format of 868 conforming messages and the interpretation thereof. 870 Published specification: Section 5.3 of this document. 872 Applications that use this media type: Mail User Agents (MUA) and 873 Mail Transfer Agents. 875 Additional information: 877 Magic number(s): n/a 879 File extension(s): ".gz" 881 Macintosh file type code(s): n/a 883 Person & email address to contact for further information: See 884 Authors' Addresses section. 886 Intended usage: COMMON 888 Restrictions on usage: n/a 890 Author: See Authors' Addresses section. 892 Change controller: Internet Engineering Task Force 893 (mailto:iesg@ietf.org). 895 6.5. STARTTLS Validation Result Types 897 This document creates a new registry, "STARTTLS Validation Result 898 Types". The initial entries in the registry are: 900 +-------------------------------+ 901 | Result Type | 902 +-------------------------------+ 903 | "starttls-not-supported" | 904 | "certificate-host-mismatch" | 905 | "certificate-expired" | 906 | "tlsa-invalid" | 907 | "dnssec-invalid" | 908 | "dane-required" | 909 | "certificate-not-trusted" | 910 | "sts-policy-invalid" | 911 | "sts-webpki-invalid" | 912 | "validation-failure" | 913 +-------------------------------+ 915 The above entries are described in section Section 4.3, "Result 916 Types." New result types can be added to this registry using "Expert 917 Review" IANA registration policy. 919 7. Security Considerations 921 SMTP TLS Reporting provides transparency into misconfigurations or 922 attempts to intercept or tamper with mail between hosts who support 923 STARTTLS. There are several security risks presented by the 924 existence of this reporting channel: 926 o Flooding of the Aggregate report URI (rua) endpoint: An attacker 927 could flood the endpoint with excessive reporting traffic and 928 prevent the receiving domain from accepting additional reports. 929 This type of Denial-of-Service attack would limit visibility into 930 STARTTLS failures, leaving the receiving domain blind to an 931 ongoing attack. 933 o Untrusted content: An attacker could inject malicious code into 934 the report, opening a vulnerability in the receiving domain. 935 Implementers are advised to take precautions against evaluating 936 the contents of the report. 938 o Report snooping: An attacker could create a bogus TLSRPT record to 939 receive statistics about a domain the attacker does not own. 940 Since an attacker able to poison DNS is already able to receive 941 counts of SMTP connections (and, absent DANE or MTA-STS policies, 942 actual SMTP message payloads), this does not present a significant 943 new vulnerability. 945 o Reports as DDoS: TLSRPT allows specifying destinations for the 946 reports that are outside the authority of the Policy Domain, which 947 allows domains to delegate processing of reports to a partner 948 organization. However, an attacker who controls the Policy Domain 949 DNS could also use this mechanism to direct the reports to an 950 unwitting victim, flooding that victim with excessive reports. 951 DMARC [RFC7489] defines a solution for verifying delegation to 952 avoid such attacks; the need for this is greater with DMARC, 953 however, because DMARC allows an attacker to trigger reports to a 954 target from an innocent third party by sending that third party 955 mail (which triggers a report from the third party to the target). 956 In the case of TLSRPT, the attacker would have to induce the third 957 party to send the attacker mail in order to trigger reports from 958 the third party to the victim; this reduces the risk of such an 959 attack and the need for a verification mechanism. 961 Finally, because TLSRPT is intended to help administrators discover 962 man-in-the-middle attacks against transport-layer encryption, 963 including attacks designed to thwart negotiation of encrypted 964 connections (by downgrading opportunistic encryption or, in the case 965 of MTA-STS, preventing discovery of a new MTA-STS policy), we must 966 also consider the risk that an adversary who can induce such a 967 downgrade attack can also prevent discovery of the TLSRPT TXT record 968 (and thus prevent discovery of the successful downgrade attack). 969 Administrators are thus encouraged to deploy TLSRPT TXT records with 970 a large TTL (reducing the window for successful attacks against DNS 971 resolution of the record) or to deploy DNSSEC on the deploying zone. 973 8. References 975 8.1. Normative References 977 [I-D.ietf-uta-mta-sts] 978 Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., 979 and J. Jones, "SMTP MTA Strict Transport Security (MTA- 980 STS)", draft-ietf-uta-mta-sts-14 (work in progress), 981 January 2018. 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, 985 DOI 10.17487/RFC2119, March 1997, . 988 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 989 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 990 . 992 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 993 for Internationalized Domain Names in Applications 994 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 995 . 997 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 998 Resource Identifier (URI): Generic Syntax", STD 66, 999 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1000 . 1002 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1003 Specifications: ABNF", STD 68, RFC 5234, 1004 DOI 10.17487/RFC5234, January 2008, . 1007 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1008 Housley, R., and W. Polk, "Internet X.509 Public Key 1009 Infrastructure Certificate and Certificate Revocation List 1010 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1011 . 1013 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1014 DOI 10.17487/RFC5321, October 2008, . 1017 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1018 DOI 10.17487/RFC5322, October 2008, . 1021 [RFC5891] Klensin, J., "Internationalized Domain Names in 1022 Applications (IDNA): Protocol", RFC 5891, 1023 DOI 10.17487/RFC5891, August 2010, . 1026 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1027 Address Text Representation", RFC 5952, 1028 DOI 10.17487/RFC5952, August 2010, . 1031 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 1032 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 1033 . 1035 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1036 Verification of Domain-Based Application Service Identity 1037 within Internet Public Key Infrastructure Using X.509 1038 (PKIX) Certificates in the Context of Transport Layer 1039 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1040 2011, . 1042 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1043 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1044 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1045 . 1047 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 1048 the Reporting of Mail System Administrative Messages", 1049 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 1050 . 1052 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1053 of Named Entities (DANE) Transport Layer Security (TLS) 1054 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1055 2012, . 1057 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1058 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1059 DOI 10.17487/RFC7231, June 2014, . 1062 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1063 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1064 . 1066 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 1067 DOI 10.17487/RFC7493, March 2015, . 1070 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 1071 Opportunistic DNS-Based Authentication of Named Entities 1072 (DANE) Transport Layer Security (TLS)", RFC 7672, 1073 DOI 10.17487/RFC7672, October 2015, . 1076 8.2. Informative References 1078 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1079 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 1080 February 2002, . 1082 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1083 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1084 . 1086 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1087 Procedures for Message Header Fields", BCP 90, RFC 3864, 1088 DOI 10.17487/RFC3864, September 2004, . 1091 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1092 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1093 December 2014, . 1095 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1096 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1097 2015, . 1099 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1100 Message Authentication, Reporting, and Conformance 1101 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1102 . 1104 Appendix A. Example Reporting Policy 1105 A.1. Report using MAILTO 1107 _smtp._tls.mail.example.com. IN TXT \ 1108 "v=TLSRPTv1;rua=mailto:reports@example.com" 1110 A.2. Report using HTTPS 1112 _smtp._tls.mail.example.com. IN TXT \ 1113 "v=TLSRPTv1; \ 1114 rua=https://reporting.example.com/v1/tlsrpt" 1116 Appendix B. Example JSON Report 1118 Below is an example JSON report for messages from Company-X to 1119 Company-Y, where 100 sessions were attempted to Company Y servers 1120 with an expired certificate and 200 sessions were attempted to 1121 Company Y servers that did not successfully respond to the "STARTTLS" 1122 command. Additionally 3 sessions failed due to 1123 "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". 1125 { 1126 "organization-name": "Company-X", 1127 "date-range": { 1128 "start-datetime": "2016-04-01T00:00:00Z", 1129 "end-datetime": "2016-04-01T23:59:59Z" 1130 }, 1131 "contact-info": "sts-reporting@company-x.example", 1132 "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", 1133 "policies": [{ 1134 "policy": { 1135 "policy-type": "sts", 1136 "policy-string": ["version: STSv1","mode: report", 1137 "mx: .mail.company-y.example","max_age: 86400"], 1138 "policy-domain": "company-y.example", 1139 "mx-host": ".mail.company-y.example" 1140 }, 1141 "summary": { 1142 "total-successful-session-count": 5326, 1143 "total-failure-session-count": 303 1144 }, 1145 "failure-details": [{ 1146 "result-type": "certificate-expired", 1147 "sending-mta-ip": "98.136.216.25", 1148 "receiving-mx-hostname": "mx1.mail.company-y.example", 1149 "failed-session-count": 100 1150 }, { 1151 "result-type": "starttls-not-supported", 1152 "sending-mta-ip": "98.22.33.99", 1153 "receiving-mx-hostname": "mx2.mail.company-y.example", 1154 "receiving-ip": "192.168.14.72", 1155 "failed-session-count": 200, 1156 "additional-information": "https://reports.company-x.example/ 1157 report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported " 1158 }, { 1159 "result-type": "validation-failure", 1160 "sending-mta-ip": "47.97.15.2", 1161 "receiving-ip": "10.72.84.12", 1162 "receiving-mx-hostname": "mx-backup.mail.company-y.example", 1163 "failed-session-count": 3, 1164 "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" 1165 }] 1166 }] 1167 } 1169 Authors' Addresses 1171 Daniel Margolis 1172 Google, Inc 1174 Email: dmargolis@google.com 1176 Alexander Brotman 1177 Comcast, Inc 1179 Email: alex_brotman@comcast.com 1181 Binu Ramakrishnan 1182 Yahoo!, Inc 1184 Email: rbinu@oath.com 1186 Janet Jones 1187 Microsoft, Inc 1189 Email: janet.jones@microsoft.com 1191 Mark Risher 1192 Google, Inc 1194 Email: risher@google.com