Using TLS in Applications D. Margolis
Internet-Draft Google, Inc
Intended status: Standards Track A. Brotman
Expires: January 9, 2017 Comcast, Inc
B. Ramakrishnan
Yahoo!, Inc
J. Jones
Microsoft, Inc
M. Risher
Google, Inc
July 8, 2016

SMTP TLS Reporting


A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 9, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design is based on "Opportunistic Security" (OS) [RFC7435], which provides interoperability for clients that do not support STARTTLS but means that any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform a downgrade or interception attack.

Because such "downgrade attacks" are not necessarily apparent to the receiving MTA, this document defines a mechanism for sending domains to report on failures at multiple parts of the MTA-to-MTA conversation.

Recipient domains may also use the mechanisms defined by MTA-STS (TODO: Add ref) or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains.

Specifically, this document defines a reporting schema that covers failures in routing, STARTTLS negotiation, and both DANE [RFC6698] and MTA-STS (TODO: Add ref) policy validation errors, and standard TXT record that recipient domains can use to indicate where reports in this format should be sent.

This document is intended as a companion to the specification for SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).

1.1. Terminology

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

We also define the following terms for further use in this document:

2. Related Technologies

3. Reporting Policy

SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone, as TXT records (similar to DMARC policies) under the name _smtp_tlsrpt. For example, for the Policy Domain, the recipient's SMTP STS policy can be retrieved from

(Future implementations may move to alternate methods of policy discovery or distribution. See the section Future Work for more discussion.)

Policies consist of the following directives:

 * In the case of `https`, reports should be submitted via POST
   ([@!RFC2818]) to the specified URI.
 * In the case of `mailto`, reports should be submitted to the specified
   email address. When sending failure reports via SMTP, sending MTAs
   MUST NOT honor SMTP STS or DANE TLSA failures.

The formal definition of the _mta_sts TXT record, defined using [RFC5234], is as follows:

sts-text-record = sts-version *WSP %x3B *WSP sts-id

sts-version     = "v" *WSP "=" *WSP %x54 %x4C %x53 
                  %x52 %x50 %x54 %x76 %x31

sts-id          = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)

3.1. Example Reporting Policy

3.1.1. Report using MAILTO IN TXT \

3.1.2. Report using HTTPS IN TXT \
	"v=TLSRPTv1; \

4. Reporting Schema

Aggregate reports contain the following fields:

  MTA-STS policy could be found.

Note that the failure types are non-exclusive; an aggregate report MAY contain overlapping counts of failure types where a single send attempt encountered multiple errors.

4.1. Result Types

The list of result types will start with the minimal set below, and is expected to grow over time based on real-world experience. The initial set is:

4.1.1. Success Type

4.1.2. Routing Failures

4.1.3. Negotiation Failures

4.1.4. Policy Failures DANE-specific Policy Failures STS-specific Policy Failures

5. Report Delivery

Note that, when sending failure reports via SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA failures.

6. IANA Considerations

There are no IANA considerations at this time.

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:

8. Appendix 1: JSON Report Schema

The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. Section 3)

  "organization-name": organization-name,
  "date-range": {
    "start-datetime": date-time,
    "end-datetime": date-time
  "contact-info": email-address,
  "report-id": report-id,
  "policy": {
    "policy-type": policy-type,
    "policy-string": policy-string,
    "policy-domain": domain,
    "mx-host": mx-host-pattern
  "report-items": [
      "result-type": result-type,
      "sending-mta-ip": ip-address,
      "receiving-mx-hostname": receiving-mx-hostname,
      "message-count": message-count,
      "additional-information": additional-info-uri

JSON Report Format

9. Appendix 2: Example JSON Report

	"organization-name": "Company-X",
	"date-range": {
		"start-datetime": "2016-04-01T00:00:00Z",
		"end-datetime": "2016-04-01T23:59:59Z"
	"contact-info": "",
	"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
	"policy": {
		"policy-type": "sts",
		"policy-string": "TODO: Add me",
		"policy-domain": "",
		"mx-host": "*"
	"report-items": [{
		"result-type": "ExpiredCertificate",
		"sending-mta-ip": "",
		"receiving-mx-hostname": "",
		"message-count": 100
	}, {
		"result-type": "StarttlsNotSupported",
		"sending-mta-ip": "",
		"receiving-mx-hostname": "",
		"message-count": 200,
		"additional-information": "hxxps://

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

10. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008.
[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.
[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.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014.
[RFC7469] Evans, C., Palmer, C. and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015.
[RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015.

Authors' Addresses

Daniel Margolis Google, Inc EMail: dmargolis (at)
Alexander Brotman Comcast, Inc EMail: alexander_brotman (at) (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)