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

[Tero Kivinen <[e-mail]>]

Brotman, Alex writes:
> Inline 

It would be nice to have some indication where inline you have
commented things, as now your text simply seems to be inline without
any markers which is your new text and which is original text.

Perhaps using normal  '>' quoting would make reading your comments
easier (I tried to find your responses and changed them to have BA> in
front to mark them out). . 

> > > 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.
> 
BA> Which lie outside of the "experiment", and nothing the IETF does
BA> could stop that. If you want to misuse some specification, have at
BA> it.

I do not think it lies outside the experiment. Experiment is where we
try things and see which parts of the experiment works and which does
not. Experiment might not always be fully successfull we might also
get good results by finding out that some parts work and some does
not.

In this case I think we found out that Chain-part of the ARC does not
work.

But based on that I do not understand why people are still trying to
use the exactly same failing mechanism in DKIM2?

The ARC is more than just Chaining part, and some of those did
succeed, at least by my measurements. 

> > 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. 
> 
BA> I would say that DKIM2 has a far better chance than ARC ever did.  I
BA> think that goal largely depends on the actions/policies created at a
BA> later date by receivers.

I disagree. ARC did not require changes on the SMTP level, it can be
implemented trivially as milter, and there are multiple
implementations of it already.

The chain part did fail, because of the problem of getting everybody
to implement it. DKIM2 has exactly same problem, it do require
everybody to implement it to make it useful.


> 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. 
> 
BA> IMO, it does not work at Internet-scale, and does not provide a
BA> trustable mechanism.

There is two parts in ARC, signing and validation. Signing already
works fine on the internet-scale. There is lots of environments which
sign and generate ARC headers.

Validation happens on the final destination (per user mailbox filters,
as that is only place who knows which ARC headers should be trusted,
as user himself is only who who can provide that information), so even
that works on Internet-Scale, as it is completely distributed.

Trust mechanism comes from the user. User lists which services he has
requested to forward emails to him, i.e., which ARC signers are
expected to be signing messages to be forwarded to his mailbox. If the
user trusted the forwarding service enough to ask it forward messages
to him, he might also trust that service enough to trust its
authentication results headers.

If the user think that the service is not trustworthy enough, he
simply does not list that signer in trusted forwardes, and that
services emails are processed without that extra information about the
authentication results before forwarding.


> 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.
> 
BA> It has many of the same failings as DKIM, and in some cases, makes
BA> Authentication reliability worse. This has been stated by a few
BA> people on the list.

If people try to use the global trusted forwarders lists (which cannot
exists, as there is no such thing as global trust), then yes it can
cause issues. But that is not caused by ARC, that is caused by the
broken policy by the adminstrator.
-- 
[e-mail]