Re: [dmarc-ietf] ARC questions

Brandon Long <blong@google.com> Fri, 04 December 2020 23:19 UTC

Return-Path: <blong@google.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 2DA353A102A for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 15:19:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5qYqKxJvTt7H for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 15:19:38 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 523A43A0DD2 for <dmarc@ietf.org>; Fri, 4 Dec 2020 15:19:38 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id v8so4218900vso.2 for <dmarc@ietf.org>; Fri, 04 Dec 2020 15:19:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0xs7Fcxp6oEut6e0LMGEt0XikgyLXESGb/dcQgZd6u4=; b=tpJkd6dH9+efgfN1o0mO+v9mMIg4SlWwtNCoYg+WGhFPQnezoZ9EvjDbPsrFIz1C66 7RnF7LTBMbu5CAeWlRlobwhu5DjsqstANMNdV07xbiJdXFkrU7Bg4hAci6CdZ6Z/Uhie kppleovvJuTX1Z4LJ5Hyxjo72UA584VmCZyR7qrEQ2q61wDAIv130SMG0Jf6G/iwvnOB WpUGOmmSxVjD4+Cb9h1/VCQ0WmbckUSIUaz2oi9k9SdwkzF5NmHIkO1XzLRLpltQiuxX dSBMBH56wOgUXXf6CVRBgKEKVXKeNa2BzSxZ7rSh6mL52srqpyt7wTisr8+YwLAsRETh vNyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0xs7Fcxp6oEut6e0LMGEt0XikgyLXESGb/dcQgZd6u4=; b=T4q2uIc7IB5KEMr0f0QM9fsZgF64dv03CbG24OikprqU6+uTlXuaGdKVwf+EcJW5fw wiP2Wi2O6vk3p4nwHZmKwEaJ7hEYdGSjcfMEauI3wyh7/0jzcQ/MELEUW1ZI6GGixHrD dHKsq4XDJqis4hDNB4Rbjpz4vPLvP1YLiB1sGc89zLanT4jIA13K/POKBmcIxCNuVf6f htj97hUroHAocmcSmDcUVZWXwlZf5bCiJ7z/QSvPwxuHkSG6AqWkYR/G60FjM16oj5BX Afy5fZWc5rNaPpLIyOiJQSqEehSiHYvNhxnvvsUiIyZCQeI2DltYeUDgJruZ0p0VacB5 F53w==
X-Gm-Message-State: AOAM530HgTkAN3kuQ+cGaxH1AraIC8lzGW4mSpeKyj6ucoylNg6c/ptw zETHSveU3fhnHsjK5qiczkzaHpEW+UfWTMWSDag4
X-Google-Smtp-Source: ABdhPJxDzwPj1YTkGOiu7qn3fdzc0bkHp6hT22kz3C4Ah3wPvtEl/5pAGtBTG3dMNGEJvoW4zo8O3OhKXQ9BHjS+1Fk=
X-Received: by 2002:a05:6102:215c:: with SMTP id h28mr5949465vsg.58.1607123976970; Fri, 04 Dec 2020 15:19:36 -0800 (PST)
MIME-Version: 1.0
References: <20201124020453.AFDC027CE5C8@ary.qy> <cd855b53-d9bd-3412-3bd5-dc4b7720dc5c@mtcc.com> <CABa8R6s0bfs87Fu9eOq_R3WH1pngauVXrw3RSPe9iWWCtf3AmQ@mail.gmail.com> <c954eadd-5c85-c0d9-2168-8a42de506b72@mtcc.com> <CABa8R6swzAQLPU=xE2tr1W0J5r+w80BSYu87_ubMwHaUMgmKvA@mail.gmail.com> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> <CABa8R6sEk+dHwHjBCKDgcmeT_Z3FymC5+jzy-GGa=7gJYvOf5A@mail.gmail.com> <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com>
In-Reply-To: <446d491b-100a-9813-6463-2294f67bbda7@mtcc.com>
From: Brandon Long <blong@google.com>
Date: Fri, 4 Dec 2020 15:19:24 -0800
Message-ID: <CABa8R6sArzV--jWBdAj+etxvXrj9hmog-r7mPqM-E0aAZoTnZw@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: John Levine <johnl@taugh.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c27b4c05b5abb59d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/P2yv8wc-EKRuam1rXqeFe14PL_A>
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: Fri, 04 Dec 2020 23:19:41 -0000

On Wed, Dec 2, 2020 at 12:13 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 11/30/20 9:43 PM, Brandon Long wrote:
>
>
> To summarize what I said already in this thread, DKIM is taken by many
> receivers as the responsible party for a message, in both spam and phishing
> classifiers, with the latter being perhaps more relevant.
> DMARC is the one example of that.  DKIM signing a message that transits
> your system allows for reputation washing of the original message.  The ARC
> chain is specified as a relay responsibility, which is a lesser burden.
>
> Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single
> hop, and lead to some complication compared to the other DKIM signatures
> already on the message.
>
> Wait, what? a DKIM signatures survives until it encounters an intermediary
> that alters the message in a breaking manner. Arc-Signatures are no
> different in that respect. In fact as far as I can tell they are identical
> modulo the i= difference.
>
I'm unsure about the disconnect we are having in our conversation, but I
shall try again.

Yes, a DKIM signature and an AMS both break if the message is altered in
the wrong way.  If you use a DKIM signature to sign the A-R header, you're
choosing to sign against a header which is
often removed by existing infrastructure due to that removal being part of
the RFC for that header, which will invalidate the signature.  Yes, the
remover can validate the signature before removing it, but anyone
downstream is now lost... so now the remover would have to remove the
signature and re-sign.

