Subject: [Uta] Genart telechat review of draft-ietf-uta-smtp-tlsrpt-18

From: Joel Halpern <[email-masked]>
Date: Thu, 05 Apr 2018 06:50:07 -0700

Reviewer: Joel Halpern
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-uta-smtp-tlsrpt-18
Reviewer: Joel Halpern
Review Date: 2018-04-05
IETF LC End Date: 2018-04-02
IESG Telechat date: 2018-04-19

Summary: This document is ready for publication as a Proposed Standard RFC
    My thanks to the authors for addressing my major concerns and most of my
    minor concerns.

Major issues:

Minor issues:
     There are several areas where the document would be helped by better
     explanations.  From my previous review:

    Section 3, bullet 3, says that submitters using POST can ignore certificate
    validation errors when using https.  That seems to undermine the usage of
    https.  As such, I would expect to at least see some explanation of when
    and why ignoring such errors is appropriate.

    It is surprising in Section 3 Bullet 4 that reporting via email requires
    that the report submitted use DKIM.  Particularly while ignoring any
    security errors in communicating with the recipient domain.

    In the formal definition of the txt record, shouldn't the URI format also
    indicate that semicolon needs to be encoded?

    Section 5.1 defines a report filename.  This is probably a naive question,
    but what is that for?  If using HTTPS, the earlier text says that the POST
    operation goes to the target URI from the txt record.  When using email,
    there is no apparent need for a filename.

    Most of the security risks described in the Security section (7) do not
    seem to have any mitigation.  Should there not be some explanation why
    deployment is acceptable with these risks?

Nits/editorial comments:

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 15:25:48 +0000

>     and why ignoring such errors is appropriate.
This is sort of obliquely (but not explicitly) addressed in Security
Considerations in the context of "report snooping." I would suggest (and am
happy to add, if the other authors are OK with it) text to the effect that
report snooping can be conducted via a bogus TLSRPT record but also by
injecting a bogus response for resolving the reporting URI or otherwise
MITM'ing the report. Because an attacker capable of these attacks can
likely, similarly, inject themselves directly into the SMTP exchange (by
injecting a bogus MX record or otherwise MITM'ing that exchange
themselves), we don't believe this substantially increases attack surface.
Exceptions are when the report URI points to a host in a different zone
than the MX host or in some other matter is MITM'able in a way that the MX
host itself is not. Hence, in the common case, MITM'ing the *report* should
present no significant additional attack surface from MITM'ing the *MX*,
and thus requiring certificate validation (which may interfere with the
delivery of reports) would be counterproductive (though we leave it up to
reporters to determine if they wish to enforce validation).

Does that make sense?

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Apr 2018 21:41:41 -0400

Joel, thanks for your review. From the thread about Ben’s DISCUSS it looks like text to clarify the point about ignoring certificate validation errors may be forthcoming. I have noted this in my No Objection ballot and asked the authors to review your other points.

Alissa

> On Apr 5, 2018, at 9:50 AM, Joel Halpern <[email-masked]> wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art