[dmarc-ietf] Re: New Tack - Learning from ARC Experiment

[Tero Kivinen <[e-mail]>]

Brotman, Alex writes:
> 
> > Labeling ARC "historic" before DKIM2 proves itself as a
> > replacement would serve no good purpose.
> 
> It might prevent people from deploying a mechanism that most have
> decided serves no true purpose in its current form.

It might also make people not deploy mechanism that some people have
decided are useful and provide useful information, even when that is
not what ARC RFC specifies. 

> Take a look at Section A.1 in RFC8617, and ask if we believe that
> ARC (the experiment) has satisfied those goals.

The first bullet:

   o  Provide a verifiable "chain of custody" for email messages;

has not been satisfied, and I argue it was impossible from the
beginning, exactly same way as DKIM2 will be impossible. To get that,
would require that we would need to update all servers participation
in the mail chain, and that is impossible.

All other goals have been mostly met:

   o  Not require changes for originators of email;

   o  Support the verification of the ARC header field set by each hop
      in the handling chain;

   o  Work at Internet scale; and

   o  Provide a trustable mechanism for the communication of
      Authentication-Results across trust boundaries.

ARC does not require changes in originators. It does support
verification of the ARC header for those hops who set it (there is no
chain). It does work on internet scale and it does provide trustable
mechanism for communication of Authentication-Results from
intermediately node to the end node.

> I'm not suggesting there could not be a DKIM2 or ARC++ that revises
> what exists today and makes it better, but this document, RFC8617,
> is not what the email ecosystem needs to create a reliable
> chain-of-custody.

Anything that tries to do chain-of-custody, or forces every
intermediate nodes to change (DKIM2) will be failing on internet
scale. There will be nodes for not supporting those handling emails
for very very long time.

> Marking it as historic won't necessarily stop implementations or
> deployments, though hopefully gives them serious pause. We had been
> running ARC inbound for ages, and determined that due to the
> various/differing ways that it was being used at other sites, it
> just wasn't useful enough to rely on. As such, as a site-to-site
> chain-of-custody, I see no value in what currently exists.

I think better plan is to remove the unachievable first bullet point
in goals list, and remove all concept of chain from the ARC and
publish it as standard track RFC.

I.e., remove following sections from the ARC RFC 8617:

2.3.  Chain of Custody
2.4.  Validation of Chain of Custody
4.3.  Authenticated Received Chain
4.4.  Chain Validation Status
5.1.3.  Only One Authenticated Received Chain per Message


and rewrite at least 5.2 (mostly just remove the chain properties,
leave the way to verify one ARC set):

5.2.  Validator Actions

section "7.  Use Cases" most likely also needs changes, i.e., most
likely some of those are no longer use cases, and there are some new
use cases.

Note, that the section 11.1 Success Considerations says:

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

ARC do provide that. When I see ARC header from iki.fi which do say
that SPF=pass, DMARC=pass when iki.fi received that email which is
then forwarded to me, then it will "allow for improved decision
making" and "better delivery rates ... heuristic approaches".

We did not get any failure conditions:

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

I at least do not know any new significant vectors for abuse cause by
ARC.
-- 
[e-mail]