Subject: [dmarc-ietf] attack on reports

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 09:24:53 -0800

This is different than yesterday. From what I can tell there is no 
identifying information of the original message like message-id in the 
report xml. If i'm wrong, please point me to it. Since the object of the 
reports is to have confidence so that I can set a p=reject policy, all 
an attacker needs to do is bombard $LARGEPROVIDER with bogus messages 
purportedly from my domain to make me not want to change over to reject 
for fear of large providers dumping legitimate email from my domain. 
This could be somewhat mitigated if you know all of the IP addresses 
that send for you domain, but that could be difficult with the use of 
outsourced email, etc and shouldn't be a requirement. Addition of the 
message-id would allow me to cross check from my logs, say, that it was 
a legitimate message from my domain or not. There may be other ways to 
solve this, but that is one.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 18:37:50 +0100

On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote:
> 
> This is different than yesterday. From what I can tell there is no identifying 
> information of the original message like message-id in the report xml. If i'm 
> wrong, please point me to it.

With a record for each message it wouldn't be an *aggregate* report.

In addition, if I recover that message from the log, I might find no 
relationship with the reporting domain or the reported source IP.  That is to 
say, I won't be able to deduce if the report is fake or real.

> Since the object of the reports is to have confidence so that I can set a
> p=reject policy, all an attacker needs to do is bombard $LARGEPROVIDER with
> bogus messages purportedly from my domain to make me not want to change over
> to reject for fear of large providers dumping legitimate email from my
> domain. This could be somewhat mitigated if you know all of the IP addresses
> outsourced email, etc and shouldn't be a requirement.

$LARGEPROVIDER must use a reputation system to evaluate both the report 
generator domain and the reported IP numbers.

> Addition of the message-id would allow me to cross check from my logs, say,
> that it was a legitimate message from my domain or not.

Not if you take forwarding into account.

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 10:00:44 -0800

On 1/26/21 9:37 AM, Alessandro Vesely wrote:
>> identifying information of the original message like message-id in 
>> the report xml. If i'm wrong, please point me to it.
>
>

 From section 7.2:

"Visibility comes in the form of daily (or more frequent) Mail 
Receiver-originated feedback reports that contain aggregate data on 
message streams relevant to the Domain Owner. This information includes 
data about messages that passed DMARC authentication as well as those 
that did not."

That sure sounds like it's on a message basis to me. How else could the 
reports get to be as big as megabytes?

> relationship with the reporting domain or the reported source IP.  
> That is to say, I won't be able to deduce if the report is fake or real.

My main point here is to point out the attack.

Mike

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Jan 2021 13:56:46 -0500

> reports get to be as big as megabytes?

I don't believe they do reach megabytes in size. I wasn't present at the
creation, but I believe that the 10MB size limit was chosen as one to allow
for more than enough headroom for aggregate reports.

Adding message-ids to aggregate reports removes the aggregation feature of
the report, and would be an undue burden both for the report generator and
the report consumer, in my opinion, mostly due to the orders of magnitude
increase in storing the data. For example, where today I can represent
50,000 messages in one row in my data store based on the aggregation of
source IP, policy_evaluated, identifier, and auth_results I would instead
require 50,000 rows to do the same if message-ids were added to the
reports. Aggregate reports aren't used to troubleshoot authentication
failures for individual messages; they're meant to convey information about
whether a sending IP is transmitting messages that generally pass or fail
SPF and DKIM checks. If a source
IP/policy_evaludated/identifier/auth_results tuple shows as failing
authentication checks a high percentage of the time, and the source IP is
known to be one used by the organization, then that mailstream can be
examined and corrected.

> My main point here is to point out the attack.
The attack scenario you have described relies on several possible but
perhaps implausible conditions all being true:

