Re: [dmarc-ietf] attack on reports

Todd Herr <todd.herr@valimail.com> Tue, 26 January 2021 18:57 UTC

Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8F63A0D91 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 10:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3w1J0CmCYD8 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 10:57:12 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CF43A0D8E for <dmarc@ietf.org>; Tue, 26 Jan 2021 10:57:03 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id r77so16816018qka.12 for <dmarc@ietf.org>; Tue, 26 Jan 2021 10:57:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fM7hGt7ZxzxMmBk+o2DPyNLojfzd9J5F+ezoOwi2TcY=; b=emsTR7hrXF+OisndJzFMGa7RT5CqxtvySdbpf+EVlgLKSX8+kli8UhjrMf0GPuAP+7 c7Yma59Igj18KlGNqhcy17G/z9+JH98sRYvDwEowYUgYqbA+bJAHv87s/5h4NBbGos1h iTScmzRVrlEuDqGB/9OOkV3nODPmcIpnOs1NkF49nxD4k8Ka0g1PtdBlrG9J3LFAnumK NI/G0vbkVjREMS54vCbPNxXzpeDL8RRvhzl/qS4LUR2yBlukkXxAOgubB7P6WzfY8sJ8 4eVbq+INlCxeo8TDpqEAOnhtRZN9AsCoto55zVDbZCZzfhau7e2yriDd5H87xGryTI0G D/EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fM7hGt7ZxzxMmBk+o2DPyNLojfzd9J5F+ezoOwi2TcY=; b=B3TG8sadhBfhQ0xp+bwDJ22FdwyHNc5BuKH2UKIfGY3rkmqHahIXyNn14BIaysXQgX fXNGcJgR1Rn3pSRW7RmztubC1KkIFcyk0lt999IVhOnjWxosRRKUUMCZjG5FtZOqJVkh wdLJm1cQ/Mpy/WJKSNRqPzoRLirl+HD+gRrJPCC7iEJwWR2DLu6er47YZlJdstItMr/H PajH3/mkfhM4JIEkG23ppV25Yz2nmAFDZ7DP32DqbuguKf49GsmhRGQRYLFglh7Thkii REXAenrSPlrmnr29htCASQc/MhjwYnRMvUu9W4Bszaqsrx6/xD+LcCbNbm8MoWvAyg8g /C4g==
X-Gm-Message-State: AOAM533IH/Ia6OGv2XwjtlpQxcgGsfa/kLsEvdGtUZpCO2yk/IGWDoGn pNxI9Rbw3qknpOBNfEyfR1M71C4nLlSxqb102A2UwIHFU1w=
X-Google-Smtp-Source: ABdhPJxjBJiKzGw+W489nausFMuFYQiT1KFVzKfKmps9CrVG1WviBdNGCsdpXgLZ/64b89fJ1nMIQWEAji6CsMVZAzo=
X-Received: by 2002:a05:620a:1fb:: with SMTP id x27mr6924934qkn.456.1611687422328; Tue, 26 Jan 2021 10:57:02 -0800 (PST)
MIME-Version: 1.0
References: <c049495f-faa2-c5f0-3e0a-7d8d86150568@mtcc.com> <aab313ee-4453-d97c-65ad-2a02d543c66c@tana.it> <24e8da5d-e306-7207-bb8f-74d44e4c5eaf@mtcc.com>
In-Reply-To: <24e8da5d-e306-7207-bb8f-74d44e4c5eaf@mtcc.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 26 Jan 2021 13:56:46 -0500
Message-ID: <CAHej_8kS7hHR70LdcktuEtm08FyjsmqV17wHq21MdT=eNspCGw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004c149c05b9d23847"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/hTgEkC59rIQACbqon0jwNN1KmMI>
Subject: Re: [dmarc-ietf] attack on reports
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 18:57:15 -0000

On Tue, Jan 26, 2021 at 1:01 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 1/26/21 9:37 AM, Alessandro Vesely wrote:
> > 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.
>
>
>  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?
>

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.


>
>
> >
> > 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
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:* todd.herr@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.