Subject: [arc] ARC path header

From: Wei Chuang <[email-masked]>
Date: Thu, 9 Sep 2021 21:46:22 -0700

Hi all,

I think one of the key stumbling blocks for ARC is what to do about
building an intermediate forwarder reputation system so I wanted to pose a
conceptual idea to build this.  The essential idea is to build out an
authenticated path as defined by the originator.  It's probably easiest to
illustrate this as an example below where the message is being sent from
gmail -> googlegroups -> outlook.  Just to distinguish this proposal from
ARC, I've prepended a ARC++ header prefix to denote proposed header changes
as well as bolded key properties to be checked for.

1) Origination

From: [email-masked]

To: [email-masked]

Arc++-path: i=0; s=gmail.com ; d=googlegroups.com;

Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass;

        d=gmail.com; s=arc-20160816; b=ABCD...Z

2) Mailing list

From: [email-masked]

To: [email-masked]

Arc-Authentication-Results: i=1; arc++=pass (....)

Arc-Seal: i=1; a=rsa-sha256; t=1628539508; cv=pass;

        d=googlegroups.com; s=arc-20160816; b=ABCD...Z

Arc++-path: i=1; s=googlegroups.com ; d=outlook.com;

Arc++-path: i=0; s=gmail.com ; d=googlegroups.com;

Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass;

        d=gmail.com; s=arc-20160816; b=ABCD...Z

2) Recipient

From: [email-masked]

To: [email-masked]

Arc-Authentication-Results: i=2; arc++=pass (....)

Arc-Seal: i=2; a=rsa-sha256; t=1628539509; cv=pass;

        d=outlook.com; s=arc-20160816; b=ABCD...Z

Arc-Authentication-Results: i=1; arc++=pass (....)

Arc++-path: i=1; s=googlegroups.com ; d=outlook.com;

Arc-Seal: i=1; a=rsa-sha256; t=1628539507; cv=pass;

        d=googlegroups.com; s=arc-20160816; b=ABCD...Z

Arc++-path: i=0; s=gmail.com ; d=googlegroups.com;

Arc++-Seal: i=0; a=rsa-sha256; t=1628539507; cv=pass;

        d=gmail.com; s=arc-20160816; b=ABCD...Z

There would also be a Arc-Message-Signature header dropped for
readability.  Also note that the originator generates an ARC set to
establish the path.  In practice, likely the path key-value could be
subsumed by some other ARC header.

This example works by establishing a path from the FROM sender domain to
the destination in order to show the intent for each sender to go along
this path to be trusted by the destination.  Here it is gmail.com ->
googlegroups.com -> outlook.com.  Each hop signed for themselves and the
intended next hop recipient domain.  All recipients should be able to
validate the path up to that point by checking the signatures, and then
matching the source and destination for each edge in the path.   Validate
the ARC chain. Also the timestamps must be approximately increasing and
within some rough time guardband, to check there wasn't a replay attack.  A
valid path can be used as an authentication input to DMARC to show the
intent of the FROM domain sender for the purposes of applying domain
policy.  Then do normal spam checking on message content, and quantify this
to create a reputation signal.  Apply the reputation for the sender and
intermediates domains along that path.  That reputation signal might be
used in aggregate when the path authentication isn't established by the
originator but can fall back to regular ARC, to determine when the
intermediates are considered trustworthy.

Feedback is very much welcome.

-Wei

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2021 14:59:28 -0400

It appears that Wei Chuang  <[email-masked]> said:
>this path to be trusted by the destination. ...

I proposed a somewhat similar idea for DKIM in 2015 which was rather
thoroughly rejected in favor of ARC.

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Figuring out all of the downstream forwarders for which a sender needs
to set an intent tag is no easier than a receiver figuring out the upstream
forwarders with credible ARC chains.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Sat, 11 Sep 2021 10:54:44 -0700

> https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

I agree this path building concept in your draft is the same as what's
being proposed in the OP, and agree with the intent of your draft.  Both
are trying to use signed header signatures that form a path to protect
against replay attacks.  There are differences too and they are: The OP
proposal builds upon ARC.  The advantage of doing that is there is some
infrastructure already deployed which makes a small modification easier to
deploy at some later time.  The ARC set provides a convenient way of
defining a node in a path and the ARC header sealing is likely more
tolerant of changes in the message.  That said, your draft's notion of
"weak" (or rather further specialization of) signatures for headers likely
provides greater security.

