draft-ietf-uta-smtp-tlsrpt-06.txt   draft-ietf-uta-smtp-tlsrpt-07.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: December 01, 2017 Comcast, Inc Expires: February 1, 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 31, 2017 July 31, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-06 draft-ietf-uta-smtp-tlsrpt-07
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 [RFC3207], DANE between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due [RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
to misconfiguration or active attack, leading to undelivered messages to misconfiguration or active attack, leading to undelivered messages
or delivery over unencrypted or unauthenticated channels. This or delivery over unencrypted or unauthenticated channels. This
document describes a reporting mechanism and format by which sending document describes a reporting mechanism and format by which sending
systems can share statistics and specific information about potential systems can share statistics and specific information about potential
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 26, 2017. This Internet-Draft will expire on February 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 6
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 13 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 14 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. application/tlsrpt+* Media Types . . . . . . . . . . . . 15 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 15
6.4. STARTTLS Validation Result Types . . . . . . . . . . . . 16 6.4. application/tlsrpt+gz Media Type . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18
8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 18
8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 18 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19
9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 18 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 20 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 5, line 17 skipping to change at page 5, line 20
The formal definition of the "_smtp-tlsrpt" TXT record, defined using The formal definition of the "_smtp-tlsrpt" TXT record, defined using
[RFC5234], is as follows: [RFC5234], is as follows:
tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua
[field-delim [tlsrpt-extensions]] [field-delim [tlsrpt-extensions]]
field-delim = %x3B ; ";" field-delim = %x3B ; ";"
tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52 tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52
%x50 %x54 %x76 %x31 ; "v=TSRPTv1" %x50 %x54 %x76 %x31 ; "v=TLSRPTv1"
tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..." tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..."
tlsrpt-uri = URI tlsrpt-uri = URI
; "URI" is imported from [@!RFC3986]; commas (ASCII ; "URI" is imported from [@!RFC3986]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21) ; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit ; MUST be encoded; the numeric portion MUST fit
; within an unsigned 64-bit integer ; within an unsigned 64-bit integer
tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension) tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
skipping to change at page 6, line 17 skipping to change at page 6, line 20
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
3.1.2. Report using HTTPS 3.1.2. Report using HTTPS
_smtp-tlsrpt.example.com. IN TXT \ _smtp-tlsrpt.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
4. Reporting Schema 4. Reporting Schema
The report is composed as a plain text file encoded in the JSON The report is composed as a plain text file encoded in the I-JSON
format ([RFC7159]). format ([RFC7493]).
Aggregate reports contain the following fields: Aggregate reports contain the following fields:
o Report metadata: o Report metadata:
* The organization responsible for the report * The organization responsible for the report
* Contact information for one or more responsible parties for the * Contact information for one or more responsible parties for the
contents of the report contents of the report
skipping to change at page 9, line 15 skipping to change at page 9, line 15
4.3.4. Transient Failures 4.3.4. Transient Failures
Transient errors due to too-busy network, TCP timeouts, etc. are not Transient errors due to too-busy network, TCP timeouts, etc. are not
required to be reported. required to be reported.
4.4. JSON Report Schema 4.4. JSON Report Schema
The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.
Section 3) Section 3)
{ {
"organization-name": organization-name, "organization-name": organization-name,
"date-range": { "date-range": {
"start-datetime": date-time, "start-datetime": date-time,
"end-datetime": date-time "end-datetime": date-time
}, },
"contact-info": email-address, "contact-info": email-address,
"report-id": report-id, "report-id": report-id,
"policy": { "policy": {
"policy-type": policy-type, "policy-type": policy-type,
"policy-string": policy-string, "policy-string": policy-string,
"policy-domain": domain, "policy-domain": domain,
"mx-host": mx-host-pattern "mx-host": mx-host-pattern
}, },
"summary": { "summary": {
"success-aggregate": total-successful-session-count, "total-successful-session-count": total-successful-session-count,
"failure-aggregate:" total-failure-session-count "total-failure-session-count:" total-failure-session-count
} }
"failure-details": [ "failure-details": [
{ {
"result-type": result-type, "result-type": result-type,
"sending-mta-ip": ip-address, "sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo, "receiving-mx-helo": receiving-mx-helo,
"session-count": failed-session-count, "failed-session-count": failed-session-count,
"additional-information": additional-info-uri, "additional-information": additional-info-uri,
"failure-reason-code": "Text body" "failure-reason-code": "failure-reason-code"
} }
] ]
} }
JSON Report Format JSON Report Format
o "organization-name": The name of the organization responsible for o "organization-name": The name of the organization responsible for
the report. It is provided as a string. the report. It is provided as a string.
o "date-time": The date-time indicates the start- and end-times for o "date-time": The date-time indicates the start- and end-times for
the report range. It is provided as a string formatted according the report range. It is provided as a string formatted according
to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The
report should be for a full UTC day, 0000-2400. report should be for a full UTC day, 0000-2400.
o "email-address": The contact information for a responsible party o "email-address": The contact information for a responsible party
of the report. It is provided as a string formatted according to of the report. It is provided as a string formatted according to
Section 3.4.1, "Addr-Spec", of [RFC5322]. Section 3.4.1, "Addr-Spec", of [RFC5321].
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": The JSON string serialization ([RFC7159] section o "policy-string": The JSON string serialization ([RFC7159] section
7) of the policy, whether TLSA record ([RFC6698] section 2.3) or 7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
MTA-STS policy. MTA-STS policy.
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. STS or DANE policy is defined. In the case of Internationalized
Domain Names ([RFC5891]), the domain is the Punycode-encoded
A-label ([RFC3492]) and not the U-label.
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]. Section 6.4.3 of [RFC6125].
o "result-type": A value from Section 4.3, "Result Types", above. o "result-type": A value from Section 4.3, "Result Types", above.
In the case of Internationalized Domain Names ([RFC5891]), the
domain is the Punycode-encoded A-label ([RFC3492]) and not the
U-label.
o "ip-address": The IP address of the sending MTA that attempted the o "ip-address": The IP address of the sending MTA that attempted the
STARTTLS connection. It is provided as a string representation of STARTTLS connection. It is provided as a string representation of
an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or
notation. colon-hexadecimal notation.
o "receiving-mx-hostname": The hostname of the receiving MTA MX o "receiving-mx-hostname": The hostname of the receiving MTA MX
record with which the sending MTA attempted to negotiate a record with which the sending MTA attempted to negotiate a
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 "success-aggregate": The aggregate number (integer) of o "total-successful-session-count": The aggregate number (integer)
successfully negotiated TLS-enabled connections to the receiving of successfully negotiated TLS-enabled connections to the
site. receiving site.
o "failure-aggregate": The aggregate number (integer) of failures to o "total-failure-session-count": The aggregate number (integer) of
negotiate an TLS-enabled connection to the receiving site. failures to negotiate an TLS-enabled connection to the receiving
site.
o "session-count": The number of (attempted) sessions that match the o "failed-session-count": The number of (attempted) sessions that
relevant "result-type" for this section. match the relevant "result-type" for this section.
o "additional-info-uri": An optional URI pointing to additional o "additional-info-uri": An optional URI [RFC3986] pointing to
information around the relevant "result-type". For example, this additional information around the relevant "result-type". For
URI might host the complete certificate chain presented during an example, this URI might host the complete certificate chain
attempted STARTTLS session. presented during an attempted STARTTLS session.
o "failure-reason-code": A text field to include an TLS-related o "failure-reason-code": A text field to include an TLS-related
error code or error message. error code or error message.
For report purposes, an IPv4 Address is defined as: 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
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 typically constructed using the following ABNF: The filename is typically constructed using the following 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 ; imported from [@!RFC5322] sender = domain ; imported from [@!RFC5321]
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
skipping to change at page 12, line 34 skipping to change at page 13, line 13
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/
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
These message headers would allow for easy searching for all reports These message headers MUST be included and should allow for easy
submitted by a report domain or a particular submitter, for example searching for all reports submitted by a report domain or a
in IMAP: particular 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. prescribed media type and filename, and ignore the rest.
The [RFC5322].Subject field for individual report submissions SHOULD The [RFC5322].Subject field for individual report submissions SHOULD
conform to the following ABNF: conform to the following ABNF:
tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS ; "Report" tlsrpt-subject = %s"Report" FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" %s"Domain:" FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376 domain-name FWS ; per RFC6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:" %s"Submitter:" FWS ; "Submitter:"
1*FWS domain-name 1*FWS domain-name FWS ; per RFC6376
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:" %s"Report-ID:" FWS ; "Report-ID:
msg-id ; from RFC 5322 "<" id-left "@" id-right ">" ; per RFC5322
[CFWS] ; per RFC5322 (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
Policy Domain "example.net" from the Sending MTA Policy Domain "example.net" from the Sending MTA
skipping to change at page 15, line 18 skipping to change at page 15, line 24
6. IANA Considerations 6. IANA Considerations
The following are the IANA considerations discussed in this document. The following are the IANA considerations discussed in this document.
6.1. Message headers 6.1. Message headers
Below is the Internet Assigned Numbers Authority (IANA) Permanent Below is the Internet Assigned Numbers Authority (IANA) Permanent
Message Header Field registration information per [RFC3864]. Message Header Field registration information per [RFC3864].
Header field name: TLS-Report-Domain Header field name: TLS-Report-Domain
Applicable protocol: smtp 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
Header field name: TLS-Report-Submitter Header field name: TLS-Report-Submitter
Applicable protocol: smtp 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 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+* Media Types 6.3. application/tlsrpt+json Media Type
This document registers multiple media types, listed in 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 |
| application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+ +-------------+----------------+-------------+-------------------+
Table 1: SMTP TLS Reporting Media Types Table 1: SMTP TLS Reporting Media Type
Type name: application Type name: application
Subtype name: This documents registers multiple subtypes, as listed
in Table 1. Subtype name: tlsrpt+json
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
[RFC7159]. [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.
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: This document is the specification for these Published specification: Section 5.3 of this document.
media types; see Table 1 for the section documenting each media type.
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): n/a
File extension(s): As listed in Table 1. 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. STARTTLS Validation Result Types 6.4. application/tlsrpt+gz Media Type
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File extn | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+
Table 2: SMTP TLS Reporting Media Type
Type name: application
Subtype name: tlsrpt+gzip
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
[RFC7493].
Security considerations: Security considerations relating to SMTP TLS
Reporting are discussed in Section 7.
Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof.
Published specification: Section 5.3 of this document.
Applications that use this media type: Mail User Agents (MUA) and
Mail Transfer Agents.
Additional information:
Magic number(s): n/a
File extension(s): ".gz"
Macintosh file type code(s): n/a
Person & email address to contact for further information: See
Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: n/a
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
6.5. STARTTLS Validation Result Types
This document creates a new registry, "STARTTLS Validation Result 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" |
| "tlsa-invalid" | | "tlsa-invalid" |
| "dnssec-invalid" | | "dnssec-invalid" |
| "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 without the Types." New result types can be added to this registry using "Expert
need to update this document. 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
existence of this reporting channel: existence of this reporting channel:
o Flooding of the Aggregate report URI (rua) endpoint: An attacker o Flooding of the Aggregate report URI (rua) endpoint: An attacker
could flood the endpoint with excessive reporting traffic and could flood the endpoint with excessive reporting traffic and
skipping to change at page 19, line 14 skipping to change at page 20, line 14
{ {
"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.com", "contact-info": "sts-reporting@company-x.com",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policy": { "policy": {
"policy-type": "sts", "policy-type": "sts",
"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\"*.mail.company-y.com\"], \"max_age\": 86400 }", "policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }",
"policy-domain": "company-y.com", "policy-domain": "company-y.com",
"mx-host": "*.mail.company-y.com" "mx-host": ".mail.company-y.com"
}, },
"summary": { "summary": {
"success-aggregate": 5326, "total-successful-session-count": 5326,
"failure-aggregate": 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": "98.136.216.25",
"receiving-mx-hostname": "mx1.mail.company-y.com", "receiving-mx-hostname": "mx1.mail.company-y.com",
"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": "98.22.33.99",
"receiving-mx-hostname": "mx2.mail.company-y.com", "receiving-mx-hostname": "mx2.mail.company-y.com",
"session-count": 200, "failed-session-count": 200,
"additional-information": "hxxps://reports.company-x.com/ "additional-information": "hxxps://reports.company-x.com/
report_info?id=5065427c-23d3#StarttlsNotSupported" report_info?id=5065427c-23d3#StarttlsNotSupported"
}, { }, {
"result-type: "validation-failure", "result-type: "validation-failure",
"sending-mta-ip": "47.97.15.2", "sending-mta-ip": "47.97.15.2",
"receiving-mx-hostname: "mx-backup.mail.company-y.com", "receiving-mx-hostname: "mx-backup.mail.company-y.com",
"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 Figure: Example JSON report for a messages from Company-X to
Company-Y, where 100 sessions were attempted to Company Y servers Company-Y, where 100 sessions were attempted to Company Y servers
with an expired certificate and 200 sessions were attempted to with an expired certificate and 200 sessions were attempted to
Company Y servers that did not successfully respond to the "STARTTLS" Company Y servers that did not successfully respond to the "STARTTLS"
command. Additionally 3 sessions failed due to command. Additionally 3 sessions failed due to
"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
skipping to change at page 20, line 24 skipping to change at page 21, line 24
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[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, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[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,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<http://www.rfc-editor.org/info/rfc3492>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://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, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <http://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[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, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
10.17487/RFC5322, October 2008, 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/
RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/
RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>. <http://www.rfc-editor.org/info/rfc6068>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
skipping to change at page 21, line 27 skipping to change at page 23, line 10
[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, <http://www.rfc-editor.org/info/rfc7469>. 2015, <http://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,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI
10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis (at) google.com Email: dmargolis (at) google.com
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
 End of changes. 48 change blocks. 
99 lines changed or deleted 194 lines changed or added

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