Re: [dmarc-ietf] ARC questions

Michael Thomas <mike@mtcc.com> Thu, 26 November 2020 18:28 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 AED103A00C9 for <dmarc@ietfa.amsl.com>; Thu, 26 Nov 2020 10:28:33 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Jm9-E0bSL1j7 for <dmarc@ietfa.amsl.com>; Thu, 26 Nov 2020 10:28:31 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 D21453A005C for <dmarc@ietf.org>; Thu, 26 Nov 2020 10:28:31 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id n137so2327244pfd.3 for <dmarc@ietf.org>; Thu, 26 Nov 2020 10:28:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=8tVN2ZGUXk21i3Jy7X+JCHT2mQj0hMAtJgPK/osR9f0=; b=RCCVLAtjCjCJvXYhPrhrOsDFrI/X28aeedXfKFUOt4VR7Qa/fv87MmT26ILUf+45CX 5ZBXTohDQVlkQrVh08i0VzYYVVI6sUnVuyc01cmDkKattAKJ7qvsUH+fwGk+qknPLBp8 nNYAf9VHIarRLHh7+4UBCs8NCB4oVbaDfqO3GbxroLoYnA1FxWIPBnBHMTj7XW4UMPSO w4c8ZLBrhsPYRjUEyq7r+rZa0mjgiC6Ar2V++76OEgStCcwi2BI6YgZtlRhE2zQLgHlI ur5k0KADpfBX68K6Okth1P/GgEm3DmS/iI6VOd+ay49KQbTe48cSLAbFwIlDIPT40QDi RgkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8tVN2ZGUXk21i3Jy7X+JCHT2mQj0hMAtJgPK/osR9f0=; b=H4nj3AK2BvfOu5v7mljZrTN2l3IbUXiv9alctFHIpFDiUrs8RtWR9+G9CR9JBhisIZ aW7X1YxFIPAQV8rB5J0iPO6LoPCM3MGMd29+we5djiFxZs+vlZTB0sSCVAGDZalrisLl C908OomYBKbBWRK1AxfphNmsrGs68d9RSkukn/SWAC7qZkO3pd3sS1x38+XihJ82F3ss bZZs3TXfmCv3LmLtwxhTrHhk6mlubPX+o/IW65cfAYzV19U2TSv0X39vu1OzGVmp/Ack fNuvMJ1FTUxnRo7xCVZhfTtdN+zQB6IDaL5BfVphDIHG9b/S+IksiL5Pg3oMPsAk5N23 wThg==
X-Gm-Message-State: AOAM530f2KMicHhyBSHc5JGugyzA8C68eyiU0x4Aa6fjxuoFbcTT/AO8 Hp+i3W3VIHrtMyZ7xqEQ8DeXelmmV7sv3A==
X-Google-Smtp-Source: ABdhPJykTUaDoOL4/bKOY34v4SsNNEAl/blRR7rj/FfwVz5wLWomSEA1eM8vJyrg9+iKwNCI+SD0Sw==
X-Received: by 2002:a63:8149:: with SMTP id t70mr3447895pgd.80.1606415310757; Thu, 26 Nov 2020 10:28:30 -0800 (PST)
Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id p6sm7334317pjt.13.2020.11.26.10.28.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Nov 2020 10:28:30 -0800 (PST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com> <c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.com> <CAH48Zfx25_o+-j0=mEA6ib=2aKPqBDihA4rt0c9_vE+570Q+TQ@mail.gmail.com> <CAL0qLwY3fc+YP-Pw1k2XJgOM0cU1W9AhuPD+kouh8Ns9UzW_HA@mail.gmail.com> <e39252f5-12d1-cdfa-5413-30cfbf2b8a4b@mtcc.com> <CAL0qLwZzg_MzX1cRe8pYZnLQovaBZJtCuUPMZpkt+TKtc=4K7w@mail.gmail.com> <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> <CAL0qLwaaiU3AGaCQ5=4GQP5vvu_kGmBK7PhDYGYc_LiSVbexdw@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <c4745515-5fa9-6617-9491-e01813d716b9@mtcc.com>
Date: Thu, 26 Nov 2020 10:28:28 -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: <CAL0qLwaaiU3AGaCQ5=4GQP5vvu_kGmBK7PhDYGYc_LiSVbexdw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CBA69FEBDA98C8D6A0D5D407"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/W7YquRuxJUwLq7bGwNF2EWMxSNc>
Subject: Re: [dmarc-ietf] ARC questions
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, 26 Nov 2020 18:28:34 -0000

On 11/26/20 1:56 AM, Murray S. Kucherawy wrote:
>
> ARC was developed over months, even before this WG started, and I 
> remember all of these conversations happening involving the questions 
> you're now asking.  We landed at what became ARC.  I suppose an 
> appendix might've been nice enumerating everything that was considered 
> and discarded, but that record doesn't really exist.

Yeah, like I said that's sort of a common failing of IETF documents in 
general. I mean, I understand at a very low level what's going on here, 
but given the document I am completely clueless of the *why* of things 
are going on. It's very frustrating, doubly so when it's a self-labeled 
experiment.

>
>
> Where do you suggest we go from here?

I would think that an informational RFC might come in really handy both 
to answer the questions in ARC itself, and any other subsequent 
questions the wg deems needed since then. Leaving ARC in an experimental 
state ad infinitum doesn't seem optimal. Basically: 1) was it needed at 
all 2) did it help. 3) if it helped, how much did it help. (1) in 
particular is what interests me because adding two new signatures seems 
*really* heavy handed. That would go a long way toward answering the 
questions of whether it's should go standards track.