I think we should revisit both approaches or some hybrid with respect to
making further progress with mail authentication that's tolerant of
forwarder modifications.

> forwarders with credible ARC chains.

Agreed figuring out the full path from the originators point of view is
impossible.  But each hop knows the next destination(s), and the path can
be built and identified via headers incrementally.  And from the
perspective of applying DMARC policy, I argue that it's sufficient to see
that the originator intended to send the message down that particular path
(assuming that the path signatures are valid).  Of course some intermediary
might be malicious and so the receiver still must do spam filtering.

-Wei

---

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

> be built and identified via headers incrementally.

Sure, give or take grouping by MX since MX lookups can happen fairly late 
in the process.  But the problem is that every one of these approaches 
depends on an external table saying when to use it.

For your approach and mine, each sending system needs a list of recipient 
systems that are likely to edit and forward mail, and also what signature 
it'll apply if it's not the same as the recipient address.  I suppose you 
could add it to every outgoing message using the recipient address domain 
but I think you'd still have a fair number of cases where the signature 
from the forwarder is different.

For ARC as it stands now, each receiving system needs to keep a list of 
what I call credible forwarders, systems well enough behaved that you can 
believe their ARC chains.  At least on a small system like mine, you 
follow the ARC chain and if you find one with a better DMARC result, you 
use it.

My point is that compiling any of these lists wlll be roughly the same 
amount of work, and the credible forwarders have the advantage of working 
with ARC as currently implemented.

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

---

From: Wei Chuang <[email-masked]>
Date: Sun, 12 Sep 2021 09:27:01 -0700

> from the forwarder is different.

I am probably missing something here.  Why is this list of trusted
recipients a prerequisite?  I propose that this path based authentication
can help discover these intermediary domains at scale that otherwise might
be rejected due to DMARC.  That process starts without any trust on these
intermediaries but over time can build reputation/history.  In the
meanwhile it depends much more on spam filtering.  With sufficient
reputation/history these domains might be promoted to being trusted so that
they might be used as ARC intermediaries when the path authentication
doesn't form a full chain.  I also propose that the path can be used for
domain authentication even without that trust prerequisite.

Another way to look at this is via threat modeling.  (And please correct me
where I am mistaken, as I've only recently looked into this.)  With ARC,
we have to trust that intermediary to provide a valid authentication result
meaning a malicious domain could forge the authentication result as coming
from some victim originator as well as the headers for it.  They could then
correctly seal the AAR, etc that could wrongly cause a DMARC policy pass.
So for ARC, having a trustworthy intermediary domain is important, hence
the need for a trusted list of intermediaries/credible forwarders ahead of
send time.

Path based authentication establishes that a message travelled from the
originating FROM domain to the receiver.  Malicious senders outside of the
path wouldn't be able to inject a message pretending to be that FROM
originator sending a  message along that path.  And from my granted limited
understanding of what domain authentication is trying to do in general, it
is trying to protect against those types of spoofed originator attack.  It
takes what once was a trivial attack, and makes it harder.  Path
authentication is vulnerable to some malicious intermediary on the path,
but that is a higher bar now.  Path authentication also says nothing about
valid content, and consequently it still must depend on spam filtering (but
so does any other domain authentication technique.  And also there needs to
be more on header signing that your proposal speaks to). .

-Wei

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2021 13:48:04 -0400

It appears that Wei Chuang  <[email-masked]> said:
>recipients a prerequisite?

It's not, I suppose you could put a forwarding path on everything,
without trying to guess who's likely to forward. I do worry about
replay attacks: find a forwarded message somewhere, splice the
original headers onto a malicious body, and send it to the same
mailing list as the original. You can't tie the forwarding token to a
body checksum, since mailing lists change the body and aren't likely
to stop doing so.

In any event, I know the ARC group was aware of my DKIM proposal and
decided to do it the way they did. Dave Crocker or Brandon Long might
have some insights into why.

R's,
John

---

From: "Marc Bradshaw" <[email-masked]>
Date: Mon, 13 Sep 2021 16:38:55 +1000

As I have understood this proposal there still needs to be a method of evaluating the trustworthyness of the intermediaries. It differs fromn the status quo in moving that responsibility from the receiver onto the originator and each hop.
It's one thing for a sender (or intermediary) to know where it is sending a message to, but quiet anther to make any determination of the trustworthyness of that arc sealer.

I may know that I'm sending a message on to foo.com, and may know they are a forwarder or mailing list, but once that hop changes a message there still needs to be established trust that those modifications are reasonable. That is the major hurdle for ARC and I don't think that this proposal helps.

For example, to expand on your earlier mailflow.

> 1) Origination
> 
> From: someuser@*gmail.com*
> 
> Arc++-path: i=0; s=*gmail.com* ; d=googlegroups.com;
> 
> Arc++-Seal: i=0; a=rsa-sha256; *t=1628539507*; cv=pass;
> 
>         d=*gmail.com*; s=arc-20160816; b=ABCD...Z
> 
> 2) Mailing list
> 
> From: [email-masked]
> 
> Arc-Seal: i=1; a=rsa-sha256; *t=1628539508*; cv=pass;
> 
>         d=*googlegroups.com*; s=arc-20160816; b=ABCD...Z
> 
> Arc++-path: i=0; s=gmail.com ; d=*googlegroups.com*;
> 
> Arc-Seal: i=2; a=rsa-sha256; *t=1628539509*; cv=pass;
> 
>         d=*outlook.com*; s=arc-20160816; b=ABCD...Z
> 
> Arc++-path: i=1; s=googlegroups.com ; d=*outlook.com*;
> 

