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.
- [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Alessandro Vesely
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Todd Herr
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Todd Herr
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Todd Herr
- Re: [dmarc-ietf] attack on reports Matt V
- Re: [dmarc-ietf] attack on reports Steven M Jones
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Michael Thomas
- Re: [dmarc-ietf] attack on reports Todd Herr
- Re: [dmarc-ietf] attack on reports Michael Thomas