On 7/12/17 3:11 AM, Leif Johansson wrote: > This starts a 3 week working group last call (WGLC) on > draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list > by Wednesday > August 2nd. General comments:
All of the references are listed as normative, which I strongly suspect isn't really the case. Informative references need to be separated. As the document notes, the reference for MTA-STS needs to be added. If it is a normative reference, this document will be held up until that is published. Section 3, what happens in the case of HTTPS delivery of reports if there is some problem with the certificate presented by the server? For mailto:, it explicitly states that the message should be sent in the clear if necessary, but that doesn't seem to be the case with https:. Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy be found? Section 5.1, I don't like the idea of associating semantics with the filename of MIME parts. As it's written, use of the specified filename format is optional, so the recipient can't depend on it anyway. DMARC does this, and I didn't like it there either, but it's an informational document so this may not have gotten all the scrutiny this should as a standards-track document. Section 5.3, I don't think it's a good idea to define and require new message header fields for this. This means that some of the general-purpose libraries for sending email messages can't be used. A better approach IMO would be to suggest the use of separate email addresses (e.g., [email protected] or [email protected] for a service provider) in order to distinguish reports from other traffic. IANA considerations: Consider adding a request to register _smtp-tlsrpt in the registry being created by draft-ietf-dnsop-attrleaf if that registry is created before this is published. Section 7, Reports as DDoS: The discussion revolves around the fact that, unlike DMARC, there isn't a third party involved in a DMARC report so it isn't necessary to validate delegation. I'm not sure this completely alleviates the DDoS risk, though: it's equally possible for malicious second parties to overload the receiver with reports, or for malicious parties to look around for TLSRPT policies with mailto: addresses and just spam them. It might be good to acknowledge that possibility here. Also, the suggestion of sending the messages daily for 0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in itself. Section 7, additional consideration: The "untrusted content" consideration talks about malicious code, but attackers could also send counterfeit reports that look real in an effort to confuse the report recipient. Should valid DKIM signatures from the reporting domain be required on TLSRPT messages? Detailed comments and nits: 1.1 last bullet: initiating the delivery -> initiating the transmission 3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986] What is the "numeric portion" that is referred to here? 4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neither a DANE nor MTA-STS policy" 5.1 "The filename is typically constructed": Is that a MAY? SHOULD? DMARC uses this wording, but it's informational. Following the ABNF, "json.gz": The IANA considerations section lists this is .gz. And the MUST here is confusing, is this only if the filename is 'typically constructed' or always? 5.3 The [RFC5322].Subject field for individual report submissions: There isn't an "individual" report defined here. Looks like this is left over from DMARC. 5.4 should use the media type -> SHOULD use the media type 5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale (do MTAs typically do this, or is it calling for something special?) Sections 8 and 9 should be renumbered as appendices, and marked as informative examples. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
