Skip to main content

SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-12

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8460.
Authors Daniel Margolis , Alex Brotman , Binu Ramakrishnan , Janet Jones , Mark Risher
Last updated 2017-12-04
Replaces draft-brotman-smtp-tlsrpt
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Leif Johansson
IESG IESG state Became RFC 8460 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to Leif Johansson <leifj@sunet.se>
draft-ietf-uta-smtp-tlsrpt-12
quot; response from the
   accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
   Other codes could indicate a delivery failure, and may be retried as
   per local policy.  The receiving system is not expected to process
   reports at receipt time, and MAY store them for processing at a later
   time.

5.5.  Delivery Retry

   In the event of a delivery failure, regardless of the delivery
   method, a sender SHOULD attempt redelivery for up to 24hrs after the
   initial attempt.  As previously stated the reports are optional, so
   while it is ideal to attempt redelivery, it is not required.  If
   multiple retries are attempted, ideally they would be on a
   logarithmic scale.

5.6.  Metadata Variances

   As stated above, there are a variable number of ways to declare
   information about the data therein.  If it should be the case that
   these objects were to disagree, then the report data contained within
   the JSON body MUST be considered the authoritative source for those
   data elements.

6.  IANA Considerations

   The following are the IANA considerations discussed in this document.

6.1.  Message headers

   Below is the Internet Assigned Numbers Authority (IANA) Permanent
   Message Header Field registration information per [RFC3864].

             Header field name:           TLS-Report-Domain
             Applicable protocol:         mail
             Status:                      standard
             Author/Change controller:    IETF
             Specification document(s):   this one

             Header field name:           TLS-Report-Submitter
             Applicable protocol:         mail
             Status:                      standard
             Author/Change controller:    IETF
             Specification document(s):   this one

Margolis, et al.          Expires June 7, 2018                 [Page 16]
Internet-Draft                 SMTP-TLSRPT                 December 2017

6.2.  Report Type

   This document registers a new parameter "report-type="tlsrpt"" under
   "multipart/report" top-level media type for use with [RFC6522].

   The media type suitable for use as a report-type is defined in the
   following section.

6.3.  application/tlsrpt+json Media Type

   This document registers multiple media types, beginning with Table 1
   below.

    +-------------+----------------+-------------+-------------------+
    | Type        | Subtype        | File extn   | Specification     |
    +-------------+----------------+-------------+-------------------+
    | application | tlsrpt+json    |  .json      | Section 5.3       |
    +-------------+----------------+-------------+-------------------+
                    Table 1: SMTP TLS Reporting Media Type

   Type name: application

   Subtype name: tlsrpt+json

   Required parameters: n/a

   Optional parameters: n/a

   Encoding considerations: Encoding considerations are identical to
   those specified for the "application/json" media type.  See
   [RFC7493].

   Security considerations: Security considerations relating to SMTP TLS
   Reporting are discussed in Section 7.

   Interoperability considerations: This document specifies format of
   conforming messages and the interpretation thereof.

   Published specification: Section 5.3 of this document.

   Applications that use this media type: Mail User Agents (MUA) and
   Mail Transfer Agents.

   Additional information:

Margolis, et al.          Expires June 7, 2018                 [Page 17]
Internet-Draft                 SMTP-TLSRPT                 December 2017

                      Magic number(s):  n/a

                      File extension(s):  ".json"

                      Macintosh file type code(s):  n/a

   Person & email address to contact for further information: See
   Authors' Addresses section.

   Intended usage: COMMON

   Restrictions on usage: n/a

   Author: See Authors' Addresses section.

   Change controller: Internet Engineering Task Force
   (mailto:iesg@ietf.org).

6.4.  application/tlsrpt+gzip Media Type

    +-------------+----------------+-------------+-------------------+
    | Type        | Subtype        | File extn   | Specification     |
    +-------------+----------------+-------------+-------------------+
    | application | tlsrpt+gzip    |  .gz        | Section 5.3       |
    +-------------+----------------+-------------+-------------------+
                    Table 2: SMTP TLS Reporting Media Type

   Type name: application

   Subtype name: tlsrpt+gzip

   Required parameters: n/a

   Optional parameters: n/a

   Encoding considerations: Binary

   Security considerations: Security considerations relating to SMTP TLS
   Reporting are discussed in Section 7.

   Interoperability considerations: This document specifies format of
   conforming messages and the interpretation thereof.

   Published specification: Section 5.3 of this document.

   Applications that use this media type: Mail User Agents (MUA) and
   Mail Transfer Agents.

