Re: [dmarc-ietf] Forensic report loops are a problem

Alessandro Vesely <vesely@tana.it> Thu, 28 January 2021 12:41 UTC

Return-Path: <vesely@tana.it>
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 0E2053A1206 for <dmarc@ietfa.amsl.com>; Thu, 28 Jan 2021 04:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 pTxhPsARn6id for <dmarc@ietfa.amsl.com>; Thu, 28 Jan 2021 04:41:57 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 8ED4F3A11F6 for <dmarc@ietf.org>; Thu, 28 Jan 2021 04:41:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611837715; bh=mwKTIHy1NrJAQY9YOCIhxZ5++2hSzoFzlyPQ+NHXfkY=; l=2221; h=To:References:From:Date:In-Reply-To; b=A6Buh6JvYVGFB1g2VulcVSc2LH4NWv9jZ2KOLedl/mfjGAdCO5asTOvCFZyuWffkj HPvvHZaIjT3MH9mqku6JlEbep3SgEnZ5VnH6C2hLQQ4/CVmEzn3njMgpDFewQIpp9q uzPZnkqkDuR5pbmVztKIe099vD8DXf/HfUQC9V71dnyGgn87cenTcVeQWUFAP
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0D1.000000006012B113.00000497; Thu, 28 Jan 2021 13:41:55 +0100
To: dmarc@ietf.org
References: <CAL0qLwY5BbwvS9XXqBk=Mp074ntN=NeS97pJAxPBdQEZAsgohg@mail.gmail.com> <20210127203714.007C86CDB9CA@ary.qy> <CAL0qLwbN+HkGfvw79rPPvqL6jWWAsUtWY9X1gW=vAvoeQS8RHg@mail.gmail.com> <b7ea6cb8-ce79-7df7-c521-544358c1866e@crash.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <db72db79-272e-5d52-8994-4da81c8723bd@tana.it>
Date: Thu, 28 Jan 2021 13:41:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <b7ea6cb8-ce79-7df7-c521-544358c1866e@crash.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/7oqtfyI-vA8Z5By0bk9rzR9OtQ0>
Subject: Re: [dmarc-ietf] Forensic report loops are a problem
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, 28 Jan 2021 12:41:59 -0000

On Thu 28/Jan/2021 04:17:06 +0100 Steven M Jones wrote:
> On 1/27/21 12:47, Murray S. Kucherawy wrote:
>> On Wed, Jan 27, 2021 at 12:37 PM John Levine wrote:
>>
>>> I still don't understand why failure reports about messages that happen
>>> to be failure reports are in any way special. >>
>> Loop detection in RFC 5321 is a normative MUST because of the obvious 
>> operational problems it creates.  Maybe I'm being thick, but right now I
>> don't see how this is different, apart from the fact that each message is
>> distinct; you're still causing a problem by turning this on without a care
>> in the world about whether two verifiers start spamming each other. >
> There's coverage in 7489 Section 7.2 that a domain owner can inadvertently
> DDoS themselves via failure reports. And that still surprised many
> implementers, even though it seemed obvious to them in retrospect. >
> This case is even less obvious, and we still have questions coming in about
> it from new implementers. >
> I don't think it's a security consideration because it doesn't scale up
> the way "ruf" can, so it deserves a brief mention here. But I would
> rephrase Ale's last sentence:
> 
> 
> 3.3.  Transport
> 
>     Email streams carrying DMARC failure reports MUST conform to the
>     DMARC mechanism, thereby resulting in an aligned "pass".  Special
>     care must be taken for authentication, as failure to authenticate
>     failure reports may result in mail loops.  These loops can be mitigated
>     by sending reports from a domain or subdomain that doesn't request
>     reports, or by performing rate limiting for report receiving mailboxes.


I rephrased it further:

3.3.  Transport

    Email streams carrying DMARC failure reports MUST conform to the
    DMARC mechanism, thereby resulting in an aligned "pass".  Special
    care must be taken of authentication, as failure to authenticate
    failure reports may result in mail loops.  These loops can be
    mitigated by sending reports from a domain or subdomain that doesn't
    request reports, or by performing rate limiting especially for
    failures related to messages received at addresses published in a
    ruf= tag.


Best
Ale
--