draft-ietf-uta-smtp-tlsrpt-18.txt   draft-ietf-uta-smtp-tlsrpt-19.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: October 6, 2018 Comcast, Inc Expires: November 3, 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
April 4, 2018 May 2, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-18 draft-ietf-uta-smtp-tlsrpt-19
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
domains. Recipient domains can then use this information to both domains. Recipient domains can then use this information to both
detect potential attackers and diagnose unintentional detect potential attacks and diagnose unintentional
misconfigurations. misconfigurations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 6, 2018. This Internet-Draft will expire on November 3, 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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 19 6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 19
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 20 6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 20
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 21 6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 21
6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 25 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 27
A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 26 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 27
A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 26 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 27
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 26 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 uses an approach that has come to be known as "Opportunistic design uses an approach that has come to be known as "Opportunistic
Security" (OS) [RFC7435], which maintains interoperability with Security" (OS) [RFC7435]. This method maintains interoperability
clients that do not support STARTTLS but means that any attacker who with clients that do not support STARTTLS, but means that any
can delete parts of the SMTP session (such as the "250 STARTTLS" attacker could potentially eavesdrop on a session. An attacker could
response) or redirect the entire SMTP session (perhaps by overwriting perform a downgrade or interception attack by deleting parts of the
the resolved MX record of the delivery domain) can perform a SMTP session (such as the "250 STARTTLS" response) or redirect the
downgrade or interception attack. entire SMTP session (perhaps by overwriting the resolved MX record of
the delivery domain).
Because such "downgrade attacks" are not necessarily apparent to the Because such "downgrade attacks" are not necessarily apparent to the
receiving MTA, this document defines a mechanism for sending domains receiving MTA, this document defines a mechanism for sending domains
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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
also serve as a heartbeat that systems are successfully negotiating also serve as a heartbeat that systems are successfully negotiating
TLS during sessions as expected. TLS during sessions as expected.
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], as well as SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts], as well as
adds reporting abilities for those implementing DANE [RFC7672]. 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 mechanism by which administrators can specify
behavior, and desired actions for a given domain when a sending the expected TLS availability, presented identity, and desired
MTA encounters problems in negotiating a secure channel. MTA-STS actions for a given email recipient domain. MTA-STS is defined in
is defined in [I-D.ietf-uta-mta-sts]. [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 specify
record that can be used to validate the certificate presented by constraints to be used to validate certificates presented by an
an MTA. DANE is defined in [RFC6698] and [RFC7672]. 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. This should be the same as the recipient envelope
domain [RFC5321], such as if the message were going to
"alice@example.com', the policy domain would be "example.com".
o Sending MTA: The MTA initiating the relay of an email message. o Sending MTA: The MTA initiating the relay of an email message.
o Aggregate Report URI (rua): A comma-separated list of locations
where the report is to be submitted.
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 4, line 51 skipping to change at page 5, line 9
A domain publishes a record to its DNS indicating that it wishes to A domain publishes a record to its DNS indicating that it wishes to
receive reports. These SMTP TLSRPT policies are distributed via DNS receive reports. These SMTP TLSRPT policies are distributed via DNS
from the Policy Domain's zone, as TXT records (similar to DMARC from the Policy Domain's zone, as TXT records (similar to DMARC
policies) under the name "_smtp._tls". For example, for the Policy policies) under the name "_smtp._tls". For example, for the Policy
Domain "example.com", the recipient's TLSRPT policy can be retrieved Domain "example.com", the recipient's TLSRPT policy can be retrieved
from "_smtp._tls.example.com". from "_smtp._tls.example.com".
Policies consist of the following directives: Policies consist of the following directives:
o "v": This value MUST be equal to "TLSRPTv1". o "v": This document defines version 1 of TLSRPT, for which this
value MUST be equal to "TLSRPTv1". Other versions may be defined
in later documents.
o "rua": A URI specifying the endpoint to which aggregate o "rua": A URI specifying the endpoint to which aggregate
information about policy validation results should be sent (see information about policy validation results should be sent (see
Section 4, "Reporting Schema", for more information). Two URI Section 4, "Reporting Schema", for more information). Two URI
schemes are supported: "mailto" and "https". As with DMARC schemes are supported: "mailto" and "https". As with DMARC
[RFC7489], the policy domain can specify a comma-separated list of [RFC7489], the policy domain can specify a comma-separated list of
URIs. URIs.
o In the case of "https", reports should be submitted via POST o In the case of "https", reports should be submitted via POST
([RFC7231]) to the specified URI. Report submitters MAY ignore ([RFC7231]) to the specified URI. Report submitters MAY ignore
certificate validation errors when submitting reports via https. certificate validation errors when submitting reports via https.
o In the case of "mailto", reports should be submitted to the o In the case of "mailto", reports should be submitted to the
specified email address ([RFC6068]). When sending failure reports specified email address ([RFC6068]). When sending failure reports
via SMTP, sending MTAs MUST deliver reports despite any TLS- via SMTP, sending MTAs MUST deliver reports despite any TLS-
related failures and SHOULD NOT include this SMTP session in the related failures and SHOULD NOT include this SMTP session in the
next report. This may mean that the reports are delivered in the next report. When sending failure reports via HTTPS, sending MTAs
clear. Additionally, reports sent via SMTP MUST contain a valid MAY deliver reports despite any TLS-related faliures. This may
DKIM [RFC6376] signature by the reporting domain. Reports lacking mean that the reports are delivered in the clear. Reports sent
such a signature MUST be ignored by the recipient. DKIM via SMTP MUST contain a valid DKIM [RFC6376] signature by the
signatures must not use the "l=" attribute to limit the body reporting domain. Reports lacking such a signature MUST be
length used in the signature. ignored by the recipient. DKIM signatures must not use the "l="
attribute to limit the body length used in the signature. The
DKIM TXT record must contain the appropriate service type
declaration, "s=tlsrpt", and if not present the receiving system
SHOULD ignore reports signed using this record.
The formal definition of the "_smtp._tls" TXT record, defined using The formal definition of the "_smtp._tls" TXT record, defined using
[RFC5234] & [RFC7405], is as follows: [RFC5234] & [RFC7405], is as follows:
tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
[field-delim] [field-delim]
field-delim = *WSP ";" *WSP field-delim = *WSP ";" *WSP
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-field = tlsrpt-rua / ; Note that the
skipping to change at page 6, line 38 skipping to change at page 6, line 38
DIGIT / "_" / "-" / ".") DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control ; chars excluding "=", ";", SP, and control
; chars ; chars
If multiple TXT records for "_smtp._tls" are returned by the If multiple TXT records for "_smtp._tls" are returned by the
resolver, records which do not begin with "v=TLSRPTv1;" are resolver, records which do not begin with "v=TLSRPTv1;" are
discarded. If the number of resulting records is not one, senders discarded. If the number of resulting records is not one, senders
MUST assume the recipient domain does not implement TLSRPT. If the MUST assume the recipient domain does not implement TLSRPT. If the
resulting TXT record contains multiple strings, then the record MUST resulting TXT record contains multiple strings (as described in
be treated as if those strings are concatenated together without Section 3.1.3 of [RFC4408]), then the record MUST be treated as if
adding spaces. those strings are concatenated together without adding spaces.
The record supports the abillity to declare more than one rua, and if The record supports the abillity to declare more than one rua, and if
there exists more than one, the reporter MAY attempt to deliver to there exists more than one, the reporter MAY attempt to deliver to
each of the supported rua destinations. A receiver MAY opt to only each of the supported rua destinations. A receiver MAY opt to only
attempt delivery to one of the endpoints, however the report SHOULD attempt delivery to one of the endpoints, however the report SHOULD
NOT be considered successfully delivered until one of the endpoints NOT be considered successfully delivered until one of the endpoints
accepts delivery of the report. If the reporter does not support one accepts delivery of the report.
of the report mechanisms, then it SHOULD NOT attempt delivery to
those rua destinations.
Parsers MUST accept TXT records which are syntactically valid (i.e. Parsers MUST accept TXT records which are syntactically valid (i.e.
valid key-value pairs separated by semi-colons) and implementing a valid key-value pairs separated by semi-colons) and implementing a
superset of this specification, in which case unknown fields SHALL be superset of this specification, in which case unknown fields SHALL be
ignored. ignored.
3.1. Example Reporting Policy 3.1. Example Reporting Policy
3.1.1. Report using MAILTO 3.1.1. Report using MAILTO
skipping to change at page 8, line 11 skipping to change at page 8, line 9
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). Because of this, even in the
single policy was applied, the "policies" field of the report body case where only a single policy was applied, the "policies" field of
MUST be an array and not a singular value. the report body MUST be an array and not a singular value.
In the case of multiple failure types, the "failure-details" array In the case of multiple failure types, the "failure-details" array
would contain multiple entries. Each entry would have its own set of would contain multiple entries. Each entry would have its own set of
infomation pertaining to that failure type. infomation pertaining to that failure type.
4.1. Report Time-frame 4.1. Report Time-frame
The report SHOULD cover a full day, from 0000-2400 UTC. This should The report SHOULD cover a full day, from 0000-2400 UTC. This should
allow for easier correlation of failure events. To avoid a Denial of allow for easier correlation of failure events. To avoid a Denial of
Service against the system processing the reports, the reports should Service against the system processing the reports, the reports should
skipping to change at page 13, line 5 skipping to change at page 13, line 5
STARTTLS connection. STARTTLS connection.
o "receiving-mx-helo": (optional) The HELO or EHLO string from the o "receiving-mx-helo": (optional) The HELO or EHLO string from the
banner announced during the reported session. banner announced during the reported session.
o "receiving-ip": The destination IP address that was using when o "receiving-ip": The destination IP address that was using when
creating the outbound session. It is provided as a string creating the outbound session. It is provided as a string
representation of an IPv4 (see below) or IPv6 ([RFC5952]) address representation of an IPv4 (see below) or IPv6 ([RFC5952]) address
in dot-decimal or colon-hexadecimal notation. in dot-decimal or colon-hexadecimal notation.
o "total-successful-session-count": The aggregate number (integer) o "total-successful-session-count": The aggregate count (integer,
of successfully negotiated TLS-enabled connections to the encoded as a JSON number) of successfully negotiated TLS-enabled
receiving site. connections to the receiving site.
o "total-failure-session-count": The aggregate number (integer) of o "total-failure-session-count": The aggregate count (integer,
failures to negotiate a TLS-enabled connection to the receiving encoded as a JSON number) of failures to negotiate a TLS-enabled
site. connection to the receiving site.
o "failed-session-count": The number of (attempted) sessions that o "failed-session-count": The number of (attempted) sessions that
match the relevant "result-type" for this section. match the relevant "result-type" for this section (integer,
encoded as a JSON number).
o "additional-info-uri": An optional URI [RFC3986] pointing to o "additional-info-uri": An optional URI [RFC3986] pointing to
additional information around the relevant "result-type". For additional information around the relevant "result-type". For
example, this URI might host the complete certificate chain example, this URI might host the complete certificate chain
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 via the following
dec-octet "." dec-octet "." dec-octet "." dec-octet ABNF:
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 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
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
4.5. Policy Samples 4.5. Policy Samples
Part of the report body includes the policy that is applied when Part of the report body includes the policy that is applied when
attemping relay to the destination. attemping relay to the destination.
For DANE TLSA policies, a JSON array of strings each representing the For DANE TLSA policies, this is a JSON array of strings each
RDATA of a single TLSA resource record as a space-separated list of representing the RDATA of a single TLSA resource record as a space-
its four TLSA fields; the fields are in presentation format (defined separated list of its four TLSA fields; the fields are in
in RFC6698 Section 2.2) with no internal spaces or grouping presentation format (defined in [RFC6698] Section 2.2) with no
parentheses: internal spaces or grouping parentheses:
[ "3 0 1 [ "3 0 1
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", "3 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", "3
0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234" 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"
] ]
For the MTA-STS policy, an array of JSON strings that represents the For MTA-STS policies, this is an array of JSON strings that
policy that is declared by the receiving site, including any errors represents the policy that is declared by the receiving site,
that may be present. Note that where there are multiple "mx" values, including any errors that may be present. Note that where there are
they must be listed as separate "mx" elements in the policy array, multiple "mx" values, they must be listed as separate "mx" elements
rather as a single nested "mx" sub-array. in the policy array, rather as a single nested "mx" sub-array.
[ "version: STSv1", "mode: report", "mx: mx1.example.com", "mx: [ "version: STSv1", "mode: report", "mx: mx1.example.com", "mx:
mx2.example.com", "mx: mx.backup-example.com", "max_age: 12345678" ] 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
skipping to change at page 15, line 7 skipping to change at page 15, line 9
"unique-id" allows an optional unique ID generated by the Sending MTA "unique-id" allows an optional unique ID generated by the Sending MTA
to distinguish among multiple reports generated simultaneously by to distinguish among multiple reports generated simultaneously by
different sources within the same Policy Domain. For example, this different sources within the same Policy Domain. For example, this
is a possible filename for a compressed report to the Policy Domain is a possible filename for a compressed report to the Policy Domain
"example.net" from the Sending MTA "mail.sndr.example.com": "example.net" from the Sending MTA "mail.sndr.example.com":
"mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz" "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
5.2. Compression 5.2. Compression
The report SHOULD be subjected to GZIP compression for both email and The report SHOULD be subjected to GZIP [RFC1952] compression for both
HTTPS transport. Declining to apply compression can cause the report email and HTTPS transport. Declining to apply compression can cause
to be too large for a receiver to process (a commonly observed the report to be too large for a receiver to process (a commonly
receiver limit is ten megabytes); compressing the file increases the observed receiver limit is ten megabytes); compressing the file
chances of acceptance of the report at some compute cost. increases the chances of acceptance of the report at some compute
cost.
5.3. Email Transport 5.3. Email Transport
The report MAY be delivered by email. To make the reports machine- The report MAY be delivered by email. To make the reports machine-
parsable for the receivers, we define a top-level media type parsable for the receivers, we define a top-level media type
"multipart/report" with a new parameter "report-type="tlsrpt"". "multipart/report" with a new parameter "report-type="tlsrpt"".
Inside it, there are two parts: The first part is human readable, Inside it, there are two parts: The first part is human readable,
typically "text/plain", and the second part is machine readable with typically "text/plain", and the second part is machine readable with
a new media type defined called "application/tlsrpt+json". If a new media type defined called "application/tlsrpt+json". If
compressed, the report should use the media type "application/ compressed, the report should use the media type "application/
skipping to change at page 17, line 47 skipping to change at page 17, line 47
Note that, when sending failure reports via SMTP, sending MTAs MUST Note that, when sending failure reports via SMTP, sending MTAs MUST
NOT honor MTA-STS or DANE TLSA failures. NOT honor MTA-STS or DANE TLSA failures.
5.4. HTTPS Transport 5.4. HTTPS Transport
The report MAY be delivered by POST to HTTPS. If compressed, the The report MAY be delivered by POST to HTTPS. If compressed, the
report SHOULD use the media type "application/tlsrpt+gzip", and report SHOULD use the media type "application/tlsrpt+gzip", and
"application/tlsrpt+json" otherwise (see section Section 6, "IANA "application/tlsrpt+json" otherwise (see section Section 6, "IANA
Considerations"). Considerations").
A reporting entity SHOULD expect a "successful" response from the The receiving system MUST return a "successful" response from its
accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. HTTPS server, typically a 200 or 201 HTTP code [RFC7321]. Other
Other codes could indicate a delivery failure, and may be retried as codes could indicate a delivery failure, and may be retried as per
per local policy. The receiving system is not expected to process local sender policy. The receiving system is not expected to process
reports at receipt time, and MAY store them for processing at a later reports at receipt time, and MAY store them for processing at a later
time. time.
Alternately, if a receiving system offers "Accept-Encoding" value of
"gzip", the sending system MAY use "Content-Encoding: gzip" as an
HTTP header as appropriate. This can be used in place of delivering
a compressed file as the payload.
5.5. Delivery Retry 5.5. Delivery Retry
In the event of a delivery failure, regardless of the delivery In the event of a delivery failure, regardless of the delivery
method, a sender SHOULD attempt redelivery for up to 24hrs after the method, a sender SHOULD attempt redelivery for up to 24hrs after the
initial attempt. As previously stated the reports are optional, so initial attempt. As previously stated the reports are optional, so
while it is ideal to attempt redelivery, it is not required. If while it is ideal to attempt redelivery, it is not required. If
multiple retries are attempted, ideally they SHOULD be done with multiple retries are attempted, ideally they SHOULD be done with
exponential backoff. exponential backoff.
5.6. Metadata Variances 5.6. Metadata Variances
skipping to change at page 19, line 13 skipping to change at page 19, line 5
Specification document(s): this one Specification document(s): this one
6.2. Report Type 6.2. Report Type
This document registers a new parameter "report-type="tlsrpt"" under This document registers a new parameter "report-type="tlsrpt"" under
"multipart/report" top-level media type for use with [RFC6522]. "multipart/report" top-level media type for use with [RFC6522].
The media type suitable for use as a report-type is defined in the The media type suitable for use as a report-type is defined in the
following section. following section.
6.3. application/tlsrpt+json Media Type 6.3. +gzip Media Type Suffix
This document registers a new media type suffix "+gzip". The GZIP
format is a public domain, cross-platform, interoperable file storage
and transfer format, specified in [RFC1952]; it supports compression
and is used as the underlying representation by a variety of file
formats. The media type "application/gzip" has been registered for
such files. The suffix "+gzip" MAY be used with any media type whose
representation follows that established for "application/gzip". The
media type structured syntax suffix registration form follows:
Type name: GZIP file storage and transfer format
+suffix: +gzip
References: [RFC1952][RFC6713]
Encoding considerations: GZIP is a binary encoding.
Fragment identifier considerations: The syntax and semantics of
fragment identifiers specified for +gzip SHOULD be as specified for
"application/gzip". (At publication of this document, there is no
fragment identification syntax defined for "application/gzip".) The
syntax and semantics for fragment identifiers for a specific "xxx/
yyy+gzip" SHOULD be processed as follows:
For cases defined in +gzip, where the fragment identifier
resolves per the +gzip rules, then process as specified in
+gzip.
For cases defined in +gzip, where the fragment identifier does
not resolve per the +gzip rules, then process as specified in
"xxx/yyy+gzip".
For cases not defined in +gzip, then process as specified in
"xxx/yyy+gzip".
Interoperability considerations: n/a
Security considerations: GZIP format doesn't provide encryption. See
also security considerations of [RFC6713]. Each individual media
type registered with a +gzip suffix can have additional security
considerations
Contact: art@ietf.org
Author/Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
6.4. application/tlsrpt+json Media Type
This document registers multiple media types, beginning with Table 1 This document registers multiple media types, beginning with Table 1
below. below.
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
| Type | Subtype | File extn | Specification | | Type | Subtype | File extn | Specification |
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
| application | tlsrpt+json | .json | Section 5.3 | | application | tlsrpt+json | .json | Section 5.3 |
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
Table 1: SMTP TLS Reporting Media Type Table 1: SMTP TLS Reporting Media Type
skipping to change at page 19, line 38 skipping to change at page 20, line 30
Required parameters: n/a Required parameters: n/a
Optional parameters: n/a Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See those specified for the "application/json" media type. See
[RFC7493]. [RFC7493].
Security considerations: Security considerations relating to SMTP TLS Security considerations: Security considerations relating to SMTP TLS
Reporting are discussed in Section 7. Reporting are discussed in Section 7. Security considerations
related to zlib compression are discussed in [RFC6713].
Interoperability considerations: This document specifies format of Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof. conforming messages and the interpretation thereof.
Published specification: Section 5.3 of this document. Published specification: Section 5.3 of this document.
Applications that use this media type: Mail User Agents (MUA) and Applications that use this media type: Mail User Agents (MUA) and
Mail Transfer Agents. Mail Transfer Agents.
Additional information: Additional information:
Magic number(s): n/a Magic number(s): The first two bytes are 0x1f, 0x8b.
File extension(s): ".json" File extension(s): ".json"
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
Person & email address to contact for further information: See Person & email address to contact for further information: See
Authors' Addresses section. Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: n/a Restrictions on usage: n/a
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org). (mailto:iesg@ietf.org).
6.4. application/tlsrpt+gzip Media Type 6.5. application/tlsrpt+gzip Media Type
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
| Type | Subtype | File extn | Specification | | Type | Subtype | File extn | Specification |
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
| application | tlsrpt+gzip | .gz | Section 5.3 | | application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
Table 2: SMTP TLS Reporting Media Type Table 2: SMTP TLS Reporting Media Type
Type name: application Type name: application
skipping to change at page 21, line 25 skipping to change at page 22, line 14
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: n/a Restrictions on usage: n/a
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org). (mailto:iesg@ietf.org).
6.5. STARTTLS Validation Result Types 6.6. STARTTLS Validation Result Types
This document creates a new registry, "STARTTLS Validation Result This document creates a new registry, "STARTTLS Validation Result
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" |
skipping to change at page 22, line 31 skipping to change at page 23, line 17
Implementers are advised to take precautions against evaluating Implementers are advised to take precautions against evaluating
the contents of the report. the contents of the report.
o Report snooping: An attacker could create a bogus TLSRPT record to o Report snooping: An attacker could create a bogus TLSRPT record to
receive statistics about a domain the attacker does not own. receive statistics about a domain the attacker does not own.
Since an attacker able to poison DNS is already able to receive Since an attacker able to poison DNS is already able to receive
counts of SMTP connections (and, absent DANE or MTA-STS policies, counts of SMTP connections (and, absent DANE or MTA-STS policies,
actual SMTP message payloads), this does not present a significant actual SMTP message payloads), this does not present a significant
new vulnerability. new vulnerability.
o Ignoring HTTPS validation when submitting reports: When reporting
benign misconfigurations, it is likely that a misconfigured SMTP
server may also mean a misconfigured HTTPS server; as a result,
reporters who required HTTPS validity on the reporting endpoint
may fail to alert administrators about such misconfigurations.
Conversely, in the event of an actual attack, an attacker who
wished to create a gap in reporting and could intercept HTTPS
reports could, just as easily, simply thwart the resolution of the
TLSRPT TXT record or establishment of the TCP session to the HTTPS
endpoint. Furthermore, such a man-in-the-middle attacker could
discover most or all of the metadata exposed in a report merely
through passive observation. As a result, we consider the risks
of failure to deliver reports on misconfigurations to outweigh
those of attackers intercepting reports.
o Reports as DDoS: TLSRPT allows specifying destinations for the o Reports as DDoS: TLSRPT allows specifying destinations for the
reports that are outside the authority of the Policy Domain, which reports that are outside the authority of the Policy Domain, which
allows domains to delegate processing of reports to a partner allows domains to delegate processing of reports to a partner
organization. However, an attacker who controls the Policy Domain organization. However, an attacker who controls the Policy Domain
DNS could also use this mechanism to direct the reports to an DNS could also use this mechanism to direct the reports to an
unwitting victim, flooding that victim with excessive reports. unwitting victim, flooding that victim with excessive reports.
DMARC [RFC7489] defines a solution for verifying delegation to DMARC [RFC7489] defines a solution for verifying delegation to
avoid such attacks; the need for this is greater with DMARC, avoid such attacks; the need for this is greater with DMARC,
however, because DMARC allows an attacker to trigger reports to a however, because DMARC allows an attacker to trigger reports to a
target from an innocent third party by sending that third party target from an innocent third party by sending that third party
skipping to change at page 23, line 7 skipping to change at page 24, line 8
Finally, because TLSRPT is intended to help administrators discover Finally, because TLSRPT is intended to help administrators discover
man-in-the-middle attacks against transport-layer encryption, man-in-the-middle attacks against transport-layer encryption,
including attacks designed to thwart negotiation of encrypted including attacks designed to thwart negotiation of encrypted
connections (by downgrading opportunistic encryption or, in the case connections (by downgrading opportunistic encryption or, in the case
of MTA-STS, preventing discovery of a new MTA-STS policy), we must 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 also consider the risk that an adversary who can induce such a
downgrade attack can also prevent discovery of the TLSRPT TXT record downgrade attack can also prevent discovery of the TLSRPT TXT record
(and thus prevent discovery of the successful downgrade attack). (and thus prevent discovery of the successful downgrade attack).
Administrators are thus encouraged to deploy TLSRPT TXT records with Administrators are thus encouraged to deploy TLSRPT TXT records with
a large TTL (reducing the window for successful attacks against DNS a large TTL (reducing the window for successful application of
resolution of the record) or to deploy DNSSEC on the deploying zone. transient attacks against DNS resolution of the record) or to deploy
DNSSEC on the deploying zone.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-uta-mta-sts] [I-D.ietf-uta-mta-sts]
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
and J. Jones, "SMTP MTA Strict Transport Security (MTA- and J. Jones, "SMTP MTA Strict Transport Security (MTA-
STS)", draft-ietf-uta-mta-sts-14 (work in progress), STS)", draft-ietf-uta-mta-sts-15 (work in progress), April
January 2018. 2018.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>. <https://www.rfc-editor.org/info/rfc3492>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, DOI 10.17487/RFC4408, April 2006,
<https://www.rfc-editor.org/info/rfc4408>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 24, line 49 skipping to change at page 26, line 15
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
the Reporting of Mail System Administrative Messages", the Reporting of Mail System Administrative Messages",
STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<https://www.rfc-editor.org/info/rfc6522>. <https://www.rfc-editor.org/info/rfc6522>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip'
Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012,
<https://www.rfc-editor.org/info/rfc6713>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc- DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
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 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, <https://www.rfc- DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
editor.org/info/rfc7672>. editor.org/info/rfc7672>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, <https://www.rfc- DOI 10.17487/RFC3864, September 2004, <https://www.rfc-
editor.org/info/rfc3864>. editor.org/info/rfc3864>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
Implementation Requirements and Usage Guidance for
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
<https://www.rfc-editor.org/info/rfc7321>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[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
skipping to change at page 27, line 27 skipping to change at page 28, line 27
"mx: .mail.company-y.example","max_age: 86400"], "mx: .mail.company-y.example","max_age: 86400"],
"policy-domain": "company-y.example", "policy-domain": "company-y.example",
"mx-host": ".mail.company-y.example" "mx-host": ".mail.company-y.example"
}, },
"summary": { "summary": {
"total-successful-session-count": 5326, "total-successful-session-count": 5326,
"total-failure-session-count": 303 "total-failure-session-count": 303
}, },
"failure-details": [{ "failure-details": [{
"result-type": "certificate-expired", "result-type": "certificate-expired",
"sending-mta-ip": "98.136.216.25", "sending-mta-ip": "2001:db8:abcd:0012::1",
"receiving-mx-hostname": "mx1.mail.company-y.example", "receiving-mx-hostname": "mx1.mail.company-y.example",
"failed-session-count": 100 "failed-session-count": 100
}, { }, {
"result-type": "starttls-not-supported", "result-type": "starttls-not-supported",
"sending-mta-ip": "98.22.33.99", "sending-mta-ip": "2001:db8:abcd:0013::1",
"receiving-mx-hostname": "mx2.mail.company-y.example", "receiving-mx-hostname": "mx2.mail.company-y.example",
"receiving-ip": "192.168.14.72", "receiving-ip": "203.0.113.56",
"failed-session-count": 200, "failed-session-count": 200,
"additional-information": "https://reports.company-x.example/ "additional-information": "https://reports.company-x.example/
report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported " report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
}, { }, {
"result-type": "validation-failure", "result-type": "validation-failure",
"sending-mta-ip": "47.97.15.2", "sending-mta-ip": "198.51.100.62",
"receiving-ip": "10.72.84.12", "receiving-ip": "203.0.113.58",
"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"
}] }]
}] }]
} }
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
 End of changes. 46 change blocks. 
101 lines changed or deleted 204 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/