If [email-masked] was a member of the example-group, and had a forward setup to evilforwarder.example.com, would we see an arc set with s=gmail.com d=evilforwarder.example.com set by google groups.
evilforwarder.example.com could then replace the message body entirely, reseal the message and pass it on to a recipient with intact ARC headers.
If the proposal is that the ARC seal includes the recipient domain regardless of a determination that that domain is somehow trusted then I (as a receiver) can't trust any of this.

Either the sender and every intermediary needs to maintain a list of trusted forwarders it may send to, or each ARC processor needs to maintain a list of trusted forwarders it may receive mail from.

On Mon, 13 Sep 2021, at 3:48 AM, John Levine via Arc wrote:
> -- 
> Arc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/arc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>

---

From: Wei Chuang <[email-masked]>
Date: Mon, 13 Sep 2021 09:21:02 -0700

> body checksum, since mailing lists change the body and aren't likely

I propose checking timestamps to look for and prevent some basic replay
attacks, and depends on spam filtering to handle other scenarios.  Yes, you
could argue for additional authentication on the message body, but such
proposals to do that are much more complex that arguably would not help
many mail forwarders and receivers.  (IMHO There are good ideas out there
for that e.g draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/>)  Like
you say because body modifications happen in legitimate mail flow by
mailing lists and other forwarders, and this proposal is intentionally
scoped to just solve the mailing lists with DMARC issue (as well as the
other legitimate forwarders).

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Mon, 13 Sep 2021 09:46:56 -0700

On Sun, Sep 12, 2021 at 11:39 PM Marc Bradshaw via Arc <[email-masked]> wrote:

> As I have understood this proposal there still needs to be a method of
> evaluating the trustworthyness of the intermediaries. It differs fromn the
> status quo in moving that responsibility from the receiver onto the
> originator and each hop.
> It's one thing for a sender (or intermediary) to know where it is sending
> a message to, but quiet anther to make any determination of the
> trustworthyness of that arc sealer.
>

Actually it's proposing that the path authentication is sufficient for
DMARC policy checks.  It still asks the receivers (i.e. both the final
destination as well as the intermediates) to spam filtering.  In the case
of intermediates determines whether to forward the message, which helps
protect its reputation.  All receivers ought to score the results to create
some sort of domain reputation filtering that can be applied as part of the
spam filtering as well as for using the ARC authentication results when a
path can't be formed, and the intermediate's trustworthiness is needed to
determine whether to trust the authentication result from that intermediate.

