Re: [dmarc-ietf] attack on reports

[Todd Herr <[e-mail]>]

On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas <[e-mail]> wrote:

>
> On 1/26/21 12:01 PM, Todd Herr wrote:
>
> On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <[e-mail]> wrote:
>
>>
>> On 1/26/21 10:56 AM, Todd Herr wrote:
>>
>>> > 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.
>>>
>>>
>>> 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
>>
>> 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.
>>
>>
>> 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?
>

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.

-- 

*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.