1. There exists a domain run by people who are savvy enough to want to
implement DMARC and can consume reports, but don't have a good grasp on
which IPs are likely to be theirs and which aren't, and don't have an
understanding of how to use common tools to figure out whether an IP
address might belong to their provider's ASN or one halfway around the
world, and
2. $LARGEPROVIDER is sophisticated enough to do DMARC validation and
reporting, but not so sophisticated as to notice that the bombardment of
mail generated by the criminal is different from other flows using that
domain, and so therefore won't take action to cut off its acceptance of
that flow in ways that would cause it to not be reported on (i.e., blocking
the source not because of DMARC, but because it's a known spam source, and
so the messages are never accepted nor run through DMARC validation
checks), and
3. There exists a criminal who, given the choice of squeezing through the
eye of a needle by somehow preventing a domain from reaching a p=reject
policy (which isn't always honored, anyway) using this bombardment
technique or driving a truck through the chasm of using cousin domains or
even look-alike domains that include homoglyphs that render them apparently
identical to the target domain (a problem DMARC is not designed to solve)
will choose the more difficult path.

I would think this scenario much more likely if DMARC were at this time a
purely hypothetical exercise. Given that we're years into implementation
already, I'm less confident that the above three conditions all exist at
the same time.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*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.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 11:24:39 -0800

> implement DMARC and can consume reports, but don't have a good grasp 
> on which IPs are likely to be theirs and which aren't, and don't have 
> an understanding of how to use common tools to figure out whether an 
> IP address might belong to their provider's ASN or one halfway around 
> the world, and

Here's a very basic question: if I do not know all of the IP addresses 
that send on my behalf, are DMARC reports of any value? Enterprises farm 
out email all of the time and it could be difficult to know when they 
change their server addresses, etc. If the reporting is predicated on 
your having in effect and up to date SPF record (ie, do all of the work 
to be able to produce one), then that negates anybody who just uses DKIM 
alone which should be a completely acceptable use case. And no, the 
domain/selector tells you nothing when it doesn't verify.

If it is the case that you MUST know all of your sending IP addresses, 
that should be in blinking bold right up front in section 7.

Mike

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Jan 2021 15:01:34 -0500

On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <[email-masked]> wrote:

> change their server addresses, etc. If the reporting is predicated on your
> having in effect and up to date SPF record (ie, do all of the work to be
> able to produce one), then that negates anybody who just uses DKIM alone
> which should be a completely acceptable use case. And no, the
> Yes, DMARC reports are of value if you don't know all of the IP addresses
that send on your behalf. Some have even written blog posts on the topic of
using DMARC aggregate reports as a tool to audit one's authentication
practices, by publishing a policy of p=none, collecting the reports,
analyzing the data, fixing problems, iterate, iterate, iterate until one is
ready to move on to the ultimate goal of p=reject.

In my experience, there is enough information in the DMARC aggregate
reports to allow for someone to make an educated guess as to whether an IP
that's generating mail that's not authenticating is perhaps a server
sending reports from the side of the desk of Emily in Engineering, or a
third party that Mike in Marketing contracted to send mail on the company's
behalf, or whether it's almost certainly an IP that's not one used by the
organization at all. This presumes, of course, that one at least has a clue
as to what public IP range(s) are in use by the organization, not just for
mail but for general connectivity, but with the security organization
and/or IT typically running (or at least ordering and participating in the
analysis of) the DMARC deployment, that seems a safe assumption. Having the
source IP in the aggregate report isn't necessarily just to make sure it
gets added to the SPF record, either; many times it (along with the other
information in that tuple) gives the report consumer a clue as to where to
start hunting in his infrastructure for the MTA that isn't correctly DKIM
signing mail at this time.

As to third parties changing email addresses all the time, you're correct,
they do, but they mitigate the impact on their customers by instructing
them to use the include: mechanism in their SPF records, rather than trying
to enumerate all of the vendor's IP ranges, e.g., include:_
spf.salesforce.com, include:_spf.google.com, etc.

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 12:16:54 -0800

On 1/26/21 12:01 PM, Todd Herr wrote:
> On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     The attack scenario you have described relies on several possible
>>     but perhaps implausible conditions all being true:
>>
>>     1. There exists a domain run by people who are savvy enough to
>>     want to implement DMARC and can consume reports, but don't have a
>>     good grasp on which IPs are likely to be theirs and which aren't,
>>     and don't have an understanding of how to use common tools to
>>     figure out whether an IP address might belong to their provider's
>>     ASN or one halfway around the world, and
>
>     Here's a very basic question: if I do not know all of the IP
>     addresses that send on my behalf, are DMARC reports of any value?
>     Enterprises farm out email all of the time and it could be
>     difficult to know when they change their server addresses, etc. If
>     the reporting is predicated on your having in effect and up to
>     date SPF record (ie, do all of the work to be able to produce
>     one), then that negates anybody who just uses DKIM alone which
>     should be a completely acceptable use case. And no, the
>     If it is the case that you MUST know all of your sending IP
>     addresses, that should be in blinking bold right up front in
>     section 7.
>
>
> Yes, DMARC reports are of value if you don't know all of the IP 
> addresses that send on your behalf. Some have even written blog posts 
> on the topic of using DMARC aggregate reports as a tool to audit one's 
> authentication practices, by publishing a policy of p=none, collecting 
> the reports, analyzing the data, fixing problems, iterate, iterate, 
> iterate until one is ready to move on to the ultimate goal of p=reject.
>
How do I know when I'm done though if I don't know the IP addresses who 
send on my behalf? Is it an actual forgery or is it Marsha in marketing 
using a outsourced email blaster?

The larger point is that I should not have had to come to a working 
group mailing list to find out what should be in the document in the 
first place. Along with some ascii art in 7.2, there needs to be some 
explanation of the reporting's applicability and limitations. It doesn't 
need to be tome but some informative text goes a long way to helping 
people out who we're involved with the document from the beginning.

Mike

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Jan 2021 15:29:14 -0500

> using a outsourced email blaster?

Time.

Some industry experts have suggested that one budget twelve to eighteen
months between first publishing a DMARC policy record and the hoped-for
transition to p=reject. YMMV, and a lot depends on the types of messages
that the organization sends, and their cadence. At the extreme end of more
than a year would be larger companies doing seasonal or cyclical mailings,
ones that maybe only market to certain customer segments once or twice per
year, tops. The more one knows about one's mail flows and the better one's
authentication practices before deploying DMARC, the shorter that time can
be, but a year or more isn't unusual at all.

--

---

From: Matt V <[email-masked]>
Date: Tue, 26 Jan 2021 15:41:10 -0500

> using a outsourced email blaster?

This is solved with conversation with the relevant stakeholders in the
organization from IT, Marketing, PR, etc... along with security and brand
policies being enforced.

Ultimately only approved and official email sources will be authenticated -
random sales/marketing people don't get to make those types of decisions on
the day-to-day. You want an exemption for your support/marketing tools you
need to get it cleared, vetted and properly authenticated to play.

This is how most large companies resolve this issue.

~
*MATTHEW VERNHOUT*
Founder, Editor
EmailKarma.net <http://ekma.co/16G2Htm>
It's not the size of your list, it's how you use it!

t: @emailkarma <https://twitter.com/EmailKarma>

---

From: Steven M Jones <[email-masked]>
Date: Tue, 26 Jan 2021 13:01:18 -0800

On 1/26/21 11:24, Michael Thomas wrote:
> that send on my behalf, are DMARC reports of any value?
>
No, an organization is not assumed to have perfect knowledge of all
their authorized sending sources. If that were common, there would have
been much less need for DMARC in the first place.

One of the primary goals of DMARC (IMO) is to help organizations
identify sending sources that have to be /investigated/. Some may be
vendors who were engaged outside the normal email operational processes,
most are likely just transient spam sources. But you won't know which is
which until you at least take a cursory look.

All of which requires those DMARC aggregate reports, and benefits from
failure reports if you can get them -- and that the domain owner, or
somebody acting on their behalf, *examines* those reports.

Organizations using email should have at least some policies and
procedures that cover all these things - and that is a very large topic
that this isn't the right place to explore. 

> Enterprises farm out email all of the time and it could be difficult
> to know when they change their server addresses, etc.
>
Yes, which is part of why even organizations that have gone through a
long deployment process and arrived at their desired "end state" find
value in continuing to receive and monitor reports. As you touch on,
vendors don't always tell you about such changes in advance.

You have to examine reports and, from time to time, take some action.

--S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 13:19:16 -0800

On 1/26/21 12:29 PM, Todd Herr wrote:
> On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas <[email-masked] 
>     addresses that send on your behalf. Some have even written blog
>     posts on the topic of using DMARC aggregate reports as a tool to
>     audit one's authentication practices, by publishing a policy of
>     p=none, collecting the reports, analyzing the data, fixing
>     problems, iterate, iterate, iterate until one is ready to move on
>     to the ultimate goal of p=reject.
>>
>     How do I know when I'm done though if I don't know the IP
>     addresses who send on my behalf? Is it an actual forgery or is it
>     Marsha in marketing using a outsourced email blaster?
>
>
> Time.
>
> Some industry experts have suggested that one budget twelve to 
> eighteen months between first publishing a DMARC policy record and the 
> hoped-for transition to p=reject. YMMV, and a lot depends on the types 
> of messages that the organization sends, and their cadence. At the 
> extreme end of more than a year would be larger companies doing 
> seasonal or cyclical mailings, ones that maybe only market to certain 
> customer segments once or twice per year, tops. The more one knows 
> about one's mail flows and the better one's authentication practices 
> before deploying DMARC, the shorter that time can be, but a year or 
> more isn't unusual at all.
>
I don't see how time helps anything if I can't differentiate between our 
legitimate traffic and attacker traffic. All an attacker would need to 
do is send a mail cannon to mimic Marsha in Marketing every once in a 
while and the entire thing resets. If it is a requirement to know all of 
the legitimate IP addresses in order to make use of the reports as an 
indicator, the draft should be very explicit about that.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 13:24:21 -0800

On 1/26/21 12:41 PM, Matt V wrote:
> On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas <[email-masked] 
> organization from IT, Marketing, PR, etc... along with security and 
> brand policies being enforced.
>
> Ultimately only approved and official email sources will be 
> authenticated - random sales/marketing people don't get to make those 
> types of decisions on the day-to-day. You want an exemption for your 
> support/marketing tools you need to get it cleared, vetted and 
> properly authenticated to play.
>
I worked for a large company and that is much easier said than done 
having attempted to do so before the reporting was a twinkle in 
anybody's eye. Hence the low uptake of DMARC. Having to know all of the 
IP addresses that are legitimate senders for your domain is daunting for 
a large enterprise.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 13:30:36 -0800

> been much less need for DMARC in the first place.

In order to move from p=none to p=reject it seems like you need to know 
that. One of the big advantages of DKIM is that you don't need to have 
know the network configuration of outsiders; you just add a selector for 
them. Not accommodating people who don't or can't know all of the 
legitimate IP addresses seems like a defect in the design/architecture 
of DMARC reporting, and leads to why it can be attacked in the way I 
described.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 13:38:28 -0800

[]

Ok, I think I understand this enough now to write a ticket.

Mike

---

From: Todd Herr <[email-masked]>
Date: Tue, 26 Jan 2021 16:44:00 -0500

On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas <[email-masked]> wrote:

> legitimate traffic and attacker traffic. All an attacker would need to do
> is send a mail cannon to mimic Marsha in Marketing every once in a while
> and the entire thing resets. If it is a requirement to know all of the
> legitimate IP addresses in order to make use of the reports as an
> Forgive me; I have failed to get my point across in a way that conveyed my
meaning. Let me try again.

My use of the word "Time" was intended to mean, effectively, "experience,
wisdom, and knowledge" all of which would be gained through regular (for me
it was daily) analysis of the latest DMARC aggregate reports. Through the
time spent analyzing those reports, one would obtain a fuller picture of
one's organization's mail flows, gaining a knowledge that can really only
come from immersion in the data.