>
> I may know that I'm sending a message on to foo.com, and may know they
> are a forwarder or mailing list, but once that hop changes a message there
> still needs to be established trust that those modifications are
> reasonable. That is the major hurdle for ARC and I don't think that this
> proposal helps.
>
> From: someuser@*gmail.com <http://gmail.com>*
>
> Arc++-path: i=0; s=*gmail.com <http://gmail.com>* ; d=googlegroups.com;
>
>         d=*gmail.com <http://gmail.com>*; s=arc-20160816; b=ABCD...Z
>
> 2) Mailing list
>
> From: [email-masked]
>
>         d=*googlegroups.com <http://googlegroups.com>*; s=arc-20160816;
> b=ABCD...Z
>
> Arc++-path: i=0; s=gmail.com ; d=*googlegroups.com
> <http://googlegroups.com>*;
>
>         d=*outlook.com <http://outlook.com>*; s=arc-20160816; b=ABCD...Z
>
> Arc++-path: i=1; s=googlegroups.com ; d=*outlook.com <http://outlook.com>*
> ;
>
> If [email-masked] was a member of the example-group, and had a
> forward setup to evilforwarder.example.com, would we see an arc set with
> s=gmail.com d=evilforwarder.example.com set by google groups.
> evilforwarder.example.com could then replace the message body entirely,
> reseal the message and pass it on to a recipient with intact ARC headers.
> If the proposal is that the ARC seal includes the recipient domain
> regardless of a determination that that domain is somehow trusted then I
> (as a receiver) can't trust any of this.
>
> Either the sender and every intermediary needs to maintain a list of
> trusted forwarders it may send to, or each ARC processor needs to maintain
> a list of trusted forwarders it may receive mail from.
>

This proposal is intentionally scoped to just solve the mailing lists with
DMARC issue (and other legitimate forwarders modifications)
As noted in the other thread, there are good ideas out there for enabling
checks of the legitimacy of the body modifications (e.g
draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/>)  My
worry is that those solutions are very complex and will may actually hinder
adoption of any solution to resolve the immediate and broad problem of
DMARC false rejection due to mailing list forwarding.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 13 Sep 2021 13:51:59 -0400

>> original headers onto a malicious body, and send it ...

> attacks, and depends on spam filtering to handle other scenarios.

I don't think timestamps would help.  If I were a bad person, I would find 
a list with a public archive or maybe just subscribe, and then replay 
messages a minute after they arrive.  In my DKIM approach I assumed it 
would sign the message-id, since you can fairly safely drop duplicate 
messages with the same ID, but I don't think many lists do that.  It'd be 
yet another game of cat and mouse.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2021 15:32:19 -0400

It appears that Marc Bradshaw  <[email-masked]> said:
>I may know that I'm sending a message on to foo.com, and may know they are a forwarder or mailing list, but once that hop changes a message there still needs to be
>established trust that those modifications are reasonable. That is the major hurdle for ARC and I don't think that this proposal helps.

Not really. If you know that foo.com runs mailing lists that your
users subscribe to, the chances that it will suddenly turn evil are
pretty low.

One time I asked one of the authors of ARC why they don't just
whitelist mail from known mailing lists. They said the problem is that
lists do lousy spam filtering, and legit lists leak bursts of spam all
the time. For example, spammer steals someone's address book and
starts sending spam to a mailing list with a From: that happens to be
a subscriber. Most lists only check the From: address and let the spam
through. ARC lets the final recpient peek back and see whether a
message was DMARC aligned when it arrived at the list. Real mail from
the sender would be, the spam wouldn't. 

Note that this isn't something for which the original sender can
provide much help, since the spammer will always say as much as it can
"I am legit, let me through."

R's,
John

PS: I should tweak my list software to moderate or reject incoming
mail with DMARC failures, since at that point, it's pretty much 100%
spam.

---

From: "Marc Bradshaw" <[email-masked]>
Date: Tue, 14 Sep 2021 06:44:52 +1000

On Tue, 14 Sep 2021, at 2:21 AM, Wei Chuang via Arc wrote:
> 
> I propose checking timestamps to look for and prevent some basic replay attacks, and depends on spam filtering to handle other scenarios.  Yes, you could argue for additional authentication on the message body, but such proposals to do that are much more complex that arguably would not help many mail forwarders and receivers.  (IMHO There are good ideas out there for that e.g draft-kucherawy-dkim-list-canon <https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/>)  Like you say because body modifications happen in legitimate mail flow by mailing lists and other forwarders, and this proposal is intentionally scoped to just solve the mailing lists with DMARC issue (as well as the other legitimate forwarders).   
>  

