Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-19.txt

From: [email-masked]
Date: Wed, 02 May 2018 09:54:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : SMTP TLS Reporting
        Authors         : Daniel Margolis
                          Alexander Brotman
                          Binu Ramakrishnan
                          Janet Jones
                          Mark Risher
	Filename        : draft-ietf-uta-smtp-tlsrpt-19.txt
	Pages           : 29
	Date            : 2018-05-02

Abstract:
   A number of protocols exist for establishing encrypted channels
   between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
   MTA-STS.  These protocols can fail due to misconfiguration or active
   attack, leading to undelivered messages or delivery over unencrypted
   or unauthenticated channels.  This document describes a reporting
   mechanism and format by which sending systems can share statistics
   and specific information about potential failures with recipient
   domains.  Recipient domains can then use this information to both
   detect potential attacks and diagnose unintentional
   misconfigurations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-19
https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-19

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 May 2018 14:04:35 -0400

> On May 2, 2018, at 12:54 PM, [email-masked] wrote:
> 

Two observations triggered by reading the diff:

1.1 Terminology:

The definition of MTA-STS describes the MTA promising STARTTLS,
specifying the valid presented identities, ..., but the DANE
definition just mentions "constraints", which is neither comparably
complete nor correct:

OLD: [compare with MTA-STS policy]

   o  DANE Policy: A mechanism by which administrators can specify
      constraints to be used to validate certificates presented by an
      MTA.  DANE is defined in [RFC6698] and [RFC7672].

NEW:

   o  DANE Policy: A mechanism by which administrators can use DNSSEC
      to commit an MTA to support STARTTLS and to publish criteria to
      be used to validate its presented certificates.  DANE for SMTP
      is defined in [RFC7672], with the base specification in [RFC6698]
      (updated in [RFC7671].

The definition of "Policy Domain" is not complete, it is *not* always
the envelope recipient domain.  Indeed for MTA-STS it may be a "smarthost"
gateway en-route to the destination domain.  And for DANE the policy
domain is the "TLSA base domain" associated with the remote SMTP server.
Typically this is the hostname of the receiving SMTP server, or its
full CNAME expansion as described in RFC7672.

OLD:

   o  Policy Domain: The domain against which an MTA-STS or DANE Policy
      is defined.  This should be the same as the recipient envelope
      domain [RFC5321], such as if the message were going to
      "[email-masked]', the policy domain would be "example.com".

NEW:

   o  Policy Domain: The domain against which an MTA-STS or DANE Policy
      is defined.  For MTA-STS this is typically the same as the envelope
      recipient domain [RFC5321], but when mail is routed to a "smarthost"
      gateway by local policy, the "smarthost" domain name is used instead.
      For DANE the Policy Domain is the "TLSA base domain" of the receiving
      SMTP server as described in [RFC7672] (Section 2.2.3) and [RFC6698]
      (Section 3).

The text in Section does not make it clear to what name the prefix "_smtp._tls"
should be prepended.  I think this would be the "Policy Domain" above.  This
should be explicit.  With DANE since policy is per-MX-host and different
parties may operate different MX hosts, it is natural to align the reporting
address with the operator's domain (by looking under the TLSA base domain
for both "_25._tcp" TLSA records and "_smtp._tls" report policy).

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 2 May 2018 19:56:45 +0100

I would like to suggest the following replacement for the Section 6.2 
(Report Type):

OLD:
    This document registers a new parameter "report-type="tlsrpt"" under
    "multipart/report" top-level media type for use with [RFC6522].

    The media type suitable for use as a report-type is defined in the
    following section.

NEW:

    This document creates a new registry for "report-type" parameter to
    Content-Type header field for "multipart/report" top-level media 
type defined in [RFC6522].
    This registry should contain "report-type" parameter value, list of 
corresponding Media Types for

    document defining it and an optional comment. Registration procedure
    for this should be "Specification Required".

    The registry is to be populated with the following entries:

      "tlsrpt", application/tlsrpt+gzip and application/tlsrpt+json, 
[RFCXXXX]

      "disposition-notification", message/disposition-notification, RFC 8098

      "disposition-notification", 
message/global-disposition-notification, RFC 6533

      "delivery-status", message/delivery-status, RFC 1894

      "delivery-status", message/global-delivery-status, RFC 6533

    Media types suitable for use with a report-type="tlsrpt" are defined 
in Sections 6.4 and 6.5.

Does this look reasonable to people?

Thank you,
Alexey

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 13:45:35 -0400

> On May 10, 2018, at 11:09 AM, Brotman, Alexander <[email-masked]> wrote:
> 
>> "The text in Section does not make it clear to what name the prefix "_smtp._tls"
>> should be prepended.  I think this would be the "Policy Domain" above.  This should be explicit.  With DANE since policy is per-MX-host and different parties may operate different MX hosts, it is natural to align the reporting address with the operator's domain (by looking under the TLSA base domain for both "_25._tcp" TLSA records and "_smtp._tls" report policy)."
> 
> Which section were you referring to here?  We have bit in the "Reporting Policy" section that I think covers this.

Never mind, I think the text on that is OK, provided that the "Policy Domain"
definition is resolved.

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 10 May 2018 17:55:30 +0000

Yes, I've already made those adjustments.  Thanks for the comments.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Thursday, May 10, 2018 1:46 PM
To: [email-masked]
Subject: Re: [Uta] [EXTERNAL] Re: I-D Action: draft-ietf-uta-smtp-tlsrpt-19.txt

-- 
	Viktor.

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta