draft-ietf-uta-smtp-tlsrpt-14.txt   draft-ietf-uta-smtp-tlsrpt-15.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: July 30, 2018 Comcast, Inc Expires: August 23, 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
January 26, 2018 February 19, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-14 draft-ietf-uta-smtp-tlsrpt-15
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 July 30, 2018. This Internet-Draft will expire on August 23, 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 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 12 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 13
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 10, line 30 skipping to change at page 10, line 30
"summary": { "summary": {
"total-successful-session-count": total-successful-session-count, "total-successful-session-count": total-successful-session-count,
"total-failure-session-count": 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,
"receiving-ip": receiving-ip,
"failed-session-count": failed-session-count, "failed-session-count": failed-session-count,
"additional-information": additional-info-uri, "additional-information": additional-info-uri,
"failure-reason-code": failure-reason-code "failure-reason-code": failure-reason-code
} }
] ]
} }
] ]
} }
JSON Report Format JSON Report Format
skipping to change at page 11, line 16 skipping to change at page 11, line 20
may use whatever scheme they prefer to generate a unique may use whatever scheme they prefer to generate a unique
identifier. It is provided as a string. identifier. It is provided as a string.
o "policy-type": The type of policy that was applied by the sending o "policy-type": The type of policy that was applied by the sending
domain. Presently, the only three valid choices are "tlsa", domain. Presently, the only three valid choices are "tlsa",
"sts", and the literal string "no-policy-found". It is provided "sts", and the literal string "no-policy-found". It is provided
as a string. as a string.
o "policy-string": A string representation of the policy, whether o "policy-string": A string representation of the policy, whether
TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:
TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13
6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version: For DANE TLSA policies, a JSON array array of strings each
STSv1\nmode: report\nmx: mx1.example.com\nmx: \ representing the RDATA of a single TLSA resource record as a space-
mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678"" separated list of its four TLSA fields (in RFC6698 Section 2.2)
presentation form with no internal spaces or grouping parentheses:
["3 0 1
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D",
3 0 1
12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"]
MTA-STS (array of JSON strings):
["version: STSv1","mode: report","mx: mx1.example.com","mx:
mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"]
o "domain": The Policy Domain is the domain against which the MTA- o "domain": The Policy Domain is the domain against which the MTA-
STS or DANE policy is defined. In the case of Internationalized STS or DANE policy is defined. In the case of Internationalized
Domain Names ([RFC5891]), the domain MUST consist of the Punycode- Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
encoded A-labels ([RFC3492]) and not the U-labels. encoded A-labels ([RFC3492]) and not the U-labels.
o "mx-host-pattern": The pattern of MX hostnames from the applied o "mx-host-pattern": The pattern of MX hostnames from the applied
policy. It is provided as a string, and is interpreted in the policy. It is provided as a string, and is interpreted in the
same manner as the "Checking of Wildcard Certificates" rules in same manner as the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125]. In the case of Internationalized Section 6.4.3 of [RFC6125]. In the case of Internationalized
skipping to change at page 13, line 26 skipping to change at page 13, line 31
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" extension = "json" / "json.gz"
The extension MUST be "json" for a plain JSON file, or "json.gz" for
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 the gzip file of a report to the Policy is a possible filename for a compressed report to the Policy Domain
Domain "example.net" from the Sending MTA "mail.sender.example.com": "example.net" from the Sending MTA "mail.sndr.example.com":
"mail.sender.example.com!example.net!1470013207!1470186007!001.json" "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 compression for both email and
HTTPS transport. Declining to apply compression can cause the report HTTPS transport. Declining to apply compression can cause the report
to be too large for a receiver to process (a commonly observed to be too large for a receiver to process (a commonly observed
receiver limit is ten megabytes); compressing the file increases the receiver limit is ten megabytes); compressing the file increases the
chances of acceptance of the report at some compute cost. chances of acceptance of the report at some compute cost.
5.3. Email Transport 5.3. Email Transport
skipping to change at page 14, line 10 skipping to change at page 14, line 19
"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/
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-Submitter: Sender- "TLS-Report-Domain: Receiver-Domain"
Domain"
"TLS-Report-Submitter: Sender-Domain"
The "TLS-Report-Submitter" value MUST match the value found in the The "TLS-Report-Submitter" value MUST match the value found in the
filename and the [RFC5321] domain from the "contact-info" from the filename and the [RFC5321] domain from the "contact-info" from the
report body. These message headers MUST be included and should allow report body. These message headers MUST be included and should allow
for easy searching for all reports submitted by a report domain or a for easy searching for all reports submitted by a report domain or a
particular submitter, for example in IMAP [RFC3501]: 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
skipping to change at page 15, line 37 skipping to change at page 15, line 45
Content-Type: text/plain; charset="us-ascii" Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
This is an aggregate TLS report from mail.sender.example.com This is an aggregate TLS report from mail.sender.example.com
------=_NextPart_000_024E_01CC9B0A.AFE54C00 ------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/tlsrpt+gzip Content-Type: application/tlsrpt+gzip
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; Content-Disposition: attachment;
filename="mail.sender.example!example.com! filename="mail.sender.example!example.com!
1013662812!1013749130.gz" 1013662812!1013749130.json.gz"
<gzipped content of report> <gzipped content of report>
------=_NextPart_000_024E_01CC9B0A.AFE54C00-- ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
... ...
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
The report MAY be delivered by POST to HTTPS. When doing so, the "application/tlsrpt+json" otherwise (see section Section 6, "IANA
report should use the media-type "application/tlsrpt" (see section Considerations").
Section 6, "IANA Considerations"). If the reporting entity
compresses the report, that should be noted in the Content-Type
"conversions" field:
Content-Type: application/tlsrpt; conversions=gzip Content-Type:
application/tlsrpt; conversions=none Content-Type: application/tlsrpt
The second and third items in the list are equivalent.
A reporting entity SHOULD expect a "successful" response from the A reporting entity SHOULD expect a "successful" response from the
accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
Other codes could indicate a delivery failure, and may be retried as Other codes could indicate a delivery failure, and may be retried as
per local policy. The receiving system is not expected to process per local 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 25, line 15 skipping to change at page 25, line 15
"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\r\nmode: report\r\n "policy-string": ["version: STSv1","mode: report",
mx: .mail.company-y.example\r\nmax_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": "98.136.216.25",
 End of changes. 17 change blocks. 
30 lines changed or deleted 43 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/