Margolis, et al.          Expires June 7, 2018                 [Page 18]
Internet-Draft                 SMTP-TLSRPT                 December 2017

   Additional information:

                      Magic number(s):  n/a

                      File extension(s):  ".gz"

                      Macintosh file type code(s):  n/a

   Person & email address to contact for further information: See
   Authors' Addresses section.

   Intended usage: COMMON

   Restrictions on usage: n/a

   Author: See Authors' Addresses section.

   Change controller: Internet Engineering Task Force
   (mailto:iesg@ietf.org).

6.5.  STARTTLS Validation Result Types

   This document creates a new registry, "STARTTLS Validation Result
   Types".  The initial entries in the registry are:

                     +-------------------------------+
                     | Result Type                   |
                     +-------------------------------+
                     | "starttls-not-supported"      |
                     | "certificate-host-mismatch"   |
                     | "certificate-expired"         |
                     | "tlsa-invalid"                |
                     | "dnssec-invalid"              |
                     | "sts-policy-invalid"          |
                     | "sts-webpki-invalid"          |
                     | "validation-failure"          |
                     +-------------------------------+

   The above entries are described in section Section 4.3, "Result
   Types."  New result types can be added to this registry using "Expert
   Review" IANA registration policy.

7.  Security Considerations

   SMTP TLS Reporting provides transparency into misconfigurations or
   attempts to intercept or tamper with mail between hosts who support
   STARTTLS.  There are several security risks presented by the
   existence of this reporting channel:

Margolis, et al.          Expires June 7, 2018                 [Page 19]
Internet-Draft                 SMTP-TLSRPT                 December 2017

   o  Flooding of the Aggregate report URI (rua) endpoint: An attacker
      could flood the endpoint with excessive reporting traffic and
      prevent the receiving domain from accepting additional reports.
      This type of Denial-of-Service attack would limit visibility into
      STARTTLS failures, leaving the receiving domain blind to an
      ongoing attack.

   o  Untrusted content: An attacker could inject malicious code into
      the report, opening a vulnerability in the receiving domain.
      Implementers are advised to take precautions against evaluating
      the contents of the report.

   o  Report snooping: An attacker could create a bogus TLSRPT record to
      receive statistics about a domain the attacker does not own.
      Since an attacker able to poison DNS is already able to receive
      counts of SMTP connections (and, absent DANE or MTA-STS policies,
      actual SMTP message payloads), this does not present a significant
      new vulnerability.

   o  Reports as DDoS: TLSRPT allows specifying destinations for the
      reports that are outside the authority of the Policy Domain, which
      allows domains to delegate processing of reports to a partner
      organization.  However, an attacker who controls the Policy Domain
      DNS could also use this mechanism to direct the reports to an
      unwitting victim, flooding that victim with excessive reports.
      DMARC [RFC7489] defines a solution for verifying delegation to
      avoid such attacks; the need for this is greater with DMARC,
      however, because DMARC allows an attacker to trigger reports to a
      target from an innocent third party by sending that third party
      mail (which triggers a report from the third party to the target).
      In the case of TLSRPT, the attacker would have to induce the third
      party to send the attacker mail in order to trigger reports from
      the third party to the victim; this reduces the risk of such an
      attack and the need for a verification mechanism.

   Finally, because TLSRPT is intended to help administrators discover
   man-in-the-middle attacks against transport-layer encryption,
   including attacks designed to thwart negotiation of encrypted
   connections (by downgrading opportunistic encryption or, in the case
   of MTA-STS, preventing discovery of a new MTA-STS policy), we must
   also consider the risk that an adversary who can induce such a
   downgrade attack can also prevent discovery of the TLSRPT TXT record
   (and thus prevent discovery of the successful downgrade attack).
   Administrators are thus encouraged to deploy TLSRPT TXT records with
   a large TTL (reducing the window for successful attacks against DNS
   resolution of the record) or to deploy DNSSEC on the deploying zone.

Margolis, et al.          Expires June 7, 2018                 [Page 20]
Internet-Draft                 SMTP-TLSRPT                 December 2017

8.  References

