[dmarc-ietf] Review of draft-ietf-dmarc-arc-to-historic

[Tero Kivinen <[e-mail]>]

Most of the text in the draft-ietf-dmarc-arc-to-historic is wrong.

First of all, it does not cover any of the topics listed in the ARC
RFC 8617 when considering whether the experiment was successfull.

If we are trying to see whether experiment is successfull, we should
first use the original goals to.

Section 11 of ARC RFC 8617 starts:
----------------------------------------------------------------------
11.  Experimental Considerations

   The ARC protocol is designed to address common interoperability
   issues introduced by intermediate message handlers.  Interoperability
   issues are described in [RFC6377] and [RFC7960].

   As the ARC protocol is implemented by Internet Mail Handlers over
   time, the following should be evaluated in order to determine the
   success of the protocol in accomplishing the intended benefits.
----------------------------------------------------------------------

I.e., this section 11 should be considered when thinking whether ARC
experiment succeeded or not.

Then it lists success considerations:
----------------------------------------------------------------------
11.1.  Success Consideration

   In an attempt to deliver legitimate messages that users desire, many
   receivers use heuristic-based methods to identify messages that
   arrive via indirect delivery paths.

   ARC will be a success if the presence of Authenticated Received
   Chains allows for improved decision making when processing legitimate
   messages, specifically resulting in equal or better delivery rates
   than achieved through the use of heuristic approaches.
----------------------------------------------------------------------

I think it succeeded in that. Almost all emails I receive have been
forwardered to me by some forwarders. I know those forwarders (iki.fi,
netbsd.org, ietf.org mailing lists, some other mailing lists).

Email forwarding does not happen without the user interaction, i.e. I
myself set up all of those forwardings and specified that those
domains should forward those emails to me.

When I receive email in my final mailbox I can use the ARC records
from iki.fi to see whether DKIM, SPF and/or DMARC succeeded when it
got the email. I do trust iki.fi so much that I allow it to forwarded
emails to me, thus I trust that iki.fi will do those checks properly.

The only interesting thing for the Chain is those machines that I
trust. I do not care if someone else forwarded email before iki.fi got
it, as I do not trust those. I only care about ARC headers that I know
I can trust.

Meaning the ARC was success as the precense of the ARC-records allowes
me for improved decision making when processing legitimate messages,
and checking those signatures is much better than heuristics using
Received headers or something like that.

Then next section of the section 11 of ARC RFC 8617 lists failure
considerations:

----------------------------------------------------------------------
11.2.  Failure Considerations

   ARC should function without introducing significant new vectors for
   abuse (see Section 9).  If unforeseen vectors are enabled by ARC,
   this protocol will be a failure.  Note that the weaknesses inherent
   in the mail protocols ARC is built upon (such as DKIM replay attacks
   and other known issues) are not new vectors that can be attributed to
   this specification.
----------------------------------------------------------------------

The draft does not list any significant new vectors for abuse caused
by ARC, and I do not know any of such things, so I assume there are
none.

(note that DKIM replay attacks are explictly listed as known attacks).

Section 11.3 then goes to Open questions, i.e., what we should have
learned from the experiment, but this draft does not answer those
either.


--

So the summary is the current draft does NOT at all use the original
sucecss / failure criteria to check whether experiment failed.

--

More detailed comments follow:

--

Abstract

I disagree that the experiment failed, and I do not think ARC should
be reclassified as Historic. I still think it has value and the
experment actually succeeded. It does provide better than heuristic
methods for the final recipient to validate the (known from outside
sources) ARC signer headers and use that information when processing
the email.

--

In the section 1 2nd paragraph there is text saying:


       	       	     	       	     	ARC's premise
   was that each handler could record its view of upstream
   authentication and then sign that record, enabling downstream
   evaluators to see what happened along the path.

I do not think the 2nd part was part of ARC's permise, i.e., "enabling
downstream evaluators to see what happened along the path". That might
be DKIM2's premise, but as ARC does not provide any such information,
ARC only allows downstream evaluators to validate
ARC-Authentication-Results headers generated by some hosts.

--

Section 1:

   This document reports the experiment's results and explains why, with
   the emergence of the proposed successor to DKIM, currently known as
   DKIM2, the community should retire ARC and incorporate the useful
   pieces directly into the successor to DKIM.

This is mostly wrong, as I explained earlier this document does NOT
report experiment's results.

I think DKIM2 will also fail, as it requires it to be implemented in
every single host that will be processing emails, and that is
unfeaseable on the internet scale. 

--

In section 2.1 the text does list forwarding party and author's domain
control, but it does not explain that the actual recipient of the
email did set up that forwarding or mailing list for himself, meaning
final recipient and forwarder do have relationship to each other, and
have some level of trust between.

--

Section 2.2 is ok, but section 2.3 again leaves out the fact that
final recipient do have trust relationship with the forwarder (if that
forwarding is something he/she actually wants). Meaning the text:


	      As such, without a robust reputation system, ARC in-
   and-of itself cannot convey trust in an email that fails DMARC.

there is no need for reputation system for ARC. There is NO global
reputation system that can work. I do not trust same forwarders that
someone else trusts. I can only list those trusted forwarders I myself
trust, I can't do that for anybody else.