I don't feel that replay attacks are the issue. A reasonably placed attacker could inject bad mail into a flow almost instantaneously, while legitimate mail could be delayed for long periods if, for example, a list server held it for moderator approval.

--

  Marc Bradshaw

---

From: "Marc Bradshaw" <[email-masked]>
Date: Tue, 14 Sep 2021 06:53:22 +1000

> users subscribe to, the chances that it will suddenly turn evil are

If you know that, then you have some already done some work in establishing a list of trusted sealers, and we are back where we started.

--

  Marc Bradshaw

---

From: Wei Chuang <[email-masked]>
Date: Mon, 13 Sep 2021 13:55:13 -0700

On Mon, Sep 13, 2021 at 1:45 PM Marc Bradshaw via Arc <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/>)
> Like you say because body modifications happen in legitimate mail flow by
> I don't feel that replay attacks are the issue. A reasonably placed
> attacker could inject bad mail into a flow almost instantaneously, while
> legitimate mail could be delayed for long periods if, for example, a list
> server held it for moderator approval.
>

Except that the originator intended for the mail to go along that path to
the attacker.  So from the perspective of applying DMARC policy, we would
say the message was intended and should pass DMARC, even if ultimately it
was malicious.  The proposal identifies such a path, and also asks for spam
filtering to detect malicious modified messages because it acknowledges
this limitation that comes with accepting mailing list and other legitimate
body modifications.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 13 Sep 2021 17:07:03 -0400

>> users subscribe to, the chances that it will suddenly turn evil are pretty low.
>

Since it is easy to fake an ARC chain beyond the most recent link, it was 
always clear that ARC is only interesting on mail from sources that are 
generally credible.

There were some sporadic attempts to crowdsource a set of mailing list 
sites but as far as I know they never went anywhere.

Regards,

---

From: Todd Herr <[email-masked]>
Date: Tue, 14 Sep 2021 13:03:53 -0400

> the sender would be, the spam wouldn't.

This kind of thing makes me think that people are tying signer/sealer
reputation to the quality of mail that they're signing and forwarding, and
I just don't understand that approach.

To my mind, signer/sealer reputation should be determined based on whether
or not one feels it can trust the authentication results being reported by
the signer/sealer. In private conversations with some mailbox providers,
I've proposed an idea that signer reputation can be measured by comparing
the reputation earned by authenticated indirect mail flows to authenticated
direct mail flows. At a rudimentary level, that would look like this:

   - Domain D sends some quantity of mail directly to Mailbox Provider M,
   and D earns a reputation for its authenticated mail; call this R1
   - ARC signer/sealer S is an intermediary on some quantity of mail that
   originated at D and is ultimately delivered to M, and D earns a reputation
   for mail that was successfully authenticated as reported by S; call this R2
   - If and only if R1 and R2 are reasonably similar, then S can be trusted
   to have reported correct authentication results

This idea was shot down because it wouldn't scale, due to too many paths to
keep track of, what with the endless number of originating domains that a
large mailbox provider might see, but I still believe in the idea that
signer/sealer reputation should be based on the trustworthiness of its ARC
Header Sets and nothing else. I just haven't figured out a good way to
instrument and measure that trustworthiness.

Am I misunderstanding the discussion here, or am I wildy off base?

-- 

*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 R Levine" <[email-masked]>
Date: 14 Sep 2021 18:40:54 -0400

> I just don't understand that approach.

The interesting question isn't whether the forwarder is doing genuine 
sealing, it's whether you want the mail they send.  Sealing is merely a 
part of that.

Here's a thought experiment: someone sets up a copy of Mailman with ARC. 
Re Mark's concerns, it only add a List-ID, no other message modifications, 
and the ARC seals are all genuine.  And 100% of the mail it sends is spam. 
(I have enountered a few Mailman setups like this give or take the ARC 
bit.)  Do you accept its mail because of its perfect ARC seals and minimal 
message modification?  Of course not, it's sending spam and ARC doesn't 
change that.

