draft-ietf-uta-smtp-tlsrpt-00.txt   draft-ietf-uta-smtp-tlsrpt-01.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 13, 2016 Comcast, Inc Expires: January 9, 2017 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 13, 2016 July 8, 2016
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-00 draft-ietf-uta-smtp-tlsrpt-01
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 SMTP MTA STS (TODO: Add ref). These protocols can [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can
fail due to misconfiguration or active attack, leading to undelivered fail due to misconfiguration or active attack, leading to undelivered
messages or delivery over unencrypted or unauthenticated channels. messages or delivery over unencrypted or unauthenticated channels.
This document describes a reporting mechanism and format by which This document describes a reporting mechanism and format by which
sending systems can share statistics and specific information about sending systems can share statistics and specific information about
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 October 20, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 4 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 5
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 4 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 5
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 5
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Result Types . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Result Types . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Success Type . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Success Type . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Routing Failures . . . . . . . . . . . . . . . . . . 6 4.1.2. Routing Failures . . . . . . . . . . . . . . . . . . 6
4.1.3. Negotiation Failures . . . . . . . . . . . . . . . . 6 4.1.3. Negotiation Failures . . . . . . . . . . . . . . . . 6
4.1.4. Policy Failures . . . . . . . . . . . . . . . . . . . 7 4.1.4. Policy Failures . . . . . . . . . . . . . . . . . . . 7
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 7 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Appendix 1: JSON Report Schema . . . . . . . . . . . . . . . 8 8. Appendix 1: JSON Report Schema . . . . . . . . . . . . . . . 8
9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 9 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
provides interoperability for clients that do not support STARTTLS provides interoperability for 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
skipping to change at page 4, line 23 skipping to change at page 4, line 23
"_smtp_tlsrpt". For example, for the Policy Domain "example.com", "_smtp_tlsrpt". For example, for the Policy Domain "example.com",
the recipient's SMTP STS policy can be retrieved from the recipient's SMTP STS policy can be retrieved from
"_smtp_tlsrpt.example.com". "_smtp_tlsrpt.example.com".
(Future implementations may move to alternate methods of policy (Future implementations may move to alternate methods of policy
discovery or distribution. See the section _Future_ _Work_ for more discovery or distribution. See the section _Future_ _Work_ for more
discussion.) discussion.)
Policies consist of the following directives: Policies consist of the following directives:
o "v": This value MUST be equal to "TLSRPT1". o "v": This value MUST be equal to "TLSRPTv1".
o "rua": A URI specifying the endpoint to which aggregate o "rua": A URI specifying the endpoint to which aggregate
information about policy failures should be sent (see the section information about policy failures should be sent (see the section
_Reporting_ _Schema_ for more information). Two URI schemes are _Reporting_ _Schema_ for more information). Two URI schemes are
supported: "mailto" and "https". supported: "mailto" and "https".
* In the case of `https`, reports should be submitted via POST * In the case of `https`, reports should be submitted via POST
([@!RFC2818]) to the specified URI. ([@!RFC2818]) to the specified URI.
* In the case of `mailto`, reports should be submitted to the specified * In the case of `mailto`, reports should be submitted to the specified
email address. When sending failure reports via SMTP, sending MTAs email address. When sending failure reports via SMTP, sending MTAs
MUST NOT honor SMTP STS or DANE TLSA failures. MUST NOT honor SMTP STS or DANE TLSA failures.
o "ruf": Future use. (There may also be a need for enabling more o "ruf": Future use. (There may also be a need for enabling more
detailed "forensic" reporting during initial stages of a detailed "forensic" reporting during initial stages of a
deployment. To address this, the authors consider the possibility deployment. To address this, the authors consider the possibility
of an optional additional "forensic reporting mode" in which more of an optional additional "forensic reporting mode" in which more
details--such as certificate chains and MTA banners--may be details--such as certificate chains and MTA banners--may be
reported. See the section _Future_ _Work_ for more details.) reported. See the section _Future_ _Work_ for more details.)
The formal definition of the "_mta_sts" TXT record, defined using
[RFC5234], is as follows:
sts-text-record = sts-version *WSP %x3B *WSP sts-id
sts-version = "v" *WSP "=" *WSP %x54 %x4C %x53
%x52 %x50 %x54 %x76 %x31
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
3.1. Example Reporting Policy 3.1. Example Reporting Policy
3.1.1. Report using MAILTO 3.1.1. Report using MAILTO
_smtp_tlsrpt.mail.example.com. IN TXT \ _smtp_tlsrpt.mail.example.com. IN TXT \
"v=TLSRPT1;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.mail.example.com. IN TXT \ _smtp_tlsrpt.mail.example.com. IN TXT \
"v=TLSRPT1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
4. Reporting Schema 4. Reporting Schema
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 + Contact information for one or more responsible parties for
skipping to change at page 10, line 4 skipping to change at page 10, line 6
o "message-count": The number of (attempted) messages that match the o "message-count": The number of (attempted) messages that match the
relevant "result-type" for this section. relevant "result-type" for this section.
o "additional-info-uri": An optional URI pointing to additional o "additional-info-uri": An optional URI pointing to additional
information around the relevant "result-type". For example, this information around the relevant "result-type". For example, this
URI might host the complete certificate chain presented during an URI might host the complete certificate chain presented during an
attempted STARTTLS session. attempted STARTTLS session.
9. Appendix 2: Example JSON Report 9. Appendix 2: Example JSON Report
{
"organization-name": "Company-X", {
"date-range": { "organization-name": "Company-X",
"start-datetime": "2016-04-01T00:00:00Z", "date-range": {
"end-datetime": "2016-04-01T23:59:59Z" "start-datetime": "2016-04-01T00:00:00Z",
}, "end-datetime": "2016-04-01T23:59:59Z"
"contact-info": "sts-reporting@company-x.com", },
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "contact-info": "sts-reporting@company-x.com",
"policy": { "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policy-type": "sts", "policy": {
"policy-string": "TODO: Add me", "policy-type": "sts",
"policy-domain": "company-y.com", "policy-string": "TODO: Add me",
"mx-host": "*.mail.company-y.com" "policy-domain": "company-y.com",
}, "mx-host": "*.mail.company-y.com"
"report-items": [{ },
"result-type": "ExpiredCertificate", "report-items": [{
"sending-mta-ip": "98.136.216.25", "result-type": "ExpiredCertificate",
"receiving-mx-hostname": "mx1.mail.company-y.com", "sending-mta-ip": "98.136.216.25",
"message-count": 100 "receiving-mx-hostname": "mx1.mail.company-y.com",
}, { "message-count": 100
"result-type": "StarttlsNotSupported", }, {
"sending-mta-ip": "98.22.33.99", "result-type": "StarttlsNotSupported",
"receiving-mx-hostname": "mx2.mail.company-y.com", "sending-mta-ip": "98.22.33.99",
"message-count": 200, "receiving-mx-hostname": "mx2.mail.company-y.com",
"additional-information": "hxxps://reports.company-x.com/ "message-count": 200,
report_info?id=5065427c-23d3#StarttlsNotSupported" "additional-information": "hxxps://reports.company-x.com/
}] report_info?id=5065427c-23d3#StarttlsNotSupported"
} }]
}
Example JSON report for a messages from Company-X to Company-Y, where Example JSON report for a messages from Company-X to Company-Y, where
100 messages were attempted to Company Y servers with an expired 100 messages were attempted to Company Y servers with an expired
certificate and 200 messages were attempted to Company Y servers that certificate and 200 messages were attempted to Company Y servers that
did not successfully respond to the STARTTLS command. did not successfully respond to the STARTTLS command.
10. Normative References 10. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
10.17487/RFC5322, October 2008, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <http://www.rfc-editor.org/info/rfc5322>.
[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>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
 End of changes. 13 change blocks. 
45 lines changed or deleted 61 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/