8.1.  Normative References

   [I-D.ietf-uta-mta-sts]
              Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
              and J. Jones, "SMTP MTA Strict Transport Security (MTA-
              STS)", draft-ietf-uta-mta-sts-11 (work in progress),
              November 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
              <https://www.rfc-editor.org/info/rfc3492>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

Margolis, et al.          Expires June 7, 2018                 [Page 21]
Internet-Draft                 SMTP-TLSRPT                 December 2017

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <https://www.rfc-editor.org/info/rfc5952>.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/info/rfc6068>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC6522]  Kucherawy, M., Ed., "The Multipart/Report Media Type for
              the Reporting of Mail System Administrative Messages",
              STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
              <https://www.rfc-editor.org/info/rfc6522>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
              RFC 7405, DOI 10.17487/RFC7405, December 2014,
              <https://www.rfc-editor.org/info/rfc7405>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

Margolis, et al.          Expires June 7, 2018                 [Page 22]
Internet-Draft                 SMTP-TLSRPT                 December 2017

8.2.  Informative References

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <https://www.rfc-editor.org/info/rfc3207>.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
              <https://www.rfc-editor.org/info/rfc3864>.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <https://www.rfc-editor.org/info/rfc7435>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <https://www.rfc-editor.org/info/rfc7469>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

Appendix A.  Example Reporting Policy

A.1.  Report using MAILTO

            _smtp-tlsrpt.mail.example.com. IN TXT \
                    "v=TLSRPTv1;rua=mailto:reports@example.com"

A.2.  Report using HTTPS

           _smtp-tlsrpt.mail.example.com. IN TXT \
                   "v=TLSRPTv1; \
                   rua=https://reporting.example.com/v1/tlsrpt"

Appendix B.  Example JSON Report

Margolis, et al.          Expires June 7, 2018                 [Page 23]
Internet-Draft                 SMTP-TLSRPT                 December 2017

   {
     "organization-name": "Company-X",
     "date-range": {
       "start-datetime": "2016-04-01T00:00:00Z",
       "end-datetime": "2016-04-01T23:59:59Z"
     },
     "contact-info": "sts-reporting@company-x.example",
     "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
     "policies": [{
       "policy": {
         "policy-type": "sts",
         "policy-string": "version: STSv1\r\nmode: report\r\n
                   mx: .mail.company-y.example\r\nmax_age: 86400",
         "policy-domain": "company-y.example",
         "mx-host": ".mail.company-y.example"
       },
       "summary": {
         "total-successful-session-count": 5326,
         "total-failure-session-count": 303
       },
       "failure-details": [{
         "result-type": "certificate-expired",
         "sending-mta-ip": "98.136.216.25",
         "receiving-mx-hostname": "mx1.mail.company-y.example",
         "failed-session-count": 100
       }, {
         "result-type": "starttls-not-supported",
         "sending-mta-ip": "98.22.33.99",
         "receiving-mx-hostname": "mx2.mail.company-y.example",
         "failed-session-count": 200,
         "additional-information": "https://reports.company-x.example/
           report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
       }, {
         "result-type": "validation-failure",
         "sending-mta-ip": "47.97.15.2",
         "receiving-mx-hostname": "mx-backup.mail.company-y.example",
         "failed-session-count": 3,
         "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
       }]
     }]
   }

   Figure: Example JSON report for a messages from Company-X to Company-
   Y, where 100 sessions were attempted to Company Y servers with an
   expired certificate and 200 sessions were attempted to Company Y
   servers that did not successfully respond to the "STARTTLS" command.

Margolis, et al.          Expires June 7, 2018                 [Page 24]
Internet-Draft                 SMTP-TLSRPT                 December 2017

   Additionally 3 sessions failed due to
   "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".

Authors' Addresses

   Daniel Margolis
   Google, Inc

   Email: dmargolis (at) google (dot com)

   Alexander Brotman
   Comcast, Inc

   Email: alex_brotman (at) comcast (dot com)

   Binu Ramakrishnan
   Yahoo!, Inc

   Email: rbinu (at) yahoo-inc (dot com)

   Janet Jones
   Microsoft, Inc

   Email: janet.jones (at) microsoft (dot com)

   Mark Risher
   Google, Inc

   Email: risher (at) google (dot com)

Margolis, et al.          Expires June 7, 2018                 [Page 25]