Re: [Gen-art] Genart telechat review of draft-ietf-uta-smtp-tlsrpt-18

[Daniel Margolis <[e-mail]>]

On Thu, Apr 5, 2018 at 3:50 PM Joel Halpern <[e-mail]> wrote:

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


>     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:
>
>
>