On 2017-08-01 20:21, Daniel Margolis wrote:
> Hey, Jim. Few points:
Jim - if you can suggest text on any of your non-nit issues that might
make it easier to zero in on a final version of this.
Cheers Leif
>
> On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy
> be found?
>
>
> Heh. It's a good point. But a sender can of course choose not to
> validate DNSSEC for the destination domain when looking up the TLSRPT
> record (and potentially MX records used for TLSRPT delivery). It seems
> unlikely to be the common case--misconfiguring your DS record or signing
> keys (as opposed to your TLSA records) is quite likely to result in mail
> never being delivered because MX records effectively fail to
> resolve--but it's hypothetically possible for a sender to still send
> TLSRPT reports from a client whose resolver does not validate, and we
> leave that possibility open by having this error type.
>
>
> 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's certainly possible that merely running a mail service opens you up
> to a DoS. But TLSRPT with mailto: endpoints doesn't (I would contend)
> exacerbate the risk, in that we assume anyone running a mailto: endpoint
> for TLSRPT is probably already running a mail service. The point of that
> paragraph is really to explain why DMARC's misdirected-reports attack
> doesn't apply; without that attack, the only concern is the generic case
> of "you're running a mail server and might get unwanted mail." Which is
> true, but isn't new attack surface induced by TLSRPT.
>
>
>
> 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.
>
>
> I think your point is that while it may make sense to send daily
> reports, they should not necessarily be /synchronized/--i.e. the mail
> covering the period 00:00 - 24:00 should not be sent at 24:00. That's a
> fair point and maybe worth being called out, I agree.
>
>
>
> 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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/uta
> <https://www.ietf.org/mailman/listinfo/uta>
>
>
>
>
> _______________________________________________
> Uta mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/uta
>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
