Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

[Todd Herr <[e-mail]>]

On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas <[e-mail]> 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:* [e-mail]
*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.