Subject: Re: [dmarc-ietf] ARC questions

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 12:13:44 -0800

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.

>
> 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 <http://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.

>
>
> 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.

>
> 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.

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.

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.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2020 15:31:19 -0500

On Wed, 2 Dec 2020, Michael Thomas wrote:
>> 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.

Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 12:32:34 -0800

On 12/2/20 12:31 PM, John R Levine wrote:
>> Arc-Signatures are no different in that respect. In fact as far as I 
>> can tell they are identical modulo the i= difference.
>

That's why I said "modulo the i= difference"

Mike

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2020 15:35:06 -0500

On Wed, 2 Dec 2020, Michael Thomas wrote:
>>> different in that respect. In fact as far as I can tell they are identical 
>>> modulo the i= difference.
>> 

> That's why I said "modulo the i= difference"

Well, yeah.  That i= is why we have ARC seals rather than just using a 
DKIM signature.

Remember that ARC is only useful if the last system sending the message to 
you is reasonably trustworthy, not in the sense that it never sends spam, 
but in the sense that its ARC tells the truth about what it saw.  That's 
a low bar that any mailing list should be able to meet.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 12:38:31 -0800

On 12/2/20 12:35 PM, John R Levine wrote:
>>>> different in that respect. In fact as far as I can tell they are 
>>>> identical modulo the i= difference.
>>>
>>> Please reread the ARC spec.  The ARC-Authentication-Results at level 
>>> N tells you whether the ARC and DKIM signatures were good at level N-1.
>
> Remember that ARC is only useful if the last system sending the 
> message to you is reasonably trustworthy, not in the sense that it 
> never sends spam, but in the sense that its ARC tells the truth about 
> what it saw.  That's a low bar that any mailing list should be able to 
> meet.
>
Which could trivially be added as an extension to DKIM and Auth-Res 
negating the need for the Seal altogether since DKIM can directly sign 
the old (renamed) auth-res. I can understand for an experiment not 
wanting to touch dkim or auth-res, but for something standards track 
less is more.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2020 17:53:33 -0500

> Which could trivially be added as an extension to DKIM and Auth-Res negating 
> the need for the Seal altogether since DKIM can directly sign the old 
> (renamed) auth-res. I can understand for an experiment not wanting to touch 
> dkim or auth-res, but for something standards track less is more.

I still don't get it.  I suppose the ARC group could have done something 
to register extra tags for DKIM-Signature and A-R and tried to do 
something about the fact that if a message passes through the same network 
twice, the first A-R will be deleted, and try and find and turn off all of 
the places where mailing lists helpfully delete DKIM signatures that no 
longer are valid, and what they came up with wouldn't work a whole lot 
worse than ARC does.

But why bother?  The IANA header field registry currently has 419 entries. 
Why is it a crisis if it increases to 422 rather than 420?

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 15:30:01 -0800

On 12/2/20 2:53 PM, John R Levine wrote:
>> negating the need for the Seal altogether since DKIM can directly 
>> sign the old (renamed) auth-res. I can understand for an experiment 
>> not wanting to touch dkim or auth-res, but for something standards 
>> track less is more.
>
> I still don't get it.  I suppose the ARC group could have done 
> something to register extra tags for DKIM-Signature and A-R and tried 
> to do something about the fact that if a message passes through the 
> same network twice, the first A-R will be deleted, and try and find 
> and turn off all of the places where mailing lists helpfully delete 
> DKIM signatures that no longer are valid, and what they came up with 
> wouldn't work a whole lot worse than ARC does.
>
> But why bother?  The IANA header field registry currently has 419 
> entries. Why is it a crisis if it increases to 422 rather than 420?
>

It does a lot more than that:

1) It adds two new signatures to an already existing DKIM signature that 
mailing lists add

2) It adds a new security mechanism (Seal) and adds a new attack 
surface, when the old (renamed) auth-res could just be DKIM-signed which 
has been thoroughly vetted

3) It adds a lot more bloat to the headers

4) Signing is a *far* more expensive operation than verifying, and you 
negated any supposed advantage by adding two new signatures to verify 
for lists that unhelpfully strip the original signature

I see a lot of anecdotes and speculation going on here and very little 
hard data. This has been going on for at least a year. Since this is an 
experiment, that is very worrying. More worrying is that I can't get a 
straight answer on what exactly the value is of the mailing list's 
auth-res is to filtering decisions. That seems to be the lynchpin to all 
of this, but from what I'm seeing it's like an article of faith.

Mike

---

From: "John R Levine" <[email-masked]>
Date: 2 Dec 2020 21:33:52 -0500

> It does a lot more than that:

We've been through this all before and none of these are persuasive.  For

> 3) It adds a lot more bloat to the headers

The message you just sent arrived with 4600 bytes of header (see below) 
and under 2K of text.  Copies that went through the dmarc mailing list 
probably had at least another 1K of header.

If header bloat were ever an issue, it hasn't been for decades.

R's,
John
---- snip ---
Subject: Re: [dmarc-ietf] ARC questions
To: John R Levine <[email-masked]>, Brandon Long <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 15:30:01 -0800

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 18:44:58 -0800

