Re: [dmarc-ietf] ARC vs reject

Michael Thomas <mike@mtcc.com> Sun, 06 December 2020 19:02 UTC

Return-Path: <mike@fresheez.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 C90A73A09F9 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 11:02:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 TNoESutWEke2 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 11:02:33 -0800 (PST)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 259223A09F5 for <dmarc@ietf.org>; Sun, 6 Dec 2020 11:02:33 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id d2so3645277pfq.5 for <dmarc@ietf.org>; Sun, 06 Dec 2020 11:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FbKBUHQfAOM4igNpt2tzrqk0eywfu9vwe7LJGZaTIb4=; b=aq9po3LZjcTEdsHZA4McHXdIhcnL93rPrqC40znP/n/c2MEolVTD7YWbYkYZTN2WAn ureOjz1MvgB0laKMHaxNWgImsQdVMQEbhY4d31NFPGN9LpZ5iJo+C4P0cj+LbDLd7qrv Tu2lfszktrC+tV9S+CmTz9cF8YuTOCE8rtj9q88r72n1+S5EC/IXY3jlCNhL3D0JiImt XWPKa0gmg5ore++BSPIrUZ3GWAV0XPXTfUttTqVYSLW/BZRtUsSk8DxDuXSrolhndBu4 Bk/MEiapRsObHmaetAFrp5nVX8H2RMZBT7hlhUoI6/AjSKYR/mEyWpS/mQwLLw83eprq 0A3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FbKBUHQfAOM4igNpt2tzrqk0eywfu9vwe7LJGZaTIb4=; b=mQhGrsR4f1NO25EvAxFmssJlzl/XiP3LKOY+8Ybo6Ts5ZoDrooCDFzBjWIfol0ikzm nFQAuhlCqAMalO8XPfoLUngxiLHUFZxSAO1BUoT75R/W3WtXwQbYnzPsp0CKJaK99m2F 3IDhAfiZeP2LbyEBJvNJdt2lT7xjuyWPITwrE5NBrXICeaJKVJwpNlbKk4OcIY97CHj6 pY5pX6V52x9UKXYjc/by9EFzBuLDMI3y1nOkf79GZCt7rOaNM98gc878PBN90HBhB8Z5 ghHoNBL7cGcK4GDRF+wMXYMP3IDLUl4QRVqrgNo93luxgIFA9SmCWIjUERXiXPaCWxoE gT7Q==
X-Gm-Message-State: AOAM533ZgdlDQebbNLDJGwxA7yWpEIQIzxvwWpO8/K9R6O/veGSTWb1P fnsHNWJtek7gVEoGCPyBG2v1VCdn68CTjA==
X-Google-Smtp-Source: ABdhPJzizM5d0NyyD4MFrrGGVBTCSi2BSwGrZyLTVcpZd3uTY5keCQ0LNj/7ztnCSgmtkLR43SN6Qw==
X-Received: by 2002:a63:5856:: with SMTP id i22mr15651342pgm.349.1607281352127; Sun, 06 Dec 2020 11:02:32 -0800 (PST)
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id u15sm3651831pju.7.2020.12.06.11.02.31 for <dmarc@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Dec 2020 11:02:31 -0800 (PST)
To: dmarc@ietf.org
References: <20201205210351.DB78E2904420@ary.qy> <28759E60-3A00-4D25-9490-34495B96EE10@bluepopcorn.net> <9c23d850-4164-1320-1c25-40554c1f64b@taugh.com> <A7E1018B-F6B1-46F3-8FEF-69FDC744DA4A@bluepopcorn.net> <d8dc2644-cbcf-d3a1-c5fb-46fdf5bec819@taugh.com> <CAH48ZfxWWxSh3j3YnA4eD4Y5Ep4GfVDr22WX1MCM4-tcVK0UpQ@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <b5774a04-fbee-8d23-d760-0380d58a9fb7@mtcc.com>
Date: Sun, 6 Dec 2020 11:02:30 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <CAH48ZfxWWxSh3j3YnA4eD4Y5Ep4GfVDr22WX1MCM4-tcVK0UpQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/zneG8GdYqBRwkEUw8SBIAA80jOQ>
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 19:02:35 -0000

On 12/6/20 10:45 AM, Douglas Foster wrote:
> The recent discussion has introduced two challenges to ARC:  first, 
> that it is too complicated, and second, that it opens up security 
> holes that should be unacceptable.    John's response appears to be 
> that the technology will only be used by a small group of lists in 
> cooperation with a small group of recipients, that the complexity will 
> be a non-issue for the participants and the risk, while present, will 
> be mitigated by the limited scope of participation.    All of this is 
> problematic.
>
> On security issues, we have to assume attacks by state-sponsored 
> actors, not just fortune seekers.   So the security challenge needs to 
> be thoroughly vetted.
>
> But the participation assumption is even more worrisome. If this is a 
> limited participation protocol, supported by a private but 
> not-yet-created communication network, then it does not solve the 
> chair's requirement for a general solution.

Indeed, I wonder if ietf.org would meet that criteria for "small group 
of lists".

>
> I ask the chairs to formally endorse development of an alternative to 
> ARC as an additional approach to the mailing list problem, a solution 
> based on reverse transformation.  Alessandro and Murray have submitted 
> drafts.   It is time to study their proposals and merge their work.
>

Based on the work I did at Cisco 15 years ago which essentially was a 
heuristic based form of those two drafts, I found that it worked for 
about 90 some percent. I unfortunately do not know what the nature of 
the remaining messages that could not be recovered (either I never did 
the analysis or don't remember). Things may have changed some since 
then, but that was what we got for the entire mail stream of a large 
company. Is that "good enough"? Or better yet, what is the definition of 
"good enough"?

That's probably the most important question out of all of this: what is 
the success criteria? Our success criteria was that we wanted to mark up 
messages that were possible spear phishing, so the success criteria was 
some given false positive rate, with whitelists to mop up some of the 
corner cases. But that was a very enterprise-y criteria. The larger 
success criteria needs to encompass a far larger set of use cases.

Mike