> I haven't put hand to coding keyboard on this problem yet, but I'm 
> trying to imagine how it would be easy to determine (a) that Subject 
> had been modified (for example), (b) what the specific modification 
> was, and (c) which hop did it.  You could say a message failing to 
> validate an author signature with "[...]" at the front of Subject was 
> likely tagged by an MLM, or that everything after "--" should be 
> ignored, or that those probably happened at non-submission hop #1, but 
> those are heuristics, and I think we're hoping for something more 
> deterministic.  The 80/20 rule isn't sufficient.
>
> But it's late and maybe I'm missing something.  What did you have in mind?

Our motivation at the time was one in particular: spear phishing. From 
an enterprise situation spear phishing is scary af, and not one that 
providers have much care about. That's what John gets wrong when he says 
that 90% pass rate is useless: for enterprise not wanting to get spear 
phished, a 10% false positive rate issuing warnings might be acceptable, 
and since we were grappling the intractable mailing list reputation (at 
least from our standpoint), maybe a better option.

But it was a combination of the l= value in the original signature to 
clip off what the mailing list added, and some heuristics on the subject 
line to remove added text. I had quite a few of them, and they were 
certainly pretty dodgy, but by and large they worked. The object was not 
to get to 100%, but just an acceptable false positive rate. At the time 
I mentioned that maybe it would be good to create a DKIM-friendly 
mailing list BCP, but that was scoffed at by the usual suspects because 
there was supposedly a massive long tail of transformations that can 
happen that nobody would quantify as to how common or important they 
were. Hence my desire of this being driven at least in part by numbers.

>     Sure, but the easier answer: to use my mailing list, you must have
>     either DKIM, SPF or both. Sounds like a good way t
>
>     o not be essentially an open relay. Don't mailing lists have those
>     sorts of policies these days? I would say that ones that don't
>     probably shouldn't have good reputations since they are, in
>     effect... open relays.
>
>
> That requires MLMs to change their behavior, which I believe is 
> something all of these protocols are hoping to avoid (or, at least, 
> MLMs should decide that on their own, not because the IETF forced them 
> to by wielding DMARC and ARC at them).

I don't see making mailing lists coerced into better behavior as a 
non-starter. Everybody has had to change over the years to get mail 
delivered, and mailing lists, etc, shouldn't be viewed as sacred cows. 
If they want to forward their mail, they need to play by the evolving 
rules so as to make for a less spammy and phishy world. Back when DKIM 
was the new kid on the block, that might have been a valid argument. 
Today, not so much.


>     PS: it's been, what, 15 years since our interop, partner? :)
>
> 2007.  Still got the t-shirt.
>
But we interoped the combined DK and IIM spec a couple of years earlier, 
right? What a great day that was... we dunn'em proud, Murray :)


Mike