draft-ietf-uta-smtp-tlsrpt-09.txt   draft-ietf-uta-smtp-tlsrpt-10.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: March 9, 2018 Comcast, Inc Expires: April 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
September 5, 2017 September 28, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-09 draft-ietf-uta-smtp-tlsrpt-10
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 March 9, 2018. This Internet-Draft will expire on April 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 35 skipping to change at page 2, line 35
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 12
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 5, line 15 skipping to change at page 5, line 15
o In the case of "https", reports should be submitted via POST o In the case of "https", reports should be submitted via POST
([RFC2818]) to the specified URI. Report submitters MAY ignore ([RFC2818]) to the specified URI. Report submitters MAY ignore
certificate validation errors when submitting reports via https. certificate validation errors when submitting reports via https.
o In the case of "mailto", reports should be submitted to the o In the case of "mailto", reports should be submitted to the
specified email address ([RFC6068]). When sending failure reports specified email address ([RFC6068]). When sending failure reports
via SMTP, sending MTAs MUST deliver reports despite any TLS- via SMTP, sending MTAs MUST deliver reports despite any TLS-
related failures. This may mean that the reports are delivered in related failures. This may mean that the reports are delivered in
the clear. Additionally, reports sent via SMTP MUST contain a the clear. Additionally, reports sent via SMTP MUST contain a
valid DKIM [RFC6376] signature by the reporting domain. Reports valid DKIM [RFC6376] signature by the reporting domain. Reports
lacking such a signature MUST be ignored by the recipient. lacking such a signature MUST be ignored by the recipient. DKIM
signatures must not use the "l=" attribute to limit the body
length used in the signature.
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] & [RFC7405], is as follows:
tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
[field-delim] [field-delim]
field-delim = *WSP ";" *WSP field-delim = *WSP ";" *WSP
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-rua tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-rua
tlsrpt-extension ; record is required. tlsrpt-extension ; record is required.
tlsrpt-version = %s"v=TLSRPTv1" tlsrpt-version = %s"v=TLSRPTv1"
skipping to change at page 11, line 10 skipping to change at page 11, line 10
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": A string representation of the policy, whether
7) of the policy, whether TLSA record ([RFC6698] section 2.3) or TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:
MTA-STS policy. TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D
)"" MTA-STS: ""version: STSv1\nmode: report\nmx:
mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup-
example.com\nmax_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 is the Punycode-encoded Domain Names ([RFC5891]), the domain is the Punycode-encoded
A-label ([RFC3492]) and not the U-label. 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]. In the case of Internationalized Section 6.4.3 of [RFC6125]. In the case of Internationalized
skipping to change at page 12, line 30 skipping to change at page 12, line 36
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 ; imported from [@!RFC5321] sender = domain ; From the [@!RFC5321] that is used
; as the domain for the `contact-info`
; 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
skipping to change at page 13, line 34 skipping to change at page 13, line 41
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 MUST be included and should allow for easy The "TLS-Report-Submitter" value MUST match the value found in the
searching for all reports submitted by a report domain or a filename and the [RFC5321] domain from the "contact-info" from the
report body. These message headers MUST be included and should allow
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
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.
skipping to change at page 23, line 36 skipping to change at page 23, line 36
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
the Reporting of Mail System Administrative Messages", the Reporting of Mail System Administrative Messages",
STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<https://www.rfc-editor.org/info/rfc6522>. <https://www.rfc-editor.org/info/rfc6522>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March RFC 7405, DOI 10.17487/RFC7405, December 2014,
2014, <https://www.rfc-editor.org/info/rfc7159>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, <https://www.rfc- DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
editor.org/info/rfc7493>. editor.org/info/rfc7493>.
10.2. Informative References 10.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>.
 End of changes. 11 change blocks. 
16 lines changed or deleted 26 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/