Re: [dmarc-ietf] ARC vs reject

The recent discussion has introduced two challenges to ARC:  first, that it
is too complicated, and second, that it opens up security holes that should
be unacceptable.    John's response appears to be that the technology will
only be used by a small group of lists in cooperation with a small group of
recipients, that the complexity will be a non-issue for the participants
and the risk, while present, will be mitigated by the limited scope of
participation.    All of this is problematic.

On security issues, we have to assume attacks by state-sponsored actors,
not just fortune seekers.   So the security challenge needs to be
thoroughly vetted.

But the participation assumption is even more worrisome.    If this is a
limited participation protocol, supported by a private but not-yet-created
communication network, then it does not solve the chair's requirement for a
general solution.

I ask the chairs to formally endorse development of an alternative to ARC
as an additional approach to the mailing list problem, a solution based on
reverse transformation.   Alessandro and Murray have submitted drafts.   It
is time to study their proposals and merge their work.

Doug Foster

On Sat, Dec 5, 2020 at 11:14 PM John R Levine <johnl@taugh.com> wrote:

> On Sat, 5 Dec 2020, Jim Fenton wrote:
> >> Of course not.  That's just the tiny gorillas stamping their teensy
> feet.
> >> Why would anyone expect that the people publishing that flag actually
> >> understood what it meant?  Many will just turn it on because someone
> said
> >> it's "more secure."
> >
> > FWIW, I don’t think a lot of the people publishing p=reject understood
> the
> > implications of that, either. This is not significantly more arcane.
>
> Then I think we agree.  There's no difference from p=reject and
> p=reject-I-really-mean it.
>
> > ... If the recipient domain accepts modifications by zero-reputation
> > intermediaries (because there are so many of them, after all)
>
> I wouldn't call that a reasonable implementation of ARC.  The set of hosts
> that are likely to send you mail with interesting ARC chains is relatively
> small, and I don't think it changes very fast.  Most of the hosts that
> send you non-spam mail aren't going to send you mail that needs ARC.
>
> If you're setting up a new mailing list host or forwarder, getting
> yourself into whatever whitelists people use will be somewhat painful but
> there's nothing new about that.
>
> > I’d be interested in other opinions on this. Or whether this is a
> fundamental
> > problem with ARC.
>
> I'd certainly be interested in hearing how people plan to compile and
> maintain their lists of ARC-worthy hosts.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>