Re: [dmarc-ietf] attack on reports
Todd Herr <todd.herr@valimail.com> Tue, 26 January 2021 20:02 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 2EA533A0AF3 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 12:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 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, RCVD_IN_DNSWL_BLOCKED=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 uyP23lqYK0U5 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 12:02:54 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 6522E3A0E4A for <dmarc@ietf.org>; Tue, 26 Jan 2021 12:01:51 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id r77so17041451qka.12 for <dmarc@ietf.org>; Tue, 26 Jan 2021 12:01:51 -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 :cc; bh=z8aFzISjbd3k4wZkk2XNuvFZaJoQ3aa3gbspCsceowc=; b=FG2BzpJRifGVyEq3h9jr+J3r7Usl2uRU6SOm/N0z1DxYar5A+0ATEw4FVPn5zGcIWI rPq3DA71xE43FguCsJ3px9hVHClf4U4D++AptTsd7OWlevAO/qaiDQkzTVeAXQsGOZJ3 5wxd8saUVU4/iRnqJmepdfK9VeZEW+BRUiGUGN+Je5GK0G7K+ZbhZ8B3xWXO5Lhv2oEz O3pdt01AMuZYwQEu70d4GLeAMrzPdGKArdVRC+fj/1pRRG9zmHHItE7nXATG4eVR/hwB wZMShio8YHhLz3rpEzlB9PjwLs5jP0+KRkDe14JXrQBLVWArgV7C/N9vsFnMeR4SuD+j FmEA==
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:cc; bh=z8aFzISjbd3k4wZkk2XNuvFZaJoQ3aa3gbspCsceowc=; b=tW0CBEKP4W4L50lL7IvMCf033XVPNpbUMsOZhCx+Hc4njqrBndlWzP3oGwH+nxD0ob iZrMhruIF6aiiUTHsVhAoTjCIYrjZ5i5nHzZrOpVtGJ/5i/qYqGwQIcYOq67RwnbfswN qFdq1MoBtQbh2N3acZELEaohDiCRo5Hp0dJN4oHToEhN+qYZeUYgD2RdWAx62yZ7P01s TfUHpg+KWEjI7d461HedasVnyEmfGbpD1ZYA/pHu9Fy6+RJ585hJ+lpEeKMTK0fS1FBh 4iEEqcYv8UgDp8AznkuIQYUH/58NAsGVWmakUCapWQcRrBgV2FIMe7/VnH00kfeY3dNW TvRw==
X-Gm-Message-State: AOAM533e+JHtbLraxGEfko7WPHQklrSX+Lsm0coJ+YcUbORxkwOCfFkT H9DhHaEkl7lgaqD7AxIPCX12PJg+qP44Jk5z35kpJREa1f82Vg==
X-Google-Smtp-Source: ABdhPJz1dkbsyQPWNiBNhay5lDhpDP7rsZzz8fY22m1pQQgGJ2TsWZRqYZcw1adBR4sGMD3E7UwGFibaTc4RryxKRpQ=
X-Received: by 2002:a37:a245:: with SMTP id l66mr3200703qke.325.1611691310184; Tue, 26 Jan 2021 12:01:50 -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> <CAHej_8kS7hHR70LdcktuEtm08FyjsmqV17wHq21MdT=eNspCGw@mail.gmail.com> <f8f77f85-a2ae-3fb3-acb4-70d14a9da0f4@mtcc.com>
In-Reply-To: <f8f77f85-a2ae-3fb3-acb4-70d14a9da0f4@mtcc.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 26 Jan 2021 15:01:34 -0500
Message-ID: <CAHej_8nZu3Fgj1=V8aQnho7LEc0Y12KfXa8b+xxXVDzDqe8Bxg@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000080f1505b9d320fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PkcfzgGbc3pcgKmKVnyvZWa5Kfg>
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 20:02:57 -0000
On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <mike@mtcc.com> 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. 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. -- *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