Last Call Review of draft-ietf-uta-smtp-tlsrpt-17
review-ietf-uta-smtp-tlsrpt-17-genart-lc-halpern-2018-03-08-00

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document: draft-ietf-uta-smtp-tlsrpt-17
Reviewer: Joel Halpern
Review Date: 2018-03-08
IETF LC End Date: 2018-04-02
IESG Telechat date: Not scheduled for a telechat

Summary: This document is close to ready for publication as a Proposed Standard
RFC.

Major issues:
    Given that the format of the txt record allows for multiple URIs, the ntext
    needs to specify what the reader of the record is supposed to do when there
    are multiple (using the same or different formats).  I presume the intent
    is that the reader may use any of the URIs, and only needs to use 1.  But
    it needs to say so.

    The field names in section 4.2.1 do not match the field names in the schema
    "summary" section in 4.4.

    Reading the details of the "failed-session-count" in the "failure details"
    section in section 4.4, I infer that the intention is that "failure
    details" is to be repeated for each different kind of failure.  That is a
    sensible approach.  I can not find where the text actually states that to
    be the approach.  (yes, it is represented in the example.)

Minor issues:
    The introductory text on the relationship between StartTLS and
    Opportunistic Security is confusing.  Niether the term nor the RFC existed
    when Starttls was defined.  Maybe instead of  "The protocol design is based
    on "Opportunistic Security"..." it could read "The protocol design uses an
    approach that has come to be known as "Opportunistic Security"..."?

    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?

    The reference in section 4.2.1 on treating the success count as a heartbeat
    suggests that the intention that these reports are to be filed even when
    everything has worked right all day.  If that is the intention, it should
    be stated explicitly.  If that is not the intent, then the reference to
    heartbeat in 4.2.1 should be removed.

    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:
    I presume that the use of DNS text records to convey policy has been
    reviewed and approved by the DNS Directorate.