--

Also in section 2.2:

   Another limitation of the design was that the ARC signature only
   indicated the intermediaries handling the message, but was silent
   about any changes the intermediaries made to the message.  As such, a
   fully validated ARC chain might include a modified message without
   the final evaluator knowing what changes were made.

I do not think that as a limitation of the ARC. It was not a goal of
ARC and I myself do not really think that it is important. When I get
email forwarded to me by ietf.org mailing list, I do not really care
what kind of changes they did before forwarding that to me. The fact
that ietf.org mailing list received the email, would have done SPF,
DKIM, and DMARC checks for the incoming email and would have in
ARC-Authentication-Results header should be enough for me to trust
that ARC-Authentication-Results (I say would here a ietf.org mailing
lists do not add ARC headers).

I think that paragraph should be removed.

--

In section 3.1 there is bullet:

   *  Internet-scale dependency on reputation: For broad
      interoperability, ARC required evaluators to run a reputation
      system for ARC signers.  Verifying the cryptography was necessary
      but insufficient; evaluators needed to decide whether to trust
      each signer in the chain before using their assertions to override
      DMARC outcomes.  This created a parallel trust infrastructure,
      separate from (but interacting with) existing domain or IP
      reputation.

The reputation system for ARC is very simple, when I set up the
forwarding from iki.fi or netbsd.org to forward email to my final
destination I add those domains to my trusted forwarders list.

Nothing else is needed.

--

In section 3.1 there is bullet:

   *  Limited reputation deployment:Even early deployers that validated
      ARC chains did not deploy robust, dynamic reputation.  Instead,
      they implemented 'allow lists' of intermediaries whose ARC
      assertions were always (or mostly) accepted.  This provided
      utility in specific bilateral or consortium relationships but did
      not scale to the open Internet.

This was correct way to implement reputation for ARC, it was not
limited reputation deployment. Only the final recipient can provide
the list of trusted forwarders. And note, this means final recipient
not the final mailbox provider. For two users in the same mailbox
providers the list of trusted forwarders is going to be different.
They might be subscribed to different set of mailing lists, meaning
one of them will trust some ARC signers that the other does not.

There is no per site, or global reputation possible with ARC.

--

In section 3.1 there is bullet:

   *  Complex evaluator policy: Receivers faced policy questions: how
      many hops of ARC to honor, how to treat partial or broken chains,
      how to reconcile conflicting assessments across chain links, and
      under what conditions ARC could influence DMARC enforcement.  The
      resulting diversity limited predictable interoperation across
      receivers.

I agree that the validation rules in the ARC RFC 8617 are bit complex,
but luckily the final recipient does NOT really care about the chain
properties of the ARC at all. The final recipient only cares whether
the trusted forwarder is in the list and what that hosts
ARC-Authentication-Results were.

--

In section 3.1 there is bullet:

   *  .....
		This reinforces that any
      intermediary authentication or chaining mechanism (such as ARC)
      must address the uncontrolled nature of forwarding, which spans
      countless unknown and dynamic systems, rather than only known
      mailing lists or enterprise relays.

Forwarding is never uncontrolled. If someone starts forwarding emails
to me I most likely do not want them, and they can end up in spam or
dropped. When I set up forwarding I do that for myself. When I join a
mailing list I need to do some actions to add myself to the mailing
list. When someone else adds me to some mailing list, I might agree or
disagree of being added to that mailing list, and if I agree that I do
want to get emails from that mailing list I can configure my trusted
forwarders accordingly, and if I disagree I will block those emails.

Remove that sentence.

--

In section 3.2 there is again talking about this "reputition system"
and there seems to be a feel that there should be one global list,
which is impossible as different people do trust different forwarders.

It is same as you complain that there should be global list of trusted
newspapers, that everybody can trust. There is no such thing. Trust is
not global it is from the forwarder to the final recipient (user).

Remove this:

						However,
   verifiable history without reputation does not enable safe override
   of DMARC or other enforcement policies.  Any Internet-wide solution
   must pair verifiable signals with a scalable, abuse-resistant trust
   model; ad hoc allow lists are not sufficient.


--

In section 3.3 I am not sure whether indication of modifications will
ever help. I do not think DKIM2 way of listing all modifications is
going to be helpful or harmful. They add lots of stuff to headers, and
for end users it is impossible to parse what was changed, and even if
you have user visible thing that shows what was changed, I am not sure
anybody is ever going to look those. But as those things are outside
the scope of ARC I thnk they do not need to be in this document
either.

I.e., remove 3.3.

--

In section 3.4 it would indicate that every node would be doing ARC
validation, but there is no need for that as the only machine that can
do ARC validation is the final end recipient machine, because he is
only one who has valid list of trusted forwarders, thus there is no
point of doing validations anywhere else than there.

I.e., remove 3.4.

--

As DKIM2 will be failing and DKIM replay was not part of ARCs goals,
listing DKIM2 as favored option is not needed, so remove section 3.5.

--

And of course my conclusions of the ARC experiment are very different.
I think it succeeded, and provided a better than heuristic way to make
decisions in the final recipient against the trust forwarders list of
the final recipient.
-- 
[e-mail]