Once one gets past the first few weeks of the exercise, picking off any
low-hanging fruit, then one settles into a posture of monitoring for
anomalies, expecting to see no failures, and quickly addressing those that
need to be addressed.

At some point, one that is wholly dependent on the complexity of the
infrastructure and the personality of the observer, one becomes comfortable
enough with the data to confidently say, "Now is the time to move to
p=reject" and one makes the move.

After that, there's continued monitoring to make sure that no ill effects
have occurred due to the move, of course, and if there's need to roll back,
one rolls back.

If you're looking for an objective standard by which one can say "If X,
then it is safe to move to p=reject", there really isn't one, save for "If
the domain is newly registered and has never sent mail, then it is safe to
move to p=reject." For any domain that has sent mail prior to the
publishing of a DMARC record, then it's publish, monitor, iterate until one
is ready, and the only standard for that is "When you know, you know."

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Jan 2021 14:15:06 -0800

On 1/26/21 1:44 PM, Todd Herr wrote:
> On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas <[email-masked] 
>     I don't see how time helps anything if I can't differentiate
>     between our legitimate traffic and attacker traffic. All an
>     attacker would need to do is send a mail cannon to mimic Marsha in
>     Marketing every once in a while and the entire thing resets. If it
>     is a requirement to know all of the legitimate IP addresses in
>     order to make use of the reports as an indicator, the draft should
>     be very explicit about that.
>
>
> Forgive me; I have failed to get my point across in a way that 
> conveyed my meaning. Let me try again.
>
> My use of the word "Time" was intended to mean, effectively, 
> "experience, wisdom, and knowledge" all of which would be gained 
> through regular (for me it was daily) analysis of the latest DMARC 
> aggregate reports. Through the time spent analyzing those reports, one 
> would obtain a fuller picture of one's organization's mail flows, 
> gaining a knowledge that can really only come from immersion in the data.
>
>
I have written this up and it is now issue #101.

Mike