idnits 2.17.1 draft-ietf-uta-smtp-tlsrpt-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 55 characters in excess of 72. ** The abstract seems to contain references ([RFC6698], [RFC3207]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 15, 2017) is 2627 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: 'TODO' is mentioned on line 140, but not defined == Missing Reference: 'SP' is mentioned on line 588, but not defined ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6713 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7435 ** Downref: Normative reference to an Informational RFC: RFC 7489 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: August 19, 2017 Comcast, Inc 6 B. Ramakrishnan 7 Yahoo!, Inc 8 J. Jones 9 Microsoft, Inc 10 M. Risher 11 Google, Inc 12 February 15, 2017 14 SMTP TLS Reporting 15 draft-ietf-uta-smtp-tlsrpt-03 17 Abstract 19 A number of protocols exist for establishing encrypted channels 20 between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE 21 [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can 22 fail due to misconfiguration or active attack, leading to undelivered 23 messages or delivery over unencrypted or unauthenticated channels. 24 This document describes a reporting mechanism and format by which 25 sending systems can share statistics and specific information about 26 potential failures with recipient domains. Recipient domains can 27 then use this information to both detect potential attackers and 28 diagnose unintentional 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 August 19, 2017. 47 Copyright Notice 49 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 67 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 69 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5 70 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5 71 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 6 73 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 74 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 75 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 77 4.3.1. Routing Failures . . . . . . . . . . . . . . . . . . 7 78 4.3.2. Negotiation Failures . . . . . . . . . . . . . . . . 7 79 4.3.3. Policy Failures . . . . . . . . . . . . . . . . . . . 8 80 4.3.4. General Failures . . . . . . . . . . . . . . . . . . 8 81 4.3.5. Transient Failures . . . . . . . . . . . . . . . . . 8 82 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 9 84 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 85 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 10 86 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 10 87 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 11 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 12 91 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 12 92 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 12 93 9. Appendix 2: JSON Report Schema . . . . . . . . . . . . . . . 12 94 10. Appendix 3: Example JSON Report . . . . . . . . . . . . . . . 15 95 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and 101 hosts to establish secure SMTP sessions over TLS. The protocol 102 design is based on "Opportunistic Security" (OS) [RFC7435], which 103 provides interoperability for clients that do not support STARTTLS 104 but means that any attacker who can delete parts of the SMTP session 105 (such as the "250 STARTTLS" response) or redirect the entire SMTP 106 session (perhaps by overwriting the resolved MX record of the 107 delivery domain) can perform a downgrade or interception attack. 109 Because such "downgrade attacks" are not necessarily apparent to the 110 receiving MTA, this document defines a mechanism for sending domains 111 to report on failures at multiple parts of the MTA-to-MTA 112 conversation. 114 Recipient domains may also use the mechanisms defined by MTA-STS 115 (TODO: Add ref) or DANE [RFC6698] to publish additional encryption 116 and authentication requirements; this document defines a mechanism 117 for sending domains that are compatible with MTA-STS or DANE to share 118 success and failure statistics with recipient domains. 120 Specifically, this document defines a reporting schema that covers 121 failures in routing, STARTTLS negotiation, and both DANE [RFC6698] 122 and MTA-STS (TODO: Add ref) policy validation errors, and a standard 123 TXT record that recipient domains can use to indicate where reports 124 in this format should be sent. 126 This document is intended as a companion to the specification for 127 SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 129 1.1. Terminology 131 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 132 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 133 document, are to be interpreted as described in [RFC2119]. 135 We also define the following terms for further use in this document: 137 o STS Policy: A definition of the expected TLS availability, 138 behavior, and desired actions for a given domain when a sending 139 MTA encounters problems in negotiating a secure channel. STS is 140 defined in [TODO] 142 o DANE Policy: A mechanism for enabling the administrators of domain 143 names to specify the keys used in that domain's TLS servers. DANE 144 is defined in [RFC6698] 146 o TLSRPT Policy: A policy specifying the endpoint to which sending 147 MTAs should deliver reports. 149 o Policy Domain: The domain against which an STS or DANE Policy is 150 defined. 152 o Sending MTA: The MTA initiating the delivery of an email message. 154 2. Related Technologies 156 o This document is intended as a companion to the specification for 157 SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). 159 o The Public Key Pinning Extension for HTTP [RFC7469] contains a 160 JSON-based definition for reporting individual pin validation 161 failures. 163 o The Domain-based Message Authentication, Reporting, and 164 Conformance (DMARC) [RFC7489] contains an XML-based reporting 165 format for aggregate and detailed email delivery errors. 167 3. Reporting Policy 169 A domain publishes a record to its DNS indicating that it wishes to 170 receive reports. These SMTP TLSRPT policies are distributed via DNS 171 from the Policy Domain's zone, as TXT records (similar to DMARC 172 policies) under the name "smtp-tlsrpt". For example, for the Policy 173 Domain "example.com", the recipient's TLSRPT policy can be retrieved 174 from "smtp-tlsrpt.example.com". 176 Policies consist of the following directives: 178 o "v": This value MUST be equal to "TLSRPTv1". 180 o "rua": A URI specifying the endpoint to which aggregate 181 information about policy failures should be sent (see the section 182 _Reporting_ _Schema_ for more information). Two URI schemes are 183 supported: "mailto" and "https". 185 * In the case of "https", reports should be submitted via POST 186 ([RFC2818]) to the specified URI. 188 * In the case of "mailto", reports should be submitted to the 189 specified email address. When sending failure reports via 190 SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA 191 failures. 193 o "ruf": Future use. (There may also be a need for enabling more 194 detailed "forensic" reporting during initial stages of a 195 deployment. To address this, the authors consider the possibility 196 of an optional additional "forensic reporting mode" in which more 197 details--such as certificate chains and MTA banners--may be 198 reported.) 200 The formal definition of the "smtp-tlsrpt" TXT record, defined using 201 [RFC5234], is as follows: 203 tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua 205 tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53 206 %x52 %x50 %x54 %x76 %x31 208 tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri 210 tlsrpt-uri = URI 211 ; "URI" is imported from [@!RFC3986]; commas (ASCII 212 ; 0x2C) and exclamation points (ASCII 0x21) 213 ; MUST be encoded; the numeric portion MUST fit 214 ; within an unsigned 64-bit integer 216 If multiple TXT records for "smtp-tlsrpt" are returned by the 217 resolver, records which do not begin with "v=TLSRPTv1;" are 218 discarded. If the number of resulting records is not one, senders 219 MUST assume the recipient domain does not implement TLSRPT. 221 3.1. Example Reporting Policy 223 3.1.1. Report using MAILTO 225 smtp-tlsrpt.example.com. IN TXT \ 226 "v=TLSRPTv1;rua=mailto:reports@example.com" 228 3.1.2. Report using HTTPS 230 smtp-tlsrpt.example.com. IN TXT \ 231 "v=TLSRPTv1; \ 232 rua=https://reporting.example.com/v1/tlsrpt" 234 4. Reporting Schema 236 The report is composed as a plain text file encoded in the JSON 237 format ([RFC7159]). 239 Aggregate reports contain the following fields: 241 o Report metadata: 243 * The organization responsible for the report 245 * Contact information for one or more responsible parties for the 246 contents of the report 248 * A unique identifier for the report 250 * The reporting date range for the report 252 o Policy, consisting of: 254 * One of the following policy types: (1) The SMTP MTA STS policy 255 applied (as a string) (2) The DANE TLSA record applied (as a 256 string) (3) The literal string "no-policy-found", if neither a 257 TLSA nor MTA-STS policy could be found. 259 * The domain for which the policy is applied 261 * The MX host 263 * An identifier for the policy (where applicable) 265 o Aggregate counts, comprising result type, sending MTA IP, 266 receiving MTA hostname, session count, and an optional additional 267 information field containing a URI for recipients to review 268 further information on a failure type. 270 Note that the failure types are non-exclusive; an aggregate report 271 may contain overlapping "counts" of failure types when a single send 272 attempt encountered multiple errors. 274 4.1. Report Time-frame 276 The report SHOULD cover a full day, from 0000-2400 UTC. This should 277 allow for easier correlation of failure events. 279 4.2. Delivery Summary 281 4.2.1. Success Count 283 o "success-count": This indicates that the sending MTA was able to 284 successfully negotiate a policy-compliant TLS connection, and 285 serves to provide a "heartbeat" to receiving domains that 286 reporting is functional and tabulating correctly. This field 287 contains an aggregate count of successful connections for the 288 reporting system. 290 4.2.2. Failure Count 292 o "failure-count": This indicates that the sending MTA was unable to 293 successfully establish a connection with the receiving platform. 294 The "Result Types" section will elaborate on the failed 295 negotiation attempts. This field contains an aggregate count of 296 failed connections. 298 4.3. Result Types 300 The list of result types will start with the minimal set below, and 301 is expected to grow over time based on real-world experience. The 302 initial set is: 304 4.3.1. Routing Failures 306 o "mx-mismatch": This indicates that the MX resolved for the 307 recipient domain did not match the MX constraint specified in the 308 policy. 310 4.3.2. Negotiation Failures 312 o "starttls-not-supported": This indicates that the recipient MX did 313 not support STARTTLS. 315 o "certificate-host-mismatch": This indicates that the certificate 316 presented did not adhere to the constraints specified in the STS 317 or DANE policy, e.g. if the CN field did not match the hostname 318 of the MX. 320 o "certificate-expired": This indicates that the certificate has 321 expired. 323 o "certificate-not-trusted": This a label that covers multiple 324 certificate related failures that include, but not limited to 325 errors such as untrusted/unknown CAs, certificate name contraints, 326 certificate chain errors etc. When using this declaration, the 327 reporting MTA SHOULD utilize the "failure-reason" to provide more 328 information to the receiving entity. 330 o "validation-failure": This indicates a general failure for a 331 reason not matching a category above. When using this 332 declaration, the reporting MTA SHOULD utilize the "failure-reason" 333 to provide more information to the receiving entity. 335 4.3.3. Policy Failures 337 4.3.3.1. DANE-specific Policy Failures 339 o "tlsa-invalid": This indicates a validation error in the TLSA 340 record associated with a DANE policy. 342 o "dnssec-invalid": This indicates a failure to authenticate DNS 343 records for a Policy Domain with a published TLSA record. 345 4.3.3.2. STS-specific Policy Failures 347 o "sts-invalid": This indicates a validation error for the overall 348 MTA-STS policy. 350 o "webpki-invalid": This indicates that the MTA-STS policy could not 351 be authenticated using PKIX validation. 353 4.3.4. General Failures 355 When a negotiation failure can not be categorized into one of the 356 "Negotiation Failures" stated above, the reporter SHOULD use the 357 "validation-failure" category. As TLS grows and becomes more 358 complex, new mechanisms may not be easily categorized. This allows 359 for a generic feedback category. When this category is used, the 360 reporter SHOULD also use the "failure-reason-code" to give some 361 feedback to the receiving entity. This is intended to be a short 362 text field, and the contents of the field should be an error code or 363 error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION". 365 4.3.5. Transient Failures 367 Transient errors due to too-busy network, TCP timeouts, etc. are not 368 required to be reported. 370 5. Report Delivery 372 Reports can be delivered either as an email message via SMTP or via 373 HTTP POST. 375 5.1. Report Filename 377 The filename is typically constructed using the following ABNF: 379 filename = sender "!" policy-domain "!" begin-timestamp 380 "!" end-timestamp [ "!" unique-id ] "." extension 382 unique-id = 1*(ALPHA / DIGIT) 384 sender = domain ; imported from [@!RFC5322] 386 policy-domain = domain 388 begin-timestamp = 1*DIGIT 389 ; seconds since 00:00:00 UTC January 1, 1970 390 ; indicating start of the time range contained 391 ; in the report 393 end-timestamp = 1*DIGIT 394 ; seconds since 00:00:00 UTC January 1, 1970 395 ; indicating end of the time range contained 396 ; in the report 398 extension = "json" / "json.gz" 400 The extension MUST be "json" for a plain JSON file, or "json.gz" for 401 a JSON file compressed using GZIP. 403 "unique-id" allows an optional unique ID generated by the Sending MTA 404 to distinguish among multiple reports generated simultaneously by 405 different sources within the same Policy Domain. For example, this 406 is a possible filename for the gzip file of a report to the Policy 407 Domain "example.net" from the Sending MTA "mail.sender.example.com": 409 `mail.sender.example.com!example.net!1470013207!1470186007!001.json.gz` 411 5.2. Compression 413 The report SHOULD be subjected to GZIP compression for both email and 414 HTTPS transport. Declining to apply compression can cause the report 415 to be too large for a receiver to process (a commonly observed 416 receiver limit is ten megabytes); compressing the file increases the 417 chances of acceptance of the report at some compute cost. 419 5.3. Email Transport 421 The report MAY be delivered by email. No specific MIME message 422 structure is required. It is presumed that the aggregate reporting 423 address will be equipped to extract MIME parts with the prescribed 424 media type and filename and ignore the rest. 426 If compressed, the report should use the media type "application/ 427 gzip" if compressed (see [RFC6713]), and "text/json" otherwise. 429 The [RFC5322].Subject field for individual report submissions SHOULD 430 conform to the following ABNF: 432 tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" 433 %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" 434 domain-name 1*FWS ; from RFC 6376 435 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" 436 1*FWS domain-name 1*FWS 437 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" 438 msg-id ; from RFC 5322 440 The first domain-name indicates the DNS domain name about which the 441 report was generated. The second domain-name indicates the DNS 442 domain name representing the Sending MTA generating the report. The 443 purpose of the Report-ID: portion of the field is to enable the 444 Policy Domain to identify and ignore duplicate reports that might be 445 sent by a Sending MTA. 447 For instance, this is a possible Subject field for a report to the 448 Policy Domain "example.net" from the Sending MTA 449 "mail.sender.example.com". It is line-wrapped as allowed by 450 [RFC5322]: 452 Subject: Report Domain: example.net 453 Submitter: mail.sender.example.com 454 Report-ID: <735ff.e317+bf22029@mailexample.net> 456 Note that, when sending failure reports via SMTP, sending MTAs MUST 457 NOT honor SMTP STS or DANE TLSA failures. 459 5.4. HTTPS Transport 461 The report MAY be delivered by POST to HTTPS. If compressed, the 462 report should use the media type "application/gzip" (see [RFC6713]), 463 and "text/json" otherwise. 465 5.5. Delivery Retry 467 In the event of a delivery failure, regardless of the delivery 468 method, a sender SHOULD attempt redelivery for up to 24hrs after the 469 initial attempt. As previously stated the reports are optional, so 470 while it is ideal to attempt redelivery, it is not required. If 471 multiple retries are attempted, they should be on a logarithmic 472 scale. 474 6. IANA Considerations 476 There are no IANA considerations at this time. 478 7. Security Considerations 480 SMTP TLS Reporting provides transparency into misconfigurations or 481 attempts to intercept or tamper with mail between hosts who support 482 STARTTLS. There are several security risks presented by the 483 existence of this reporting channel: 485 o Flooding of the Aggregate report URI (rua) endpoint: An attacker 486 could flood the endpoint and prevent the receiving domain from 487 accepting additional reports. This type of Denial-of-Service 488 attack would limit visibility into STARTTLS failures, leaving the 489 receiving domain blind to an ongoing attack. 491 o Untrusted content: An attacker could inject malicious code into 492 the report, opening a vulnerability in the receiving domain. 493 Implementers are advised to take precautions against evaluating 494 the contents of the report. 496 o Report snooping: An attacker could create a bogus TLSRPT record to 497 receive statistics about a domain the attacker does not own. 498 Since an attacker able to poison DNS is already able to receive 499 counts of SMTP connections (and, absent DANE or MTA-STS policies, 500 actual SMTP message payloads), this does not present a significant 501 new vulnerability. 503 o Reports as DDoS: TLSRPT allows specifying destinations for the 504 reports that are outside the authority of the Policy Domain, which 505 allows domains to delegate processing of reports to a partner 506 organization. However, an attacker who controls the Policy Domain 507 DNS could also use this mechanism to direct the reports to an 508 unwitting victim, flooding that victim with excessive reports. 509 DMARC [RFC7489] defines an elegant solution for verifying 510 delegation; however, since the attacker had less ability to 511 generate large reports than with DMARC failures, and since the 512 reports are generated by the sending MTA, such a delegation 513 mechanism is left for a future version of this specification. 515 8. Appendix 1: Example Reporting Policy 517 8.1. Report using MAILTO 519 smtp-tlsrpt.mail.example.com. IN TXT \ 520 "v=TLSRPTv1;rua=mailto:reports@example.com" 522 8.2. Report using HTTPS 524 smtp-tlsrpt.mail.example.com. IN TXT \ 525 "v=TLSRPTv1; \ 526 rua=https://reporting.example.com/v1/tlsrpt" 528 9. Appendix 2: JSON Report Schema 530 The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. 531 Section 3) 532 { 533 "organization-name": organization-name, 534 "date-range": { 535 "start-datetime": date-time, 536 "end-datetime": date-time 537 }, 538 "contact-info": email-address, 539 "report-id": report-id, 540 "policy": { 541 "policy-type": policy-type, 542 "policy-string": policy-string, 543 "policy-domain": domain, 544 "mx-host": mx-host-pattern 545 }, 546 "summary": { 547 "success-aggregate": total-successful-session-count, 548 "failure-aggregate:" total-failure-session-count 549 } 550 "failure-details": [ 551 { 552 "result-type": result-type, 553 "sending-mta-ip": ip-address, 554 "receiving-mx-hostname": receiving-mx-hostname, 555 "receiving-mx-helo": receiving-mx-helo, 556 "session-count": failed-session-count, 557 "additional-information": additional-info-uri, 558 "failure-reason-code": "Text body" 559 } 560 ] 561 } 563 Figure: JSON Report Format 565 o "organization-name": The name of the organization responsible for 566 the report. It is provided as a string. 568 o "date-time": The date-time indicates the start- and end-times for 569 the report range. It is provided as a string formatted according 570 to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The 571 report should be for a full UTC day, 0000-2400. 573 o "email-address": The contact information for a responsible party 574 of the report. It is provided as a string formatted according to 575 Section 3.4.1, "Addr-Spec", of [RFC5322]. 577 o "report-id": A unique identifier for the report. Report authors 578 may use whatever scheme they prefer to generate a unique 579 identifier. It is provided as a string. 581 o "policy-type": The type of policy that was applied by the sending 582 domain. Presently, the only three valid choices are "tlsa", 583 "sts", and the literal string "no-policy-found". It is provided 584 as a string. 586 o "policy-string": The string serialization of the policy, whether 587 TLSA record or STS policy. Any linefeeds from the original policy 588 MUST be replaced with [SP]. TODO: Help with specifics. 590 o "domain": The Policy Domain upon which the policy was applied. 591 For messages sent to "user@example.com" this field would contain 592 "example.com". It is provided as a string. 594 o "mx-host-pattern": The pattern of MX hostnames from the applied 595 policy. It is provided as a string, and is interpreted in the 596 same manner as the "Checking of Wildcard Certificates" rules in 597 Section 6.4.3 of [RFC6125]. 599 o "result-type": A value from the _Result Types_ section above. 601 o "ip-address": The IP address of the sending MTA that attempted the 602 STARTTLS connection. It is provided as a string representation of 603 an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal 604 notation. 606 o "receiving-mx-hostname": The hostname of the receiving MTA MX 607 record with which the sending MTA attempted to negotiate a 608 STARTTLS connection. 610 o "receiving-mx-helo": (optional) The HELO or EHLO string from the 611 banner announced during the reported session. 613 o "success-aggregate": The aggregate number (integer) of 614 successfully negotiated SSL-enabled connections to the receiving 615 site. 617 o "failure-aggregate": The aggregate number (integer) of failures to 618 negotiate an SSL-enabled connection to the receiving site. 620 o "session-count": The number of (attempted) sessions that match the 621 relevant "result-type" for this section. 623 o "additional-info-uri": An optional URI pointing to additional 624 information around the relevant "result-type". For example, this 625 URI might host the complete certificate chain presented during an 626 attempted STARTTLS session. 628 o "failure-reason-code": A text field to include an SSL-related 629 error code or error message. 631 10. Appendix 3: Example JSON Report 633 { 634 "organization-name": "Company-X", 635 "date-range": { 636 "start-datetime": "2016-04-01T00:00:00Z", 637 "end-datetime": "2016-04-01T23:59:59Z" 638 }, 639 "contact-info": "sts-reporting@company-x.com", 640 "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", 641 "policy": { 642 "policy-type": "sts", 643 "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\"*.mail.company-y.com\"], \"max_age\": 86400 }", 644 "policy-domain": "company-y.com", 645 "mx-host": "*.mail.company-y.com" 646 }, 647 "summary": { 648 "success-aggregate": 5326, 649 "failure-aggregate": 303 650 } 651 "failure-details": [{ 652 "result-type": "certificate-expired", 653 "sending-mta-ip": "98.136.216.25", 654 "receiving-mx-hostname": "mx1.mail.company-y.com", 655 "session-count": 100 656 }, { 657 "result-type": "starttls-not-supported", 658 "sending-mta-ip": "98.22.33.99", 659 "receiving-mx-hostname": "mx2.mail.company-y.com", 660 "session-count": 200, 661 "additional-information": "hxxps://reports.company-x.com/ 662 report_info?id=5065427c-23d3#StarttlsNotSupported" 663 }, { 664 "result-type: "validation-failure", 665 "sending-mta-ip": "47.97.15.2", 666 "receiving-mx-hostname: "mx-backup.mail.company-y.com", 667 "session-count": 3, 668 "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" 669 }] 670 } 672 Figure: Example JSON report for a messages from Company-X to 673 Company-Y, where 100 sessions were attempted to Company Y servers 674 with an expired certificate and 200 sessions were attempted to 675 Company Y servers that did not successfully respond to the "STARTTLS" 676 command. Additionally 3 sessions failed due to 677 "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". 679 11. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 683 RFC2119, March 1997, 684 . 686 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 687 RFC2818, May 2000, 688 . 690 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 691 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 692 February 2002, . 694 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 695 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 696 . 698 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 699 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 700 RFC5234, January 2008, 701 . 703 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 704 10.17487/RFC5322, October 2008, 705 . 707 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 708 Verification of Domain-Based Application Service Identity 709 within Internet Public Key Infrastructure Using X.509 710 (PKIX) Certificates in the Context of Transport Layer 711 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 712 2011, . 714 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 715 of Named Entities (DANE) Transport Layer Security (TLS) 716 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 717 2012, . 719 [RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' 720 Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, 721 . 723 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 724 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 725 2014, . 727 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 728 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 729 December 2014, . 731 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 732 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 733 2015, . 735 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 736 Message Authentication, Reporting, and Conformance 737 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 738 . 740 Authors' Addresses 742 Daniel Margolis 743 Google, Inc 745 Email: dmargolis (at) google.com 747 Alexander Brotman 748 Comcast, Inc 750 Email: alex_brotman (at) comcast.com 752 Binu Ramakrishnan 753 Yahoo!, Inc 755 Email: rbinu (at) yahoo-inc (dot com) 757 Janet Jones 758 Microsoft, Inc 760 Email: janet.jones (at) microsoft (dot com) 762 Mark Risher 763 Google, Inc 765 Email: risher (at) google (dot com)