On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas <m...@mtcc.com> wrote:
> > On 1/24/21 6:29 PM, John R. Levine wrote: > > I realized why the arguments about whether to require authentication > > on reports are pointless. > > > A blatant assertion. The onus of proof is with people who say we should > accept information from unknown sources. Extraordinary claims require > extraordinary evidence. I have been doing security related stuff for > long enough to know that being humble in the face of adversaries is the > most prudent course. State actors can get involved when they figure they > can game things to their advantage. To be dismissive is complete hubris. > > I've spent several days thinking about these tickets, and for the life of me I can't see what the payoff might be for someone to forge a DMARC report. I suppose nominally there's a denial of service risk, where a bad actor could flood a rua or ruf mailbox with forged reports or just email in general, but that's going to exist whether or not the "reports" are DKIM-signed. My first question for aggregate reports would focus on the DKIM signing domain - Should it align with the RFC5322.From domain that sent the report, or with the org_name or email fields in the report_metadata bits in the XML itself? John has demonstrated that there's no alignment now in many cases between the domain generating reports and the domain(s) about which the reports are generated. You almost have to require that the signing domain align with the RFC5322.From domain, because DKIM validation is likely to be done by different infrastructure than does the report processing (see below) and the DKIM validation layer isn't likely to be able to read the reports, while the report processing layer may be a simple tool that doesn't care to do DKIM validation. About that, aggregate reports are meant to be machine-parsed, and in my own experience that's accomplished by running a cron job a couple times a day to process the rua mailbox. (Personally, I favored Mark Overmeer's perl stuff; open the mailbox, cycle through each message, strip off the attachment, unzip it, and pass it to the tools that John wrote to read the XML and store the results in a database, but I was working at a relatively small site.) If the message isn't crafted specifically to match the format mandated in the DMARC spec, it's not going to get processed; if the bad actor takes the time to properly format an aggregate report and forge it to appear to be from a given entity, what does the bad actor gain? If the report contains data showing illegitimate mail that's not authenticating, the target yawns. Best case for the bad guy, his report appears to contain legit data showing that the target is sending email that isn't passing authentication checks, and it causes someone at the target to try to chase down a mailflow that isn't really there. And then what? The bad actor could keep being a nuisance, but I suspect eventually he'd get bored, because he's not going to have any visibility into the results of his actions. As for forging failure reports, again what's in it for the actor doing the forging? If the faked failure report is crafted to appear to contain actionable data (something that's rare these days), the most likely responses to that are one of the following: - In the case of the failure report appearing to show a message that forges domain A's identity and originated from a network run by B, maybe it fosters ill will between A and B's abuse desk, with A providing evidence of forged mail being emitted by B and asking B to take action, and B saying "not our problem" - In the case of the failure report appearing to show an unauthenticated message sent by A, again it's another case of someone at A trying to chase down and fix a phantom mail flow. Unless our bad guy is playing a long game that I can't conceive of (and my imagination can be limited) then I don't see that there's any money in it for the bad guy, so I don't see why he'd bother to forge reports. What threats do you have in mind, Michael? -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
