Thx! Skickat från min iPhone
> 3 aug. 2017 kl. 23:11 skrev Jim Fenton <[email protected]>: > > 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., [email protected] or [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
