Subject: [Uta] Ben Campbell's Yes on draft-ietf-uta-smtp-tlsrpt-18: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Apr 2018 02:35:29 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-uta-smtp-tlsrpt-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[Thank you for responding to my DISCUSS points via email. I have cleared, but I
do how to see more explicit discussion in the security considerations.]

Substantive:

§1.1: There are at least a few lower case instances of 2119 keywords. Please
consider using the boilerplate from RFC 8174 instead of 2119.

§5.3, first paragraph: The paragraph claims that this document defines
"multipart/report". In fact, it does not.

§5.4, 2nd paragraph: " A reporting entity HOULD expect a "successful" response
from the accepting HTTPS server...": I'm not sure how to interpret a normative
requirement to expect success. What is the real intent here?

Editorial and Nits:

§1, paragraph 1, 2nd sentence: The sentence is convoluted. Can it be broken
into multiple simpler sentences?

§1.1, Policy Domain: The definition is partially circular. Please define what
is meant by "domain". I assume that means domain in the DNS sense, but the word
"domain" is commonly uses in other senses as well. Please be explicit.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 Apr 2018 10:41:49 -0400

> On Apr 19, 2018, at 5:35 AM, Ben Campbell <[email-masked]> wrote:
> 

Thanks, this is a good catch!  The policy domain does need a clear definition.

While it is the domain for which either a DANE or STS policy mandates secure
TLS delivery, and will be a DNS domain, a more precise definition is probably
helpful. 

In the case of STS it is usually the envelope recipient domain, but
may be the domain name of an explicitly configured "next-hop" gateway for email
delivery to the envelope recipient.

In the case of DANE, security policy is specified for each "MX Host'
separately, with the TLSA records obtained via the "TLSA base domain"
for that host.  And yet, it is *perhaps* not the intention here to
publish the reporting address separately for each MX host.  It is
more "economical" to publish it just once for the envelope recipient
domain or override next-domain just as with STS.

On the other hand, when email is hosted by a third-party,
obtaining the reporting address for the MX host is more
likely to get the report to the responsible party.

With either DANE or STS the most likely reason for policy
failure is operator error, and so there's some appeal to
notifying the the MX host provider (if "_smtp-tlsrpt.<mx-host>"
is found).  Perhaps with the envelope recipient domain or
locally configured next-hop domain as a fallback policy domain.

If, however, the failure results from a botched MiTM, with the
MX RRset modified by the attacker, then one would perhaps want
to notify the (email) destination domain, not the operators of
the fake MX host.  With DANE, the MX RRset is more likely to
be DNSSEC-validated, and so tamper-evident, but DANE may also
be apply to the DNSSEC-signed MX hosts of an "insecure" (unsigned)
domain.

Thus, I must admit to have overlooked some of the subtlety
involved in figuring out which "example.com" is the right
input to "_smtp-tlsrpt.example.com".  Don't know whether
the authors have thought this through more thoroughly.

It is likely that the present intent is to use the same
location for both DANE and STS, and for that to be
the envelope recipient domain or configured next-hop
if set, but I'd guess that use of the MX host domain as
a primary (or fallback) base for the "_smtp-tlsrpt" lookup
likely has not been considered.

-- 
	Viktor.