As far as I can see ARC is useful for one narrow but important thing: if 
you have a forwarder that sends mostly mail your users want, but leaks 
some spam due to lousy filtering at its end, ARC can compensate for the 
lousy filtering and sort mail better than blindly following DMARC 
policies.  So you use ARC on forwarders that already have a good 
reputation.

By the way, trying to see if a host's seals are genuine by comparing the 
pass rate won't work.  A bad guy can seal whatever it wants with fake A-R 
results that match whatever ratio you're looking for.  If an ARC seal 
validates, that only means you're seeing the same seal the signer added, 
not that the seal reflected reality.

Regards,

---

From: Todd Herr <[email-masked]>
Date: Wed, 15 Sep 2021 08:57:22 -0400

> not that the seal reflected reality.

I have not considered ARC to be necessary to answering the question of "Do
I want the mail that this forwarder is sending me?" at least not in the
context in which you're presenting it.

I am long removed from the mailbox provider side, but I have always seen
this as the use case for ARC...

   - Message arrives, RFC5322.From domain is X
   - X publishes a DMARC policy record, and the message fails the DMARC
   validation checks that I perform
   - However, there is within the message one or more ARC header sets, and
   at least one of those header sets indicates that the message passed DMARC
   validation checks at a previous hop in its journey, signed and sealed by S
      - If I know S to be a source of truth for such signing and sealing
      (meaning I can trust that the message really did pass DMARC validation
      checks when S inserted its ARC header set), then I can reliably
know that X
      was the authentic source of the message, and I can apply whatever rules I
      have in place to treat the message in a manner that is
consistent with the
      reputation X has earned at my site.
      - If I do not know S to be a source of truth for signing and sealing,
      then I must treat the message as if it failed DMARC validation checks
   - If there are no ARC header sets in the message, then I must treat the
   message as if it failed DMARC validation checks

The open question for me, of course, is how does S establish itself to me
as a source of truth for the information contained in its ARC header sets,
and the above probably really only works if there is one ARC header set for
every intermediary that handled the message, but this is where my brain
lands when thinking about ARC.

Note that I'm not arguing here that my interpretation of ARC is correct;
it's just how I've interpreted the Abstract from 8617:

   The Authenticated Received Chain (ARC) protocol provides an
   authenticated "chain of custody" for a message, allowing each entity
   that handles the message to see what entities handled it before and
   what the message's authentication assessment was at each step in the
   handling.

   ARC allows Internet Mail Handlers to attach assertions of message
   authentication assessment to individual messages.  As messages
   traverse ARC-enabled Internet Mail Handlers, additional ARC
   assertions can be attached to messages to form ordered sets of ARC
   assertions that represent the authentication assessment at each step
   of the message-handling paths.

   ARC-enabled Internet Mail Handlers can process sets of ARC assertions
   to inform message disposition decisions, identify Internet Mail
   Handlers that might break existing authentication mechanisms, and
   convey original authentication assessments across trust boundaries.

--

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2021 15:28:54 -0400

>   validation checks at a previous hop in its journey, signed and sealed by S

So far so good.

>      checks when S inserted its ARC header set), then I can reliably know that X
>      have in place to treat the message in a manner that is consistent with the

Nope.  

You know that the message originally came from X but you do not know
what S did with it.  The message reputation can't be better than X's
reputation but depending on what S does, it could be much worse.

Let's adjust my example a little: it picks up real mail from
somewhere, replaces the bodies with ransomware, and sends it out with
genuine ARC seals. The reputation of X was fine, but S is very not
fine.

The message reputation is min(S,X). That's why ARC is only useful if S
has a good reputation, and you can't tell that by looking at ARC
seals.

R's,
John

---

From: Todd Herr <[email-masked]>
Date: Wed, 15 Sep 2021 16:00:51 -0400

> has a good reputation, and you can't tell that by looking at ARC
I'm doing a poor job of getting my idea across, or perhaps I'm doing a good
job and you're rejecting it, but I'm going to try one more time...

