Reviewer: Joel Halpern Review result: Almost 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 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.
