Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

"John Levine" <johnl@taugh.com> Wed, 03 January 2018 20:48 UTC

Return-Path: <johnl@iecc.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 C9A4612785F for <dmarc@ietfa.amsl.com>; Wed, 3 Jan 2018 12:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.76
X-Spam-Level:
X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tQcs7OQb; dkim=pass (1536-bit key) header.d=taugh.com header.b=c7iBbTpq
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 wkDS7EC_bIq1 for <dmarc@ietfa.amsl.com>; Wed, 3 Jan 2018 12:48:09 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5B85B126C83 for <dmarc@ietf.org>; Wed, 3 Jan 2018 12:48:09 -0800 (PST)
Received: (qmail 14084 invoked from network); 3 Jan 2018 20:48:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3702.5a4d4187.k1801; bh=0pAIyytyVna1RzIG5bn9BVYH0j3zHxnvc4TZzWavuF0=; b=tQcs7OQb1PtS6ppo3e/qvUbH13Wy5kDBO7Mv8aMyadm4cpKGVZpTG+cqIHSc4aImQgiPDrrLlImyOA/mbLfqevd36OFrVr7/jdK/OMmAiiuPPu3a1re8Lo21ZGVq5g0JTrkNQgDJwsJmtuBUs9mhAMWfqw32b4tiw/mQSNZYekQPzILIRikk1xUk2JRJ0cPV7Ai+R79kkQzdQfe0W58CsshEToGlIcGpZ/zB1bXmlPSfAYMmQFP53bnd4/FZ1GP3
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3702.5a4d4187.k1801; bh=0pAIyytyVna1RzIG5bn9BVYH0j3zHxnvc4TZzWavuF0=; b=c7iBbTpqo10QlAg3ziOhaEcwaU/m8vtV7ndEv11eDf1Z1gcLrF6EQZ8mVorr3nYLJePB7vs4mpKU1Yp8unem8VkmqW1UQaNmLXoYLXhNeRknSdTr0U+pTvBHoBPGR99j5wBynqINY+obU9wR1shk4Y4HywfOli7Nyv7rLcT/dtHGIXBt0/3jEODghaYrnQ0YxmEThBZDYdYLUn3t38P1Xg5lO/r5PrZOfh6l3VeJ6JjO5w234diwBSH63Lf5gkVr
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Jan 2018 20:48:06 -0000
Received: by ary.qy (Postfix, from userid 501) id C191218C7E78; Wed, 3 Jan 2018 15:48:06 -0500 (EST)
Date: Wed, 03 Jan 2018 15:48:06 -0500
Message-Id: <20180103204806.C191218C7E78@ary.qy>
From: John Levine <johnl@taugh.com>
To: dmarc@ietf.org
Cc: brong@fastmailteam.com
In-Reply-To: <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/eXGO5IpLg47RBTHjzAYd4v2eO2M>
Subject: Re: [dmarc-ietf] Clarifying the value of arc.closest-fail
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 03 Jan 2018 20:48:11 -0000

In article <1514939995.3318165.1222346488.5B169072@webmail.messagingengine.com> you write:
>Please  read my examples again if the problem wasn't clear, because you
>don't get security by imagining the best cases where everyone behaves
>themselves, you get security by imagining that everybody is trying to
>get away with the worst abuses they can without being detected.

Seems to me this makes some assumptions about the way ARC consumers
will use ARC chains to decide whether to ignore a DMARC failure.
Personally, I think the most likely scenario is that they'll look at
all of the signers to see if they all are reasonably trustworthy, and
if so, look at the i=1 seal to see if the message would have passed
before being munged, and if so allow it.  This requires having a giant
reputation database for every ARC signer, but that's not much of a
stretch beyond the reputation database you need to decide whether to
look at the ARC chain at all.

Trying to guess who changed something and whether they were malicious
seems unlikely to work.

R's,
John