draft-ietf-uta-smtp-tlsrpt-02.txt   draft-ietf-uta-smtp-tlsrpt-03.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: June 18, 2017 Comcast, Inc Expires: August 19, 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
December 15, 2016 February 15, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-02 draft-ietf-uta-smtp-tlsrpt-03
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 June 18, 2017. This Internet-Draft will expire on August 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 35 skipping to change at page 4, line 35
o The Domain-based Message Authentication, Reporting, and o The Domain-based Message Authentication, Reporting, and
Conformance (DMARC) [RFC7489] contains an XML-based reporting Conformance (DMARC) [RFC7489] contains an XML-based reporting
format for aggregate and detailed email delivery errors. format for aggregate and detailed email delivery errors.
3. Reporting Policy 3. Reporting Policy
A domain publishes a record to its DNS indicating that it wishes to A domain publishes a record to its DNS indicating that it wishes to
receive reports. These SMTP TLSRPT policies are distributed via DNS receive reports. These SMTP TLSRPT policies are distributed via DNS
from the Policy Domain's zone, as TXT records (similar to DMARC from the Policy Domain's zone, as TXT records (similar to DMARC
policies) under the name "_smtp-tlsrpt". For example, for the Policy policies) under the name "smtp-tlsrpt". For example, for the Policy
Domain "example.com", the recipient's TLSRPT policy can be retrieved Domain "example.com", the recipient's TLSRPT policy can be retrieved
from "_smtp-tlsrpt.example.com". from "smtp-tlsrpt.example.com".
Policies consist of the following directives: Policies consist of the following directives:
o "v": This value MUST be equal to "TLSRPTv1". 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".
skipping to change at page 5, line 14 skipping to change at page 5, line 14
SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA
failures. 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.) reported.)
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 %x3B tlsrpt-rua tlsrpt-record = tlsrpt-version *WSP %x3B tlsrpt-rua
tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53 tlsrpt-version = "v" *WSP "=" *WSP %x54 %x4C %x53
%x52 %x50 %x54 %x76 %x31 %x52 %x50 %x54 %x76 %x31
tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri tlsrpt-rua = "rua" *WSP "=" *WSP tlsrpt-uri
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
If multiple TXT records for "_smtp-tlsrpt" are returned by the If multiple TXT records for "smtp-tlsrpt" are returned by the
resolver, records which do not begin with "v=TLSRPTv1;" are resolver, records which do not begin with "v=TLSRPTv1;" are
discarded. If the number of resulting records is not one, senders discarded. If the number of resulting records is not one, senders
MUST assume the recipient domain does not implement TLSRPT. MUST assume the recipient domain does not implement TLSRPT.
3.1. Example Reporting Policy 3.1. Example Reporting Policy
3.1.1. Report using MAILTO 3.1.1. Report using MAILTO
_smtp-tlsrpt.example.com. IN TXT \ smtp-tlsrpt.example.com. IN TXT \
"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 JSON
format ([RFC7159]). format ([RFC7159]).
Aggregate reports contain the following fields: Aggregate reports contain the following fields:
skipping to change at page 12, line 11 skipping to change at page 12, line 11
DMARC [RFC7489] defines an elegant solution for verifying DMARC [RFC7489] defines an elegant solution for verifying
delegation; however, since the attacker had less ability to delegation; however, since the attacker had less ability to
generate large reports than with DMARC failures, and since the generate large reports than with DMARC failures, and since the
reports are generated by the sending MTA, such a delegation reports are generated by the sending MTA, such a delegation
mechanism is left for a future version of this specification. mechanism is left for a future version of this specification.
8. Appendix 1: Example Reporting Policy 8. Appendix 1: Example Reporting Policy
8.1. Report using MAILTO 8.1. Report using MAILTO
_smtp-tlsrpt.mail.example.com. IN TXT \ smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
8.2. Report using HTTPS 8.2. Report using HTTPS
_smtp-tlsrpt.mail.example.com. IN TXT \ smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
9. Appendix 2: JSON Report Schema 9. Appendix 2: 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": {
 End of changes. 13 change blocks. 
13 lines changed or deleted 13 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/