draft-ietf-uta-smtp-tlsrpt-20.txt   draft-ietf-uta-smtp-tlsrpt-21.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: November 3, 2018 Comcast, Inc Expires: November 21, 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
May 2, 2018 May 20, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-20 draft-ietf-uta-smtp-tlsrpt-21
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 November 3, 2018. This Internet-Draft will expire on November 21, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 7 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 7
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 9
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 9 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 10
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 10 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 11
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 11
4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 14
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 15
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 17
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 18
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 19
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 18 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 18 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 19
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 19 6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 20
6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 20 6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 21
6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 21 6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 23
6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 22 6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 28
A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 27 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 27 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 29
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 27 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 29
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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]. This method maintains interoperability Security" (OS) [RFC7435]. This method maintains interoperability
with clients that do not support STARTTLS, but means that any with clients that do not support STARTTLS, but means that any
attacker could potentially eavesdrop on a session. An attacker could attacker could potentially eavesdrop on a session. An attacker could
perform a downgrade or interception attack by deleting parts of the perform a downgrade or interception attack by deleting parts of the
skipping to change at page 4, line 20 skipping to change at page 4, line 24
[BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 mechanism by which administrators can specify o MTA-STS Policy: A mechanism by which administrators can specify
the expected TLS availability, presented identity, and desired the expected TLS availability, presented identity, and desired
actions for a given email recipient domain. MTA-STS is defined in actions for a given email recipient domain. MTA-STS is defined in
[I-D.ietf-uta-mta-sts]. [I-D.ietf-uta-mta-sts].
o DANE Policy: A mechanism by which administrators can specify o DANE Policy: A mechanism by which administrators can use DNSSEC to
constraints to be used to validate certificates presented by an commit an MTA to support STARTTLS and to publish criteria to be
MTA. DANE is defined in [RFC6698] and [RFC7672]. used to validate its presented certificates. DANE for SMTP is
defined in [RFC7672], with the base specification in [RFC6698]
(updated in [RFC7671].
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. This should be the same as the recipient envelope is defined. For MTA-STS this is typically the same as the
domain [RFC5321], such as if the message were going to envelope recipient domain [RFC5321], but when mail is routed to a
"alice@example.com', the policy domain would be "example.com". "smarthost" gateway by local policy, the "smarthost" domain name
is used instead. For DANE the Policy Domain is the "TLSA base
domain" of the receiving SMTP server as described in RFC7672 [1]
and RFC6698 [2].
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 o Aggregate Report URI (rua): A comma-separated list of locations
where the report is to be submitted. 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].
skipping to change at page 6, line 17 skipping to change at page 6, line 17
field-delim = *WSP ";" *WSP field-delim = *WSP ";" *WSP
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-field = tlsrpt-rua / ; Note that the
tlsrpt-extension ; tlsrpt-rua record is tlsrpt-extension ; tlsrpt-rua record is
; required. ; required.
tlsrpt-version = %s"v=TLSRPTv1" tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-rua = %s"rua=" tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI tlsrpt-uri = URI
; "URI" is imported from [RFC3986]; ; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C), exclamation ; commas (ASCII 0x2C), exclamation
; points (ASCII 0x21), and semicolons ; points (ASCII 0x21), and semicolons
; (ASCII 0x3B) MUST be encoded ; (ASCII 0x3B) MUST be encoded
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
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 (as described in resulting TXT record contains multiple strings (as described in
skipping to change at page 8, line 24 skipping to change at page 8, line 24
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
be delivered after some delay, perhaps several hours. be delivered after some delay, perhaps several hours.
As an example, a sending site might want to introduce a random delay
of up to four hours:
func generate_sleep_delay() {
min_delay = 1
max_delay = 14400
rand = random(min_delay,max_delay)
return rand
}
func generate_report(policy_domain) {
do_rpt_work(policy_domain)
send_rpt(policy_domain)
}
func generate_tlsrpt() {
sleep(generate_sleep_delay())
for policy_domain in list_of_tlsrpt_enabled_domains {
generate_report(policy_domain)
}
}
A sending site might wish to introduce a random delay per destination
site, up to four hours:
func generate_sleep_delay() {
min_delay = 1
max_delay = 14400
rand = random(min_delay,max_delay)
return rand
}
func generate_report(policy_domain) {
sleep(generate_sleep_delay())
do_rpt_work(policy_domain)
send_rpt(policy_domain)
}
func generate_tlsrpt() {
for policy_domain in list_of_tlsrpt_enabled_domains {
generate_report(policy_domain)
}
}
4.2. Delivery Summary 4.2. Delivery Summary
4.2.1. Success Count 4.2.1. Success Count
o "total-successful-session-count": This indicates that the sending o "total-successful-session-count": This indicates that the sending
MTA was able to successfully negotiate a policy-compliant TLS MTA was able to successfully negotiate a policy-compliant TLS
connection, and serves to provide a "heartbeat" to receiving connection, and serves to provide a "heartbeat" to receiving
domains that reporting is functional and tabulating correctly. domains that reporting is functional and tabulating correctly.
This field contains an aggregate count of successful connections This field contains an aggregate count of successful connections
for the reporting system. for the reporting system.
skipping to change at page 14, line 10 skipping to change at page 15, line 10
] ]
For MTA-STS policies, this is an array of JSON strings that For MTA-STS policies, this is an array of JSON strings that
represents the policy that is declared by the receiving site, represents the policy that is declared by the receiving site,
including any errors that may be present. Note that where there are including any errors that may be present. Note that where there are
multiple "mx" values, they must be listed as separate "mx" elements multiple "mx" values, they must be listed as separate "mx" elements
in the policy array, rather as a single nested "mx" sub-array. in the policy array, rather as a single nested "mx" sub-array.
[ [
"version: STSv1", "version: STSv1",
"mode: report", "mode: testing",
"mx: mx1.example.com", "mx: mx1.example.com",
"mx: mx2.example.com", "mx: mx2.example.com",
"mx: mx.backup-example.com", "mx: mx.backup-example.com",
"max_age: 12345678" "max_age: 604800"
] ]
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:
filename = sender "!" policy-domain "!" begin-timestamp filename = sender "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension "!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT) unique-id = 1*(ALPHA / DIGIT)
sender = domain ; From the [RFC5321] that is used sender = domain ; From the [RFC5321] that is used
; as the domain for the `contact-info` ; as the domain for the `contact-info`
; address in the report body ; address in the report body
policy-domain = domain policy-domain = domain
begin-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained ; indicating start of the time range contained
; in the report ; in the report
end-timestamp = 1*DIGIT end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; indicating end of the time range contained
; in the report ; in the report
extension = "json" / "json.gz" extension = "json" / "json.gz"
The extension MUST be "json" for a plain JSON file, or "json.gz" for The extension MUST be "json" for a plain JSON file, or "json.gz" for
a JSON file compressed using GZIP. a JSON file compressed using GZIP.
"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":
skipping to change at page 16, line 10 skipping to change at page 17, line 10
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
the following ABNF: the following ABNF:
tlsrpt-subject = %s"Report" FWS ; "Report" tlsrpt-subject = %s"Report" FWS ; "Report"
%s"Domain:" FWS ; "Domain:" %s"Domain:" FWS ; "Domain:"
domain-name FWS ; per [RFC6376] domain-name FWS ; per [RFC6376]
%s"Submitter:" FWS ; "Submitter:" %s"Submitter:" FWS ; "Submitter:"
domain-name FWS ; per [RFC6376] domain-name FWS ; per [RFC6376]
%s"Report-ID:" FWS ; "Report-ID: %s"Report-ID:" FWS ; "Report-ID:
"<" id-left "@" id-right ">" ; per [RFC5322] "<" id-left "@" id-right ">" ; per [RFC5322]
[CFWS] ; per [RFC5322] [CFWS] ; per [RFC5322]
; (as with FWS) ; (as with FWS)
The first domain-name indicates the DNS domain name about which the The first domain-name indicates the DNS domain name about which the
report was generated. The second domain-name indicates the DNS report was generated. The second domain-name indicates the DNS
domain name representing the Sending MTA generating the report. The domain name representing the Sending MTA generating the report. The
purpose of the Report-ID: portion of the field is to enable the purpose of the Report-ID: portion of the field is to enable the
Policy Domain to identify and ignore duplicate reports that might be Policy Domain to identify and ignore duplicate reports that might be
sent by a Sending MTA. sent by a Sending MTA.
For instance, this is a possible Subject field for a report to the For instance, this is a possible Subject field for a report to the
skipping to change at page 18, line 46 skipping to change at page 19, line 46
Specification document(s): this one Specification document(s): this one
Header field name: TLS-Report-Submitter Header field name: TLS-Report-Submitter
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
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 creates a new registry for "report-type" parameter to
"multipart/report" top-level media type for use with [RFC6522]. the Content-Type header field for the "multipart/report" top-level
media type defined in [RFC6522].
The media type suitable for use as a report-type is defined in the The registry name is "Report Type Registry", and the procedure for
following section. updating the registry will be "Specification Required".
An entry in this registry should contain:
o the report-type being registered
o one or more registered media-types that can be used with this
report-type
o the document containing the registration action
o an optional comment
The initial entries are:
Report-Type: tlsrpt
Media Type: application/tlsrpt+gzip, application/tlsrpt+json
Registered By: [RFCXXXX]
Comment: Media types suitable for use with this report-type are defined in Sections 6.4 and 6.5 of [RFCXXXX]
Report-Type: disposition-notification
Media Type: message/disposition-notification
Registered By: [@?RFC8098]
Report-Type: disposition-notification
Media Type: message/global-disposition-notification
Registered By: [@?RFC6533]
Report-Type: delivery-status
Media Type: message/delivery-status
Registered By: [@?RFC3464]
Report-Type: delivery-status
Media Type: message/global-delivery-status
Registered By: [@?RFC6533]
6.3. +gzip Media Type Suffix 6.3. +gzip Media Type Suffix
This document registers a new media type suffix "+gzip". The GZIP This document registers a new media type suffix "+gzip". The GZIP
format is a public domain, cross-platform, interoperable file storage format is a public domain, cross-platform, interoperable file storage
and transfer format, specified in [RFC1952]; it supports compression and transfer format, specified in [RFC1952]; it supports compression
and is used as the underlying representation by a variety of file and is used as the underlying representation by a variety of file
formats. The media type "application/gzip" has been registered for formats. The media type "application/gzip" has been registered for
such files. The suffix "+gzip" MAY be used with any media type whose such files. The suffix "+gzip" MAY be used with any media type whose
representation follows that established for "application/gzip". The representation follows that established for "application/gzip". The
skipping to change at page 22, line 19 skipping to change at page 24, line 14
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.6. 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 | Desc |
+-------------------------------+ +-------------------------------+-----------+
| "starttls-not-supported" | | "starttls-not-supported" | 4.3 |
| "certificate-host-mismatch" | | "certificate-host-mismatch" | 4.3 |
| "certificate-expired" | | "certificate-expired" | 4.3 |
| "tlsa-invalid" | | "tlsa-invalid" | 4.3 |
| "dnssec-invalid" | | "dnssec-invalid" | 4.3 |
| "dane-required" | | "dane-required" | 4.3 |
| "certificate-not-trusted" | | "certificate-not-trusted" | 4.3 |
| "sts-policy-invalid" | | "sts-policy-invalid" | 4.3 |
| "sts-webpki-invalid" | | "sts-webpki-invalid" | 4.3 |
| "validation-failure" | | "validation-failure" | 4.3 |
+-------------------------------+ +-------------------------------+-----------+
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
SMTP TLS Reporting provides transparency into misconfigurations or SMTP TLS Reporting provides transparency into misconfigurations or
attempts to intercept or tamper with mail between hosts who support attempts to intercept or tamper with mail between hosts who support
STARTTLS. There are several security risks presented by the STARTTLS. There are several security risks presented by the
skipping to change at page 24, line 12 skipping to change at page 26, line 7
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 application of a large TTL (reducing the window for successful application of
transient attacks against DNS resolution of the record) or to deploy transient attacks against DNS resolution of the record) or to deploy
DNSSEC on the deploying zone. DNSSEC on the deploying zone.
8. References 8. Privacy Considerations
8.1. Normative References MTAs are generally considered public knowledge, however, the
internals of how those MTAs are configured and the users of those
MTAs may not be as public. It should be noted that when providing a
receiving site with information, it may reveal information about the
sender's configuration, or even information about the senders
themselves. Consider that by sending a report, it might disclose
your SSL library version as the inability to negotiate a session may
be a known incompatbility between two library versions, or perhaps
commonly used in a operating system release that is centered in a
certain region. The risk may be minimal, but should be considered.
9. References
9.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-15 (work in progress), April STS)", draft-ietf-uta-mta-sts-17 (work in progress), May
2018. 2018.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <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>.
skipping to change at page 26, line 42 skipping to change at page 28, line 47
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 9.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
skipping to change at page 27, line 29 skipping to change at page 29, line 33
[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>.
9.3. URIs
[1] Section 2.2.3
[2] Section 3
Appendix A. Example Reporting Policy Appendix A. Example Reporting Policy
A.1. Report using MAILTO A.1. Report using MAILTO
_smtp._tls.mail.example.com. IN TXT \ _smtp._tls.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._tls.mail.example.com. IN TXT \ _smtp._tls.mail.example.com. IN TXT \
skipping to change at page 28, line 16 skipping to change at page 31, line 16
"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": {
"policy-type": "sts", "policy-type": "sts",
"policy-string": ["version: STSv1","mode: report", "policy-string": ["version: STSv1","mode: testing",
"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": "2001:db8:abcd:0012::1", "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
 End of changes. 33 change blocks. 
99 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/