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

From: Ben Campbell <[email-masked]>
Date: Sun, 15 Apr 2018 21:10:04 -0700

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

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I plan to ballot "Yes" for this, but there is an issue I think needs discussion
first. Hopefully this will be easy to address:

§3 says "Report submitters MAY ignore certificate validation errors when
submitting reports via https." Yet the security considerations mention how an
attacker than can subvert SMTP security might also be able to subvert the
TLSRTP TXT records. It seems like one potential result of that could be to
redirect the reports to a hostile destination, or at least away from the
intended destination. Ignoring certificate validation errors  removes a check
against that sort of thing.

I'm sure there are good reasons to allow that; I can even guess at a few. But I
think allowing that sort of behavior needs explicit motivation, and I failed to
find text that did that.

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

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: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 15:45:50 +0000

Hey. Thanks for the feedback.

> think allowing that sort of behavior needs explicit motivation, and I

I sent a somewhat related comment to the list a few minutes ago. tl;dr:

* The risks we may consider if this introduces are a) information leakage
(receiving someone else's reports) and b) *preventing* discovering of
malicious interception.
* The benefit this introduces is increasing the chance of discovering
benign misconfiguration (which is likely, I posit, to coincide with
validation errors in TLSRPT reporting).

The second point, I trust, is fairly clear. For the first point, I believe
these two risks are *mostly* spurious.

a) In most cases (though not all; imagine the case of a reporting URI whose
host is in a different--say, non-DNSSEC-secured--zone than the delivery
domain), an attacker who can intercept the reports can probably also
intercept the mail (or at least the initial SMTP EHLO) itself, and so can
already glean some of the metadata visible in the report.
b) An attacker who can inject a spurious reporting URI or otherwise
intercept reports doesn't need to handle them properly (with valid HTTPS),
but can simply inject NXDOMAIN for the TLSRPT record.

As such, I believe the risks are very limited and the benefits (in the
benign misconfiguration case) large.

I'm not opposed to expanding on Security Considerations with more text like
the above. (The ideas above are somewhat obliquely referenced already, I
think, but not directly so.)

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 18 Apr 2018 18:52:56 +0000

For the DISCUSS section:

We did note that the reports could be made to be submitted elsewhere via hijacked DNS, as you've noted.  I don't believe that an expired or self-signed certificate from the HTTPS endpoint should be a reason to stop the submission, so we can leave it to the submitter.  Another possible problem would be that the receiving site uses a CA that the submitter doesn't trust for some reason.  While I agree with the notion that an attacker could alter the DNS response to force the reports to go elsewhere, I don't think they'd be able to do it for all submissions without the receiving site noticing (unless they're not paying any attention to reports at all).   We discussed this as a group when we first started, and I vaguely recall that to be the consensus.  If you'd like us to explicitly note this in the Security Considerations, we can do that.

We'll work on cleaning up the COMMENT portions.  They all seem reasonable.

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

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Monday, April 16, 2018 12:10 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Leif Johansson <[email-masked]>
Subject: [Uta] Ben Campbell's Discuss on draft-ietf-uta-smtp-tlsrpt-18: (with DISCUSS and COMMENT)

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.)

I plan to ballot "Yes" for this, but there is an issue I think needs discussion first. Hopefully this will be easy to address:

§3 says "Report submitters MAY ignore certificate validation errors when submitting reports via https." Yet the security considerations mention how an attacker than can subvert SMTP security might also be able to subvert the TLSRTP TXT records. It seems like one potential result of that could be to redirect the reports to a hostile destination, or at least away from the intended destination. Ignoring certificate validation errors  removes a check against that sort of thing.

I'm sure there are good reasons to allow that; I can even guess at a few. But I think allowing that sort of behavior needs explicit motivation, and I failed to find text that did that.

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.

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