Subject: [arc] Simplifying the Decision to Trust an ARC Header Set

From: Todd Herr <[email-masked]>
Date: Fri, 24 Sep 2021 15:12:10 -0400

As a result of an internal conversation at my employer on the topic of
trusting ARC header sets, I would like to throw an idea out there for the
list membership to chew on.

"If you accept a message from an intermediary, you trust that any ARC
header set inserted by that intermediary that passes your validation checks
contains information that is true and correct."

This makes no value judgement regarding the quality of the mail that caused
the ARC header set to be inserted; it only stipulates that if you accept a
message from the intermediary foo.com and find an ARC header set inserted
by foo.com, if that ARC header set validates then you trust that the
information contained in the ARC header set is true. You can then use the
information in the ARC header set to aid in your message disposition
decision.

Deciding whether or not to trust ARC header sets is, to my mind, the chief
hurdle to widespread ARC adoption. This provides a simple way to make that
decision, and it's a decision that's no more permanent than the decision to
accept the message itself from the intermediary.

Appreciate any feedback y'all might have.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 25 Sep 2021 21:05:16 -0400

It appears that Todd Herr  <[email-masked]> said:
>-=-=-=-=-=-

I think I agree although it depends on what you mean by "accept".  Assuming it's
something along the lines of messages that you plan to deliver unless they have
some other spam sign, that seems reasonable.

Another way to look at it is that anyone who would go to the effort of adding fake
ARC seals to try to evade spam filters will be doing other bad stuff so you'll
catch them soon enough.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Sep 2021 10:41:44 +0200

> some other spam sign, that seems reasonable.

Except that phishing messages, formally from BANK.example, with failed 
DKIM and SPF validation, are going to make it to the user's INBOX, 
despite the p=reject mark the bank put on their record.  That position 
relegates both protocols, DMARC and ARC, to the rank of futile 
programming exercises.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2021 15:47:11 -0400

>DKIM and SPF validation, are going to make it to the user's INBOX,

Why do you think so?

If someone sends a phish to a mailing list which adds genuine ARC headers,
those headers will record that the phish failed DMARC alignment when it
arrived at the list, and receivers can filter appropriately.

Surely we don't have to explain that valid ARC doesn't mean that you always
deliver a message, any more than valid DKIM or aligned DMARC does.

R's,
JOhn

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Sep 2021 10:46:01 +0200

> arrived at the list, and receivers can filter appropriately.

I was thinking of someone forging a phish and sending it directly to 
the victim.  The phish has an invalid DKIM signature by BANK.example 
and a valid ARC set which says the BANK signature was valid when it 
reached the forwarder.  Fake assertions about SPF, forged Received: 
and the like, possibly also an X-MIME-Autoconverted or similar hint at 
what might have invalidated DKIM are all in place.

> deliver a message, any more than valid DKIM or aligned DMARC does.

Right, that phish must not be delivered.  However, the message was 
accepted by an intermediary, and since the ARC header set inserted by 
that intermediary passed your validation checks, you automatically 
trust it.  On what element would you base, then, the decision to not 
deliver it?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2021 08:25:23 -0400

> I was thinking of someone forging a phish and sending it directly to the 
> victim.  The phish has an invalid DKIM signature by BANK.example and a valid 
> ARC set which says the BANK signature was valid when it reached the 
> forwarder.

As I said a few messages ago, if they do that, they are likely doing other 
bad stuff and the sender will have a bad reputation.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Sep 2021 13:06:01 +0200

On Tue 28/Sep/2021 14:25:23 +0200 John R Levine via Arc wrote:
>> ARC set which says the BANK signature was valid when it reached the forwarder.
> 
> As I said a few messages ago, if they do that, they are likely doing other bad 
> stuff and the sender will have a bad reputation.

That's an essential addition to the idea Todd proposed:

     "If you accept a message from an intermediary, you trust that any ARC
      header set inserted by that intermediary that passes your validation
      checks[*] contains information that is true and correct."

     [*] NOTE: Validation checks for ARC are not limited to formal cryptographic
     verifications, but MUST include assessing the intermediary against a
     reliable reputation database.

That note characterizes ARC as a sort of reputation accounting tool for use by 
global mailbox providers.  Certainly not a generic means to cure DMARC effects 
on indirect mail flows.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 29 Sep 2021 15:46:24 -0400

>    [*] NOTE: Validation checks for ARC are not limited to formal > cryptographic

No, that's not what he said.  Trying to rewrite other people's messages is 
not helpful.

Regards,

---

From: Todd Herr <[email-masked]>
Date: Thu, 30 Sep 2021 08:55:10 -0400

> No, that's not what he said.  Trying to rewrite other people's messages is
John is correct; the NOTE added here has nothing to do with my proposal.

The "validation checks" to which I referred in my proposal are those that
are currently described in RFC 8617, Section 5.2 -
https://datatracker.ietf.org/doc/html/rfc8617#section-5.2 - no more, no
less.

The decision by a server to accept a message from a client is made based on
whatever criteria the operators of that server establish. My proposal is
simply:

   - IF you accept a message from a client, AND
   - IF that client has inserted an ARC header set that passes validation
   checks (RFC 8617 Section 5.2), THEN
   - The information in that header set (and any previously-inserted header
   sets that pass validation checks) must be accepted by you to be true and
   correct

Note that "true and correct" does not mean:

   - The message isn't spam
   - The message passed previous authentication checks; dmarc=fail is
   information that can appear in an ARC header set and be true and correct

--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Sep 2021 19:30:49 +0200

On Thu 30/Sep/2021 14:55:10 +0200 Todd Herr via Arc wrote:
>       sets that pass validation checks) must be accepted by you to be true
>       and correct

Where would you insert John's objection about sender reputation?  I'd propose 
after accept, because servers who don't have a reliable reputation database 
need to accept messages from unknown senders.  For example, like so:

    - IF you accept a message from a client, AND
    - IF you can swear the client is not malicious, AND
    - IF that client has inserted an ARC header set that passes validation
      checks (RFC 8617 Section 5.2), THEN
    - The information in that header set (and any previously-inserted header
      sets that pass validation checks) must be accepted by you to be true
      and correct

Swearing about the client is not quite practicable, but I don't know how to 
express assessment so as to include 0-day exploits, such as a trusted server 
having just been compromised.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Thu, 30 Sep 2021 13:40:54 -0400

> need to accept messages from unknown senders.  For example, like so:
I have reviewed the thread, and for the life of me I can't find something I
would call "John's objection about sender reputation". Can you point it out
to me, please?

> having just been compromised.
The locally-known reputation of the client is factored into the decision to
accept the message, and has nothing itself to do with ARC, in my opinion.

I would expect senders without a locally-known reputation to be judged
differently from those with a locally-known good reputation and from those
with a locally-known bad reputation, in that unknown senders should be
treated as suspicious until proven otherwise by your users (e.g., route all
mail to spam until your users tell you it's not spam, perhaps). That
suspicion may, and probably should, carry over to your trust in any ARC
header sets inserted by the previously unknown sender.

--