I'm not proposing that S's reputation be directly driven by the content of
its seals; rather, I'm proposing that S's reputation be driven by the
reputation X gathers through its indirect mail flow (call it XI) that is
sealed by S, when compared to the reputation X gathers through its direct
mail flow to me (call it XD).

   - XD will be calculated based on authenticated mail sent directly to me
   from X. Doesn't matter what the reputation is, only that it establishes one
   in this fashion.
   - XI will be calculated based on mail claimed to be authenticated
   through S's sealing. Again, doesn't matter what the reputation is, only
   that it establishes one.
   - If XD and XI are similar (by my definition of "similar" based on how I
   calculate sender domain reputation), then I know I can trust S to properly
   seal X's mail, because the quality of X's mail is the same whether it's
   direct or indirect through S. Doesn't necessarily mean that I'll place it
   in the Inbox or even accept it, because if X's reputation is bad, it'll
   still be subject to the "Your mail is bad and you should feel bad"
   treatment, but I have established that S can be trusted for this
   mailstream, I think.
   - If XI is demonstrably worse than XD, then I likely cannot trust S to
   properly seal X's mail (and maybe can't trust S at all)
   - If XI is demonstrably better than XD (something I think likely when X
   is a mailbox provider and S is a well-run mailing list server) then I
   likely can trust S to properly seal X's mail.
   - At some point, if S has shown itself worthy of trust to reliably seal
   mail from many domains, then I know I can trust S to seal all mail, but
   I'll keep monitoring things

As I said in an earlier post, though, it's likely this won't scale because
there are too many X's to keep track of.

--

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2021 02:15:50 -0400

It appears that Todd Herr  <[email-masked]> said:
>   direct or indirect through S. ...

Oh. I see what you're saying.  I suppose it would work although it'd be hard to
tell from a perverse setup where S rejected all of the unaligned mail from X
and a lazy programmer put a fake seal on everything.  I realize that's unlikely.

So here's my low(ish) tech counterapproach.  If a mail source has a generally
good reputation, assume its ARC seals are real.  What's the downside?

R's,
John

---

From: "Marc Bradshaw" <[email-masked]>
Date: Thu, 16 Sep 2021 22:12:24 +1000

The originator indended for A message to be sent along that part of the path,  But if a bad actor maliciously modified it en route they may not have indended that the message arrived at the destination as it was when it arrived.
If we can't trust that a modification made by an intermediary was legitimate we surely cannot make any judgement about what DMARC policy should or should not be applied.
Spam and maliciousness filtering is a side issue. I have said before, and will keep saying. A good forwarder can and will forward bad messages, this isn't about the quality of mail, it is about wether or not we believe that an intermediary which modifies messages makes only reasonable and legitimate modifications.

On Tue, 14 Sep 2021, at 6:55 AM, Wei Chuang via Arc wrote:
>> __
> Except that the originator intended for the mail to go along that path to the attacker.  So from the perspective of applying DMARC policy, we would say the message was intended and should pass DMARC, even if ultimately it was malicious.  The proposal identifies such a path, and also asks for spam filtering to detect malicious modified messages because it acknowledges this limitation that comes with accepting mailing list and other legitimate body modifications.
> 
> -Wei
>  
>> 
>> 
>> --
>> 
>>   Marc Bradshaw

--

  Marc Bradshaw

---

From: "Marc Bradshaw" <[email-masked]>
Date: Thu, 16 Sep 2021 22:18:07 +1000

This is how I approach reputation for ARC. We're just not seeing enough mail which is ARC sealed, modified, and not from the top senders we all already know and have reputation for. The volume right now is so low it isn't feasable to apply any automated reputation. This may be a chicken and egg thing.

On Wed, 15 Sep 2021, at 3:03 AM, Todd Herr via Arc wrote:
> This kind of thing makes me think that people are tying signer/sealer reputation to the quality of mail that they're signing and forwarding, and I just don't understand that approach.
> 
> To my mind, signer/sealer reputation should be determined based on whether or not one feels it can trust the authentication results being reported by the signer/sealer. In private conversations with some mailbox providers, I've proposed an idea that signer reputation can be measured by comparing the reputation earned by authenticated indirect mail flows to authenticated direct mail flows. At a rudimentary level, that would look like this:
>  * Domain D sends some quantity of mail directly to Mailbox Provider M, and D earns a reputation for its authenticated mail; call this R1
>  * ARC signer/sealer S is an intermediary on some quantity of mail that originated at D and is ultimately delivered to M, and D earns a reputation for mail that was successfully authenticated as reported by S; call this R2
>  * If and only if R1 and R2 are reasonably similar, then S can be trusted to have reported correct authentication results
> This idea was shot down because it wouldn't scale, due to too many paths to keep track of, what with the endless number of originating domains that a large mailbox provider might see, but I still believe in the idea that signer/sealer reputation should be based on the trustworthiness of its ARC Header Sets and nothing else. I just haven't figured out a good way to instrument and measure that trustworthiness.
> 
> *Todd Herr *** | Technical Director, Standards and Ecosystem
> 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.
> 
> -- 
> Arc mailing list
> [email-masked]

