Skip to main content

Telechat Review of draft-ietf-uta-smtp-tlsrpt-18

Request Review of draft-ietf-uta-smtp-tlsrpt
Requested revision No specific revision (document currently at 23)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-04-17
Requested 2018-03-12
Authors Daniel Margolis , Alex Brotman , Binu Ramakrishnan , Janet Jones , Mark Risher
Draft last updated 2018-04-05
Completed reviews Secdir Last Call review of -17 by Phillip Hallam-Baker (diff)
Genart Last Call review of -17 by Joel M. Halpern (diff)
Genart Telechat review of -18 by Joel M. Halpern (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Review review-ietf-uta-smtp-tlsrpt-18-genart-telechat-halpern-2018-04-05
Reviewed revision 18 (document currently at 23)
Result Ready
Completed 2018-04-05
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


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: