Hey. Thanks for the feedback. On Mon, Apr 16, 2018 at 6:10 AM Ben Campbell <[email protected]> wrote:
> > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I plan to ballot "Yes" for this, but there is an issue I think needs > discussion > first. Hopefully this will be easy to address: > > §3 says "Report submitters MAY ignore certificate validation errors when > submitting reports via https." Yet the security considerations mention how > an > attacker than can subvert SMTP security might also be able to subvert the > TLSRTP TXT records. It seems like one potential result of that could be to > redirect the reports to a hostile destination, or at least away from the > intended destination. Ignoring certificate validation errors removes a > check > against that sort of thing. > I'm sure there are good reasons to allow that; I can even guess at a few. > But I > think allowing that sort of behavior needs explicit motivation, and I > failed to > find text that did that. > I sent a somewhat related comment to the list a few minutes ago. tl;dr: * The risks we may consider if this introduces are a) information leakage (receiving someone else's reports) and b) *preventing* discovering of malicious interception. * The benefit this introduces is increasing the chance of discovering benign misconfiguration (which is likely, I posit, to coincide with validation errors in TLSRPT reporting). The second point, I trust, is fairly clear. For the first point, I believe these two risks are *mostly* spurious. a) In most cases (though not all; imagine the case of a reporting URI whose host is in a different--say, non-DNSSEC-secured--zone than the delivery domain), an attacker who can intercept the reports can probably also intercept the mail (or at least the initial SMTP EHLO) itself, and so can already glean some of the metadata visible in the report. b) An attacker who can inject a spurious reporting URI or otherwise intercept reports doesn't need to handle them properly (with valid HTTPS), but can simply inject NXDOMAIN for the TLSRPT record. As such, I believe the risks are very limited and the benefits (in the benign misconfiguration case) large. I'm not opposed to expanding on Security Considerations with more text like the above. (The ideas above are somewhat obliquely referenced already, I think, but not directly so.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > §1.1: There are at least a few lower case instances of 2119 keywords.. > Please > consider using the boilerplate from RFC 8174 instead of 2119. > > §5.3, first paragraph: The paragraph claims that this document defines > "multipart/report". In fact, it does not. > > §5.4, 2nd paragraph: " A reporting entity HOULD expect a "successful" > response > from the accepting HTTPS server...": I'm not sure how to interpret a > normative > requirement to expect success. What is the real intent here? > > Editorial and Nits: > > §1, paragraph 1, 2nd sentence: The sentence is convoluted. Can it be broken > into multiple simpler sentences? > > §1.1, Policy Domain: The definition is partially circular. Please define > what > is meant by "domain". I assume that means domain in the DNS sense, but the > word > "domain" is commonly uses in other senses as well. Please be explicit. > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