--

  Marc Bradshaw

---

From: Todd Herr <[email-masked]>
Date: Thu, 16 Sep 2021 08:40:32 -0400

> good reputation, assume its ARC seals are real.  What's the downside?
I suspect that any system designed to measure signer/sealer reputation will
likely rely on multiple data sets, simply because of a lack of uniformity
on how identities are able to be established for intermediaries.

Your counter approach would seemingly work just fine for an intermediary
that has already established a domain-based reputation through DKIM signing
all mail it handles or rewriting the From header to use its domain rather
than the domain of the original sender. For those intermediaries that don't
leave fingerprints on mail they handle beyond Received headers, they'll
likely only have an IP-based reputation and so their domain-based seals may
be harder to automatically match to the traffic seen. Not impossible given
enough resources, but that's pretty much true for everything we say about
tracking ARC reputation.

--

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2021 15:13:49 -0400

It appears that Marc Bradshaw  <[email-masked]> said:
>-=-=-=-=-=-
>
>This is how I approach reputation for ARC. We're just not seeing enough mail which is ARC sealed, modified, and
>not from the top senders we all already know and have reputation for. The volume right now is so low it isn't
>feasable to apply any automated reputation. This may be a chicken and egg thing.

So how about my lazy guy approach: if a source has a good reputation, assume it's ARC seals are real.  What's the downside?

If the reputation is good, it is unlikely to be making naughty changes with or without ARC.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Sat, 18 Sep 2021 10:56:33 -0700

On Thu, Sep 16, 2021 at 5:18 AM Marc Bradshaw via Arc <[email-masked]> wrote:

> This is how I approach reputation for ARC. We're just not seeing enough
> mail which is ARC sealed, modified, and not from the top senders we all
> already know and have reputation for. The volume right now is so low it
> isn't feasable to apply any automated reputation. This may be a chicken and
> egg thing.
>

What ARC traffic I see is from a few already very well known senders and
then a modest sized tail whose volume drops off very quickly.  Agree
that the low traffic rate in the tail will already make using automated
reputation difficult.  I worry the proposal will further segment that small
traffic volume.  Another issue I see is that while ARC is meant to override
mistaken DMARC policy enforcement, if ARC reputation has insufficient
volume to be applied, it may fall back to DMARC and some reject policy is
applied.  Such a domain may not be able to establish sufficient traffic
volume to change its reputation.

-Wei

>    - If and only if R1 and R2 are reasonably similar, then S can be
>    trusted to have reported correct authentication results
>
> This idea was shot down because it wouldn't scale, due to too many paths
> to keep track of, what with the endless number of originating domains that
> a large mailbox provider might see, but I still believe in the idea that
> *m:* 703.220.4153 <(703)%20220-4153>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Sep 2021 19:48:32 +0200

On Thu 16/Sep/2021 14:12:24 +0200 Marc Bradshaw via Arc wrote:
> A good forwarder can and will forward bad messages, this isn't about the 
> quality of mail, it is about whether or not we believe that an intermediary 
> which modifies messages makes only reasonable and legitimate modifications.

For a limited set of modifications and author's signatures following DKIM's 
Recommended Signature Content, it is feasible to undo the modifications and 
check the original author's signature:
https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform

Best
Ale
--

---

From: "Marc Bradshaw" <[email-masked]>
Date: Tue, 21 Sep 2021 15:31:50 +1000

I believe that draft-vesely-dmarc-mlm-transform needs some work before it can be applied at scale. The intent is good, but there are some issues. However this isn't the forum to discuss those. The issue still remains, a large number of good forwarders will make modifications outside of those in that draft, but those may still be legitimate modifications.

--

  Marc Bradshaw