> We've been through this all before and none of these are persuasive.  For
So you just dismissed every other thing i wrote as insignificant and 
picked off one that is just calling into question why this is worth it. 
Sorry you are not persuasive. And you most certainly have not answered 
the central question of what having the previous auth-res is useful for 
in practice to add all of this heavy and untested machinery.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 18:47:20 -0800

PS: you're adding X-Google-DKIM-Signature which nobody knows what its 
utility is to your bloat total for dramatic effect.

Mike

On 12/2/20 6:33 PM, John R Levine wrote:
> The message you just sent arrived with 4600 bytes of header (see 
> below) and under 2K of text.  Copies that went through the dmarc 
> mailing list probably had at least another 1K of header.
>
> Return-Path: <[email-masked]>
> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
> X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 
> tests=BAYES_00,DCC_REPUT_00_12,
>     DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
>     autolearn=no autolearn_force=no version=3.4.4
> Delivered-To: [email-masked]
> Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -0000
> Delivered-To: [email-masked]
> Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -0000
> Authentication-Results: iecc.com; spf=pass 
> spf.mailfrom=[email-masked] spf.helo=mail-pl1-x62a.google.com 
> smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass 
> header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 
> header.a=rsa-sha256 header.b="vvoZ+Loe"
> Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
>   by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
>   with ESMTPS via TCP6 (port 38853/25) id 665297367
>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 2020 
> 23:30:06 -0000
> Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
>         for <[email-masked]>; Wed, 02 Dec 2020 15:30:05 -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-transfer-encoding:content-language;
>         bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
> b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
> KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
> +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
> l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
> VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
>          Y3Nw==
> 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-transfer-encoding
>          :content-language;
>         bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
> b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
> TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
> 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
> GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
>          2CWA==
> X-Gm-Message-State: 
> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD
>     chdQCnyR1XB3fAEw5oIqGysS4Q==
> X-Google-Smtp-Source: 
> ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
> X-Received: by 2002:a17:90a:c4f:: with SMTP id 
> u15mr287214pje.177.1606951804840;
>         Wed, 02 Dec 2020 15:30:04 -0800 (PST)
> Return-Path: <[email-masked]>
> Received: from mike-mac.lan (107-182-42-33.volcanocom.com. 
> [107.182.42.33])
>         by smtp.gmail.com with ESMTPSA id 
> x7sm158495pfn.85.2020.12.02.15.30.03
>         (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
>         Wed, 02 Dec 2020 15:30:04 -0800 (PST)
> References: <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <CABa8R6swzAQLPU=[email-masked]>
>  <[email-masked]>
>  <CABa8R6sEk+dHwHjBCKDgcmeT_Z3FymC5+jzy-GGa=[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
>  <[email-masked]>
> Message-ID: <[email-masked]>
> 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: <[email-masked]>
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 8bit
> Content-Language: en-US

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Dec 2020 18:58:28 -0800

if you're trying to make a point about the bloat, you might actually get 
your facts straight. ARC adds an additional DKIM signature and a Seal. i 
have no idea what a X-Google-DKIM-Signature is and is not relevant.

Mike

On 12/2/20 6:55 PM, John R. Levine wrote:
> Um, it was there when your message arrived here.  Complain to your 
> mail provider.
>
>>>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 
>>> 2020 23:30:06 -0000
> John Levine, [email-masked], Primary Perpetrator of "The Internet for 
> Dummies",

---

From: Benny Pedersen <[email-masked]>
Date: Thu, 03 Dec 2020 19:11:31 +0100

Michael Thomas skrev den 2020-12-03 03:58:
> if you're trying to make a point about the bloat, you might actually
> get your facts straight. ARC adds an additional DKIM signature and a
> Seal. i have no idea what a X-Google-DKIM-Signature is and is not
> relevant.

would you show an example on that openARC adds openDKIM signature ?

---

From: Brandon Long <[email-masked]>
Date: Fri, 4 Dec 2020 15:19:24 -0800

On Wed, Dec 2, 2020 at 12:13 PM Michael Thomas <[email-masked]> wrote:

> 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.
>
> that alters the message in a breaking manner. Arc-Signatures are no
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.

> 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.
>
> (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.

> 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.
>
> 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.

> 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

---

From: Brandon Long <[email-masked]>
Date: Fri, 4 Dec 2020 15:27:41 -0800

I'm pretty sure I explained what the X-Google-DKIM-Signature was in this or
related threads.  It was
part of the original attempt at ARC, which was
X-Original-Authentication-Results.  Adding just
an XOAR header was not sufficient, we had to have reason to trust it, so we
added the signature.
We didn't re-use the existing DKIM-Signature header name because that
header was already used
by DMARC and had a bunch of other uses that we didn't want to use.

And our own coding error while doing it meant that we validated that
point... Turns out the signature
was done re-using the existing DKIM code, which didn't sign the extra
X-Google- at the beginning...
so just stripping that off would still pass verification.  And we
originally signed with d=google.com,
so people could relay mail through us, remove the X-Google- and send it
again and phish people
since it was validly signed by Google.  So, we switched the domain to a
domain that never sends
email to work around that security issue.

So yes, that's a way to work around some of the issues if we wanted to
pursue the DKIM+A-R,
just have everyone sign with a different domain that you don't use for
mail.  That seems heavier
weight to me, but that would be a single-hop solution.  I think we did
discuss this in the early meetings
and found the ARC proposal provided more (multi-hop) and less complicated
(no new domains).  There's
also a phishing design challenge when picking a domain to represent you in
a limited way.

Brandon

On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 16:44:44 -0800

On 12/4/20 3:27 PM, Brandon Long wrote:
> I'm pretty sure I explained what the X-Google-DKIM-Signature was in 
> this or related threads.  It was
> an XOAR header was not sufficient, we had to have reason to trust it, 
> so we added the signature.

DKIM doesn't have to be from the originating domain, and if you look at 
my mail headers in this message, you will see there is no originating 
domain signature because I changed over to gsuite last year. DMARC would 
just ignore all of those non-From domain signatures. I don't see the 
problem here.

I don't understand what you mean about "trust". I thought the entire 
point of ARC was to deliver the intermediary's auth-res for 
consideration to the next hop(s). that could be done with XOAR and DKIM. 
If you don't agree, I would appreciate a step-by-step why that is not 
the case because I'm just not seeing it.

And if X-Google is legacy, why is it still in your email headers? I have 
to say that when I came upon all of this it was definitely a wtf moment. 
I imagine that other people less familiar will look at it and have a 
FOMO moment.

> and found the ARC proposal provided more (multi-hop) and less 
> complicated (no new domains).  There's
> also a phishing design challenge when picking a domain to represent 
> you in a limited way.

The original intent was for mailing lists to always DKIM-resign with the 
domain of the mailing list. I expect that that happens today (and if 
they don't, ARC is not likely to be adopted either). So that can't 
possibly be heavier than adding two new signatures on top of that, since 
mailing lists would still have to apply the resigned DKIM signature.

Mike

>
> Brandon
>
> On Wed, Dec 2, 2020 at 6:58 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >>> Return-Path: <[email-masked] <mailto:[email-masked]>>
>     >>> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
>     gal.iecc.com <http://gal.iecc.com>
>     >>> Delivered-To: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     >>> Authentication-Results: iecc.com <http://iecc.com>; spf=pass
>     >>> spf.mailfrom=[email-masked] <mailto:[email-masked]>
>     spf.helo=mail-pl1-x62a.google.com <http://mail-pl1-x62a.google.com>
>     >>> header.d=mtcc-com.20150623.gappssmtp.com
>     <http://mtcc-com.20150623.gappssmtp.com> header.s=20150623
>     >>> Received: from mail-pl1-x62a.google.com
>     <http://mail-pl1-x62a.google.com> ([IPV6:2607:f8b0:4864:20::62a])
>     >>>   by mail1.iecc.com <http://mail1.iecc.com>
>     ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
>     >>>   tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com
>     <http://mx1.taugh.com>; 02 Dec
>     >>> 2020 23:30:06 -0000
>     >>> Received: by mail-pl1-x62a.google.com
>     <http://mail-pl1-x62a.google.com> with SMTP id 4so91499plk.5
>     >>>         for <[email-masked] <mailto:[email-masked]>>; Wed,
>     02 Dec 2020 15:30:05 -0800 (PST)
>     >>>         d=mtcc-com.20150623.gappssmtp.com
>     <http://mtcc-com.20150623.gappssmtp.com>; s=20150623;
>     >>>         d=1e100.net <http://1e100.net>; s=20161025;
>     >>> Return-Path: <[email-masked] <mailto:[email-masked]>>
>     >>> Received: from mike-mac.lan (107-182-42-33.volcanocom.com
>     <http://107-182-42-33.volcanocom.com>.
>     >>> [107.182.42.33])
>     >>>         by smtp.gmail.com <http://smtp.gmail.com> with ESMTPSA id
>     >>> To: John R Levine <[email-masked] <mailto:[email-masked]>>,
>     Brandon Long <[email-masked] <mailto:[email-masked]>>
>     >>> Cc: IETF DMARC WG <[email-masked] <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>
>      <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>
>      <CABa8R6swzAQLPU=[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>
>      <CABa8R6sEk+dHwHjBCKDgcmeT_Z3FymC5+jzy-GGa=[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>>  <[email-masked]
>     <mailto:[email-masked]>>
>     >>> From: Michael Thomas <[email-masked] <mailto:[email-masked]>>
>     >>> Message-ID: <[email-masked]
>     <mailto:[email-masked]>>
>     >>> In-Reply-To: <[email-masked]
>     <mailto:[email-masked]>>
>     > John Levine, [email-masked] <mailto:[email-masked]>, Primary
>     Perpetrator of "The Internet for
>     > Dummies",
>     > Please consider the environment before reading this e-mail.
>     https://jl.ly <https://jl.ly>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>