Re: [dmarc-ietf] ARC vs reject

Jim Fenton <fenton@bluepopcorn.net> Sun, 06 December 2020 03:56 UTC

Return-Path: <fenton@bluepopcorn.net>
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 6157C3A0C9D for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 19:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=bluepopcorn.net
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 DJAwkpShfFj8 for <dmarc@ietfa.amsl.com>; Sat, 5 Dec 2020 19:56:10 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 B36893A0C9B for <dmarc@ietf.org>; Sat, 5 Dec 2020 19:56:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XedvumPxX62cfOVkQBXa9FkCArfg/7boUtgS4nNX5f0=; b=t2HQWKMsRczk5ZdpiYglLwdUdD VHUJalhv8BWCzk704F5Q667BT8sLlFuDcKIWZV20EGNhpgHZHp273iSO+dW5LHDeqAUQqPdK4RAxG vOVNBiHZDvKbNaYOa3Z16dLwmAGHfFHufSBArFH7GAVz1aQSezyWxxpLVhHiHh4Hc8AI=;
Received: from [2601:647:4400:1261:7d1c:9b45:21bd:630e] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fenton@bluepopcorn.net>) id 1kll9d-00057I-1w; Sat, 05 Dec 2020 19:56:09 -0800
From: "Jim Fenton" <fenton@bluepopcorn.net>
To: "John R Levine" <johnl@taugh.com>
Cc: dmarc@ietf.org
Date: Sat, 05 Dec 2020 19:56:08 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <A7E1018B-F6B1-46F3-8FEF-69FDC744DA4A@bluepopcorn.net>
In-Reply-To: <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com>
References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/sknJ55aV-2ucvSme8rvPI-6s8_o>
Subject: Re: [dmarc-ietf] ARC vs reject
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: Sun, 06 Dec 2020 03:56:12 -0000

On 5 Dec 2020, at 18:22, John R Levine wrote:

>> If a domain publishes p=reject, they’re requesting particular 
>> handling of a message they originate. ARC modifies that, which is 
>> good for mailing lists and similar intermediaries, but depends on a 
>> list of trusted intermediaries that is not under the control of the 
>> originating domain. That increases the attack surface for DMARC 
>> considerably.
>
> Not if the recipients use ARC reasonably, e.g., only on mail from 
> hosts with a history of not sending botware, use it to see whether a 
> message was originally aligned.  Anyone who misuses ARC is going to 
> have worse spam leakage than anyone can fix for them.

“Use ARC reasonably” then seems to depend on whether the recipient 
has a good reputation system for evaluating the trustworthiness of 
message modifiers. There isn’t a good track record in creating and 
deploying such reputation systems, as you well know. In this case 
specifically, there is the question of what happens when a domain user 
subscribes to a mailing list, or has their mail forwarded with 
modification, from a new intermediary.

>> The question I have is: Should DMARC have a policy (or policy 
>> modifier) that says, “Do not accept modifications to this 
>> message?” In other words, that the originator values the integrity 
>> of their messages over deliverability.
>
> Of course not.  That's just the tiny gorillas stamping their teensy 
> feet. Why would anyone expect that the people publishing that flag 
> actually understood what it meant?  Many will just turn it on because 
> someone said it's "more secure."

FWIW, I don’t think a lot of the people publishing p=reject understood 
the implications of that, either. This is not significantly more arcane.

> A lot of this boils down to what if some entity sends signed valid 
> DMARC aligned mail but somehow doesn't mean it, e.g., an internal 
> policy says no mailing lists but their users participate in lists 
> anyway.  If they can't control their own mail system, it is not anyone 
> else's job to do it for them.

It isn’t a question of controlling their own mail system. One of the 
value propositions of DMARC is effectiveness against phishing. Suppose a 
phishing attacker composed a message purporting to be from someone the 
victim trusts (including a DKIM signature that doesn’t verify because 
the message has supposedly been modified), and then makes it look like 
it has been forwarded by a throw-away intermediary they control and adds 
valid ARC header fields signed by the supposed intermediary. If the 
recipient domain accepts modifications by zero-reputation intermediaries 
(because there are so many of them, after all), DMARC policy is ignored 
and the message is delivered normally. The premise of DMARC is that the 
originating domain has an interest in expressing how messages purporting 
to come from their domain should be handled, and this attack uses ARC to 
override that.

I’d be interested in other opinions on this. Or whether this is a 
fundamental problem with ARC.

-Jim