In response to Leif's request for specific text for the larger issues: On 7/31/17 4:02 PM, Jim Fenton wrote: > > 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.
I agree that the MTA-STS reference is informative. By my reading, the following RFC references are also informative: 3207, 3501, 3864, 7435, 7469, 7489 But check me on those... > > 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 3, third bullet: o In the case of "https", reports SHOULD be submitted via POST ([RFC2818]) to the specified URI. Report submitters MAY ignore certificate verification errors when submitting reports via https. > > Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy > be found? Maybe just note this situation; add the following text to this bullet: Note that DNSSEC failures are likely to also affect the retrieval of the TLSRPT record, so reports with this failure are likely to be rare in practice. > > 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. I suggest eliminating this requirement. > > 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., repo...@example.org or reports+clie...@example.org for > a service provider) in order to distinguish reports from other traffic. I suggest eliminating this requirement. > > 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. 6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry This document registers a new DNS name in the "DNS Global Underscore Scoped Entry Registry" as follows: Scoped Entry: _smtp-tlsrpt Applicable protocol: SMTP Status: standard Author/Change controller: IETF Specification document(s): This document Note that this registry is created by the publication of draft-ietf-dnsop-attrleaf. If this document precedes it in publication, the entry is requested to be included in the registry at its creation. > > 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 4.1: The report SHOULD cover a full day (24 hours). In order to avoid congestion caused by synchronized transmission and receipt of reports, report senders SHOULD choose an arbitrary time to send their reports, either individually or as a group. The transmission time MAY be determined, for example, by hashing the reporting domain name, taking the result modulo 1440, and sending reports at that many minutes past midnight UTC each day. In Section 7: (original text is OK here too if you prefer, but suggest including the "More broadly" sentence) Reports as DDoS: TLSRPT allows specifying destinations for reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls a Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. More broadly, the publication of a reporting email address or URI presents the opportunity for the addresses to be harvested and used as the target of a DoS or DDoS attack. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks, which is an effective countermeasure for innocent third-party senders of reports, but TLSRPT has less need for a verification mechanism because it would require the attacker to induce the innocent third party to send mail to the attacker. > > 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? Add to Section 7: Deceptive reports: TLSRPT supports the processing of reports from arbitrary sources. As such, the data in the reports may be incorrect or even intentionally deceptive. Report recipients need to be aware of and prepared to handle this situation. Add to bullet 4 of Section 3: Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. (add normative reference to RFC6376) (note that we still have a problem authenticating https reports, unless client-authenticated TLS is required, which would be an onerous requirement). _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
