draft-ietf-uta-smtp-tlsrpt-15.txt   draft-ietf-uta-smtp-tlsrpt-16.txt 
Using TLS in Applications D. Margolis Using TLS in Applications D. Margolis
Internet-Draft Google, Inc Internet-Draft Google, Inc
Intended status: Standards Track A. Brotman Intended status: Standards Track A. Brotman
Expires: August 23, 2018 Comcast, Inc Expires: September 5, 2018 Comcast, Inc
B. Ramakrishnan B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
M. Risher M. Risher
Google, Inc Google, Inc
February 19, 2018 March 4, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-15 draft-ietf-uta-smtp-tlsrpt-16
Abstract Abstract
A number of protocols exist for establishing encrypted channels A number of protocols exist for establishing encrypted channels
between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
MTA-STS. These protocols can fail due to misconfiguration or active MTA-STS. These protocols can fail due to misconfiguration or active
attack, leading to undelivered messages or delivery over unencrypted attack, leading to undelivered messages or delivery over unencrypted
or unauthenticated channels. This document describes a reporting or unauthenticated channels. This document describes a reporting
mechanism and format by which sending systems can share statistics mechanism and format by which sending systems can share statistics
and specific information about potential failures with recipient and specific information about potential failures with recipient
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 13 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 14 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 19
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 25
A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 24 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 25
A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 24 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 26
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 24 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to establish secure SMTP sessions over TLS. The protocol hosts to establish secure SMTP sessions over TLS. The protocol
design is based on "Opportunistic Security" (OS) [RFC7435], which design is based on "Opportunistic Security" (OS) [RFC7435], which
maintains interoperability with clients that do not support STARTTLS maintains interoperability with clients that do not support STARTTLS
but means that any attacker who can delete parts of the SMTP session but means that any attacker who can delete parts of the SMTP session
(such as the "250 STARTTLS" response) or redirect the entire SMTP (such as the "250 STARTTLS" response) or redirect the entire SMTP
session (perhaps by overwriting the resolved MX record of the session (perhaps by overwriting the resolved MX record of the
skipping to change at page 3, line 38 skipping to change at page 3, line 39
to report on failures at multiple stages of the MTA-to-MTA to report on failures at multiple stages of the MTA-to-MTA
conversation. conversation.
Recipient domains may also use the mechanisms defined by MTA-STS Recipient domains may also use the mechanisms defined by MTA-STS
[I-D.ietf-uta-mta-sts] or DANE [RFC6698] to publish additional [I-D.ietf-uta-mta-sts] or DANE [RFC6698] to publish additional
encryption and authentication requirements; this document defines a encryption and authentication requirements; this document defines a
mechanism for sending domains that are compatible with MTA-STS or mechanism for sending domains that are compatible with MTA-STS or
DANE to share success and failure statistics with recipient domains. DANE to share success and failure statistics with recipient domains.
Specifically, this document defines a reporting schema that covers Specifically, this document defines a reporting schema that covers
failures in routing, STARTTLS negotiation, and both DANE [RFC6698] failures in routing, DNS resolution, STARTTLS negotiation, and both
and MTA-STS [I-D.ietf-uta-mta-sts] policy validation errors, and a DANE [RFC6698] and MTA-STS [I-D.ietf-uta-mta-sts] policy validation
standard TXT record that recipient domains can use to indicate where errors, and a standard TXT record that recipient domains can use to
reports in this format should be sent. indicate where reports in this format should be sent.
This document is intended as a companion to the specification for This document is intended as a companion to the specification for
SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts]. SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts], as well as
adds reporting abilities for those implementing DANE [RFC7672].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We also define the following terms for further use in this document: We also define the following terms for further use in this document:
o MTA-STS Policy: A definition of the expected TLS availability, o MTA-STS Policy: A definition of the expected TLS availability,
behavior, and desired actions for a given domain when a sending behavior, and desired actions for a given domain when a sending
MTA encounters problems in negotiating a secure channel. MTA-STS MTA encounters problems in negotiating a secure channel. MTA-STS
is defined in [I-D.ietf-uta-mta-sts]. is defined in [I-D.ietf-uta-mta-sts].
o DANE Policy: A mechanism by which administrators can supply a o DANE Policy: A mechanism by which administrators can supply a
record that can be used to validate the certificate presented by record that can be used to validate the certificate presented by
an MTA. DANE is defined in [RFC6698]. an MTA. DANE is defined in [RFC6698] and [RFC7672].
o TLSRPT Policy: A policy specifying the endpoint to which sending o TLSRPT Policy: A policy specifying the endpoint to which sending
MTAs should deliver reports. MTAs should deliver reports.
o Policy Domain: The domain against which an MTA-STS or DANE Policy o Policy Domain: The domain against which an MTA-STS or DANE Policy
is defined. is defined.
o Sending MTA: The MTA initiating the delivery of an email message. o Sending MTA: The MTA initiating the relay of an email message.
2. Related Technologies 2. Related Technologies
o This document is intended as a companion to the specification for o This document is intended as a companion to the specification for
SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts]. SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts].
o SMTP-TLSRPT defines a mechanism for sending domains that are o SMTP-TLSRPT defines a mechanism for sending domains that are
compatible with MTA-STS or DANE to share success and failure compatible with MTA-STS or DANE to share success and failure
statistics with recipient domains. DANE is defined in [RFC6698] statistics with recipient domains. DANE is defined in [RFC6698]
and MTA-STS is defined in [I-D.ietf-uta-mta-sts]. and MTA-STS is defined in [I-D.ietf-uta-mta-sts].
skipping to change at page 7, line 11 skipping to change at page 7, line 41
* One of the following policy types: (1) The MTA-STS policy * One of the following policy types: (1) The MTA-STS policy
applied (as a string) (2) The DANE TLSA record applied (as a applied (as a string) (2) The DANE TLSA record applied (as a
string, with each RR entry of the RRset listed and separated by string, with each RR entry of the RRset listed and separated by
a semicolon) (3) The literal string "no-policy-found", if a semicolon) (3) The literal string "no-policy-found", if
neither a DANE nor MTA-STS policy could be found. neither a DANE nor MTA-STS policy could be found.
* The domain for which the policy is applied * The domain for which the policy is applied
* The MX host * The MX host
* An identifier for the policy (where applicable)
o Aggregate counts, comprising result type, sending MTA IP, o Aggregate counts, comprising result type, sending MTA IP,
receiving MTA hostname, session count, and an optional additional receiving MTA hostname, session count, and an optional additional
information field containing a URI for recipients to review information field containing a URI for recipients to review
further information on a failure type. further information on a failure type.
Note that the failure types are non-exclusive; an aggregate report Note that the failure types are non-exclusive; an aggregate report
may contain overlapping "counts" of failure types when a single send may contain overlapping "counts" of failure types when a single send
attempt encountered multiple errors. Reporters may report multiple attempt encountered multiple errors. Reporters may report multiple
applied policies (for example, an MTA-STS policy and a DANE TLSA applied policies (for example, an MTA-STS policy and a DANE TLSA
record for the same domain and MX); even in the case where only a record for the same domain and MX); even in the case where only a
skipping to change at page 8, line 18 skipping to change at page 8, line 44
is expected to grow over time based on real-world experience. The is expected to grow over time based on real-world experience. The
initial set is: initial set is:
4.3.1. Negotiation Failures 4.3.1. Negotiation Failures
o "starttls-not-supported": This indicates that the recipient MX did o "starttls-not-supported": This indicates that the recipient MX did
not support STARTTLS. not support STARTTLS.
o "certificate-host-mismatch": This indicates that the certificate o "certificate-host-mismatch": This indicates that the certificate
presented did not adhere to the constraints specified in the MTA- presented did not adhere to the constraints specified in the MTA-
STS or DANE policy, e.g. if the MX does not match any identities STS or DANE policy, e.g. if the MX hostname does not match any
listed in the Subject Alternate Name (SAN) [RFC5280]. identities listed in the Subject Alternate Name (SAN) [RFC5280].
o "certificate-expired": This indicates that the certificate has o "certificate-expired": This indicates that the certificate has
expired. expired.
o "certificate-not-trusted": This a label that covers multiple o "certificate-not-trusted": This a label that covers multiple
certificate related failures that include, but not limited to certificate related failures that include, but not limited to
errors such as untrusted/unknown CAs, certificate name errors such as untrusted/unknown CAs, certificate name
constraints, certificate chain errors etc. When using this constraints, certificate chain errors etc. When using this
declaration, the reporting MTA SHOULD utilize the "failure-reason" declaration, the reporting MTA SHOULD utilize the "failure-reason-
to provide more information to the receiving entity. code" to provide more information to the receiving entity.
o "validation-failure": This indicates a general failure for a o "validation-failure": This indicates a general failure for a
reason not matching a category above. When using this reason not matching a category above. When using this
declaration, the reporting MTA SHOULD utilize the "failure-reason" declaration, the reporting MTA SHOULD utilize the "failure-reason-
to provide more information to the receiving entity. code" to provide more information to the receiving entity.
4.3.2. Policy Failures 4.3.2. Policy Failures
4.3.2.1. DANE-specific Policy Failures 4.3.2.1. DANE-specific Policy Failures
o "tlsa-invalid": This indicates a validation error in the TLSA o "tlsa-invalid": This indicates a validation error in the TLSA
record associated with a DANE policy. None of the records in the record associated with a DANE policy. None of the records in the
RRset were found to be valid. RRset were found to be valid.
o "dnssec-invalid": This would indicate that no valid records were o "dnssec-invalid": This would indicate that no valid records were
skipping to change at page 11, line 19 skipping to change at page 12, line 19
o "report-id": A unique identifier for the report. Report authors o "report-id": A unique identifier for the report. Report authors
may use whatever scheme they prefer to generate a unique may use whatever scheme they prefer to generate a unique
identifier. It is provided as a string. identifier. It is provided as a string.
o "policy-type": The type of policy that was applied by the sending o "policy-type": The type of policy that was applied by the sending
domain. Presently, the only three valid choices are "tlsa", domain. Presently, the only three valid choices are "tlsa",
"sts", and the literal string "no-policy-found". It is provided "sts", and the literal string "no-policy-found". It is provided
as a string. as a string.
o "policy-string": A string representation of the policy, whether o "policy-string": A string representation of the policy, whether
TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples
follow in the next section.
For DANE TLSA policies, a JSON array array of strings each
representing the RDATA of a single TLSA resource record as a space-
separated list of its four TLSA fields (in RFC6698 Section 2.2)
presentation form with no internal spaces or grouping parentheses:
["3 0 1
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D",
3 0 1
12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"]
MTA-STS (array of JSON strings):
["version: STSv1","mode: report","mx: mx1.example.com","mx:
mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"]
o "domain": The Policy Domain is the domain against which the MTA- o "domain": The Policy Domain is the domain against which the MTA-
STS or DANE policy is defined. In the case of Internationalized STS or DANE policy is defined. In the case of Internationalized
Domain Names ([RFC5891]), the domain MUST consist of the Punycode- Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
encoded A-labels ([RFC3492]) and not the U-labels. encoded A-labels ([RFC3492]) and not the U-labels.
o "mx-host-pattern": The pattern of MX hostnames from the applied o "mx-host-pattern": The pattern of MX hostnames from the applied
policy. It is provided as a string, and is interpreted in the policy. It is provided as a string, and is interpreted in the
same manner as the "Checking of Wildcard Certificates" rules in same manner as the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125]. In the case of Internationalized Section 6.4.3 of [RFC6125]. In the case of Internationalized
skipping to change at page 12, line 43 skipping to change at page 13, line 29
presented during an attempted STARTTLS session. presented during an attempted STARTTLS session.
o "failure-reason-code": A text field to include a TLS-related error o "failure-reason-code": A text field to include a TLS-related error
code or error message. code or error message.
For report purposes, an IPv4 Address is defined as: IPv4address = For report purposes, an IPv4 Address is defined as: IPv4address =
dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ;
100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255
4.5. Policy Samples
Part of the report body includes the policy that is applied when
attemping relay to the destination.
For DANE TLSA policies, a JSON array of strings each representing the
RDATA of a single TLSA resource record as a space-separated list of
its four TLSA fields; the fields are in presentation format (defined
in RFC6698 Section 2.2) with no internal spaces or grouping
parentheses:
["3 0 1
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D",
3 0 1
12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"]
For the MTA-STS policy, an array of JSON string will represent the
policy that is declared by the receiving site, including any errors
that may be present. Note that if there are multiple MX records,
they are not included as an array.
["version: STSv1","mode: report","mx: mx1.example.com","mx:
mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"]
5. Report Delivery 5. Report Delivery
Reports can be delivered either as an email message via SMTP or via Reports can be delivered either as an email message via SMTP or via
HTTP POST. HTTP POST.
5.1. Report Filename 5.1. Report Filename
The filename is RECOMMENDED to be constructed using the following The filename is RECOMMENDED to be constructed using the following
ABNF: ABNF:
skipping to change at page 14, line 24 skipping to change at page 15, line 32
tlsrpt+gzip". tlsrpt+gzip".
In addition, the following two new top level message header fields In addition, the following two new top level message header fields
are defined: are defined:
"TLS-Report-Domain: Receiver-Domain" "TLS-Report-Domain: Receiver-Domain"
"TLS-Report-Submitter: Sender-Domain" "TLS-Report-Submitter: Sender-Domain"
The "TLS-Report-Submitter" value MUST match the value found in the The "TLS-Report-Submitter" value MUST match the value found in the
filename and the [RFC5321] domain from the "contact-info" from the [RFC5321] domain from the "contact-info" from the report body. These
report body. These message headers MUST be included and should allow message headers MUST be included and should allow for easy searching
for easy searching for all reports submitted by a report domain or a for all reports submitted by a report domain or a particular
particular submitter, for example in IMAP [RFC3501]: submitter, for example in IMAP [RFC3501]:
"s SEARCH HEADER "TLS-Report-Domain" "example.com"" "s SEARCH HEADER "TLS-Report-Domain" "example.com""
It is presumed that the aggregate reporting address will be equipped It is presumed that the aggregate reporting address will be equipped
to process new message header fields and extract MIME parts with the to process new message header fields and extract MIME parts with the
prescribed media type and filename, and ignore the rest. These prescribed media type and filename, and ignore the rest. These
additional headers SHOULD be included in the DKIM [RFC6376] signature additional headers SHOULD be included in the DKIM [RFC6376] signature
for the message. for the message.
The [RFC5322].Subject field for report submissions SHOULD conform to The [RFC5322].Subject field for report submissions SHOULD conform to
skipping to change at page 19, line 48 skipping to change at page 21, line 38
Types". The initial entries in the registry are: Types". The initial entries in the registry are:
+-------------------------------+ +-------------------------------+
| Result Type | | Result Type |
+-------------------------------+ +-------------------------------+
| "starttls-not-supported" | | "starttls-not-supported" |
| "certificate-host-mismatch" | | "certificate-host-mismatch" |
| "certificate-expired" | | "certificate-expired" |
| "tlsa-invalid" | | "tlsa-invalid" |
| "dnssec-invalid" | | "dnssec-invalid" |
| "dane-required" |
| "certificate-not-trusted" |
| "sts-policy-invalid" | | "sts-policy-invalid" |
| "sts-webpki-invalid" | | "sts-webpki-invalid" |
| "validation-failure" | | "validation-failure" |
+-------------------------------+ +-------------------------------+
The above entries are described in section Section 4.3, "Result The above entries are described in section Section 4.3, "Result
Types." New result types can be added to this registry using "Expert Types." New result types can be added to this registry using "Expert
Review" IANA registration policy. Review" IANA registration policy.
7. Security Considerations 7. Security Considerations
skipping to change at page 23, line 23 skipping to change at page 25, line 13
editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, <https://www.rfc- DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
editor.org/info/rfc7493>. editor.org/info/rfc7493>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
editor.org/info/rfc7672>.
8.2. Informative References 8.2. Informative References
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>. February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
skipping to change at page 24, line 5 skipping to change at page 25, line 47
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
editor.org/info/rfc7672>.
Appendix A. Example Reporting Policy Appendix A. Example Reporting Policy
A.1. Report using MAILTO A.1. Report using MAILTO
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
A.2. Report using HTTPS A.2. Report using HTTPS
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
skipping to change at page 25, line 4 skipping to change at page 26, line 16
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
A.2. Report using HTTPS A.2. Report using HTTPS
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
Appendix B. Example JSON Report Appendix B. Example JSON Report
Below is an example JSON report for messages from Company-X to
Company-Y, where 100 sessions were attempted to Company Y servers
with an expired certificate and 200 sessions were attempted to
Company Y servers that did not successfully respond to the "STARTTLS"
command. Additionally 3 sessions failed due to
"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
{ {
"organization-name": "Company-X", "organization-name": "Company-X",
"date-range": { "date-range": {
"start-datetime": "2016-04-01T00:00:00Z", "start-datetime": "2016-04-01T00:00:00Z",
"end-datetime": "2016-04-01T23:59:59Z" "end-datetime": "2016-04-01T23:59:59Z"
}, },
"contact-info": "sts-reporting@company-x.example", "contact-info": "sts-reporting@company-x.example",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policies": [{ "policies": [{
"policy": { "policy": {
skipping to change at page 25, line 48 skipping to change at page 28, line 5
"result-type": "validation-failure", "result-type": "validation-failure",
"sending-mta-ip": "47.97.15.2", "sending-mta-ip": "47.97.15.2",
"receiving-ip": "10.72.84.12", "receiving-ip": "10.72.84.12",
"receiving-mx-hostname": "mx-backup.mail.company-y.example", "receiving-mx-hostname": "mx-backup.mail.company-y.example",
"failed-session-count": 3, "failed-session-count": 3,
"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
}] }]
}] }]
} }
Figure: Example JSON report for a messages from Company-X to Company-
Y, where 100 sessions were attempted to Company Y servers with an
expired certificate and 200 sessions were attempted to Company Y
servers that did not successfully respond to the "STARTTLS" command.
Additionally 3 sessions failed due to
"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis@google.com Email: dmargolis@google.com
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
 End of changes. 25 change blocks. 
86 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/