Re: [dmarc-ietf] Forensic report loops

Steven M Jones <smj@crash.com> Thu, 14 January 2021 09:22 UTC

Return-Path: <smj@crash.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 346A23A1387 for <dmarc@ietfa.amsl.com>; Thu, 14 Jan 2021 01:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level:
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, 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=crash.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 OjTY3kdtHIZg for <dmarc@ietfa.amsl.com>; Thu, 14 Jan 2021 01:22:32 -0800 (PST)
Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A947C3A134B for <dmarc@ietf.org>; Thu, 14 Jan 2021 01:22:27 -0800 (PST)
Received: from shiny.crash.com (192-184-141-33.static.sonic.net [192.184.141.33]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 10E9MCkC034127 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dmarc@ietf.org>; Thu, 14 Jan 2021 09:22:25 GMT (envelope-from smj@crash.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 10E9MCkC034127
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1610616146; bh=xs2KvYePZAPyPB1nHRnAy32QKwFORYkc7mC/aunpJsc=; h=Subject:To:References:From:Date:In-Reply-To; b=CQZRd05/Ag5oYdGL3vFpdkyg10fgrWC5ist0hmgavnk1cXnVhBmMm6Oc8MOFe6Y5z gdn+oPY1OrKJmjdJqvUA6bTTohmbyRgmnI9XvblNx+MwCmL13ErWl0nFGYYXiUq5Eg ad5MKMCakRUvTfwKcnv3P/Oh5yVMNmuVrYsm+5gz4x/4qqeeqrNu2gQhrRoXoDn2qV UuCdsaTvS9i6nyiDKuLgylfXA44Cl7u7T8oKZepUyOF7UsoRNiYvHv4yaa9xoNzm+V ZXMA/Ucqclg9WBR1QNrJg3AQwHvMXLK9Ov3VTyY/F+88xqBN5Zaywc0XcNi0ztDvN2 pA+uc173ehAXA==
X-Authentication-Warning: segv.crash.com: Host 192-184-141-33.static.sonic.net [192.184.141.33] claimed to be shiny.crash.com
To: dmarc@ietf.org
References: <CAL0qLwaZx97cztehz_o=cCVZRbEP_yFVS9hTqWDKg7cMgjNvFg@mail.gmail.com>
From: Steven M Jones <smj@crash.com>
Message-ID: <9b68024a-f538-af7a-3a9b-e2ad2657ce9b@crash.com>
Date: Thu, 14 Jan 2021 01:22:10 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwaZx97cztehz_o=cCVZRbEP_yFVS9hTqWDKg7cMgjNvFg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Thu, 14 Jan 2021 09:22:25 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HX2oj5DisKEmgMYxxDu77xKqx5I>
Subject: Re: [dmarc-ietf] Forensic report loops
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: Thu, 14 Jan 2021 09:22:34 -0000

On 1/13/21 20:29, Murray S. Kucherawy wrote:
>
> How are implementers dealing with forensic report loops?

The question of whether such a thing is actually ever seen in the wild
should be asked, if only to document that it was asked and answered. See
prior "this is a vanishingly small number who cares" discussions.

Channeling Dave, is it fair to just say the objective is: To ensure that
forensic reports do not ever cause the recipient of a forensic report to
generate another forensic report in response? Is that overly broad? Are
there other goals or conditions?


> Say I send a message from X to Y, whose DKIM signature fails.  Y sends
> me back a forensic report, whose DKIM signature also fails.  X sends a
> forensic report to Y, whose report fails, etc.  We need a way to break
> the loop.

Is there a functional or operational difference between aggregate and
forensic reports I'm not thinking of that would cause the solution for
one case to be unsuitable for the other? Or can we hope for a mechanism
that applies to all DMARC reports?


> Off the top of my head, a few options:
>
> 1) a new header field indicating "This is a forensic report, don't
> generate a forensic report about it."

Is there a reason somebody might use this new header in an abusive way?
Or include it in a forged forensic report to avoid exposure? Cue a 0.1%
of 0.1% sidebar...

Jumping ahead of those questions, would the new header have to be DKIM
signed by the report generator, and the entity /doing final delivery of
that report/ required to validate the DKIM signature(s) from the report
generator, and only generate a forensic report in response if this new
header is not present? Or if the signature didn't cover the new header?
Or if the signature couldn't be validated?

"Doing final delivery of that report" -- is that sufficient? Or, "any
entity processing the report and potentially generating a report in
response?"


> 2) some kind of token that's always in the Subject field of a DMARC
> forensic report.
DMARC forensic report Subject: lines aren't uniform, but the last time I
looked there was an awful lot of similarity. If that were tightened up a
little more, would an explicit token really be necessary?


> 3) always generate forensic reports as the null sender, and specify
> that forensic reports should never be generated in response to the
> null sender

I suppose that would meet the goal, but what would be lost along the
way? What keeps coming to mind is the advice I've seen to have your
bounce messages authenticate with DMARC - if a sender does that or is in
the process of implementing it, they might want whatever forensic
reports they could potentially get...

cf.
https://www.validity.com/how-to-authenticate-your-bounce-messages-with-dmarc/


--S.