And fundamentally, every time the message has a breaking alteration, the
message would need to be re-signed.  And every time you add another A-R for
another domain, you'd have to sign, just like we do in ARC.

Except you can only sign with your own key, so now the message you've
modified in some manner has acquired your signature.  What does that mean
to the existing systems?  Well, at Google that means if we receive the
message, we will perform spam classification on it based on the reputation
of the DKIM signature domain, and update the reputation of the domain based
no the results.  This isn't uncommon.  If we perform DMARC verification, we
do so against the DKIM signatures on the message.  The DKIM signature makes
you "responsible" for the message.

Adding an A-R header doesn't seem like the kind of thing that should
justify extra responsibility.  When we argue that changing the From header
of messages on mailing lists because they have
now become the "author" of the message by modifying it, folks rightly
object.  The modifications that are made are automated and clear, the
actual "intended" authorship of the message is mostly
unchanged, why should the mailing list take responsibility?

ARC makes that differentiation, the AMS is saying "I take responsibility
for what should be a minor change" and for the A-R results.  You can use
this to say "ok" or not.  You could potentially evaluate that over time,
even, by seeing the messages that are sent directly and indirectly.  How
you do that is an unknown, hence the experimental nature of this RFC.


> DKIM is not the only thing that can be reputation washed, SPF can as
> well.  821.FROM rewriting is more common, so there are work-arounds.  OTOH,
> SPF doesn't survive forwarding, but with ARC you can forward it.  DKIM+A-R
> would only work for a single hop, and lead to some complication compared to
> the other DKIM signatures already on the message.
>
>
>
>
>> So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it
>> would run into problems? I haven't put up a DMARC policy, but if I did I
>> might run into issues with false positives? Like I said, I'm trying to get
>> my head around what the actual problems are, and this is coming from a
>> person who stressed mightily from the very beginning about the mailing list
>> problem.
>>
> It's unlikely you have a complicated mail flow involving multiple vendors,
> but certainly there are plenty of configuration options alllowing folks to
> shoot themselves in the foot.
>
> By definition a message hitting the front door of the destination domain
> (via an MX record) sees the DKIM signatures in the message and can process
> them at that point, or at some point before other manglers get a hold of
> the message. I don't see why we should care at all about what happens
> beyond the destination domain's front door because that's their problem not
> ours. The entire point of DKIM is the inter-domain case, not intra-domain.
>

My point is that for large organizations, the difference between
inter-domain and intra-domain becomes much weaker.  And I think we're
interested in the entire mail ecosystem, which would
include passing such information between intra-domain email vendors.

> With ARC, we can instead say "trust this arc admd" and have the data
> passed directly, and also work around the DKIM breakage.
>
> But ARC suffers the same breakage with the ARC-Signature. And if the
> ARC-Signature is broken, you can't trust the sealed data because that's a
> trivial cut and paste attack as far as I can see. So I'm just not seeing
> how this is any better than just a plain old DKIM-Signature with the old
> auth-res renamed and signed since you can already for 15 years trust
> signing intermediaries or not.
>
ARC requires the last AMS to be valid for the chain to be intact, yes.  It
does not require that all AMS be valid.  That does mean that content wise,
only the last AMS has a strong ownership of the message.  ARC in this case
does not have the same strength as DKIM.


> As for another comment in the thread about adding two signatures per hop,
> there was a suggestion that it could be replaced with a single signature
> per hop near last call with some loss of information (maybe), but it was
> decided to move forward with the existing solution that already had several
> implementations and was experimental anyways.
>
> As I said elsewhere, since this is an active experiment and it's already
> been a year, it might be good to start documenting what the experiment is
> teaching us. I still after many messages have no clue what what ARC does
> that DKIM+old-auth-res cannot beyond tying the authres and signature
> together. It would be nice to know in a quantitative way why that is
> important, as well as any other things that cannot be done with
> DKIM+old-auth-res.
>
I've cited a number of definitional reasons why your scheme would not work,
I'm unclear what quantitative information would change that fact.  ARC was
designed to actually handle the use case you're talking about without
breaking in obvious ways.  What the ARC experiment is actually asking is
whether the added information is useful.  That information has been
provided at various points, and
certainly we should do so again, but adoption has been slow.  That may mean
the experiment will fail.

At Google with limited adoption externally and without us even doing all of
the things with it that we originally wanted, it has been useful in a
number of corner cases and flows.  That is not sufficient
for the ecosystem at large, of course, we need adoption and better usage to
see at scale.

The utility is always going to be somewhat at the margins, however... 95%
of messages we received were spf authenticated (and presumably nearly
directly sent) back in 2013 (
https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html),
and I think the numbers of increased since then.

> In fact since I expect that most signature breaking intermediaries DKIM
> resign the messages (and if they don't thay aren't going to do ARC either),
> it would be very simple to chronicle how the two approaches differ in
> efficacy. The same reputation look for ARC can be done for DKIM too, after
> all.
>
When the dmarc-apocalypse happened, relatively few mailing list hosters
DKIM signed their messages... and I don't think any interdomain relays do
for the reasons I keep citing.
ARC and DKIM may be similarly technically, but they are meant to impart
different information and be used in different ways, they are not the same.

> BTW: i can understand not wanting to touch DKIM or AUTH-RES proper for an
> experiment, but a standards track document should really consider just
> adding the binding tag to DKIM and Auth-res. They were both designed to be
> able to do that.
>
A-R was not designed to allow arbitrary tags, only ones for specific cases.
DKIM was designed for new tags, but adding them won't automatically change
how systems are interpreting them today.

Brandon