Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Hector Santos <[e-mail]>]

On 8/16/2017 9:32 PM, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     While there exists A SINGLE SITE which is ARC-unaware and DMARC
>     p=reject aware, you can't use ARC on a DMARC p=reject domain
>     without rewriting the sender.  Otherwise that site will bounce the
>     email.
>
>     You still have to rewrite the sender until there is either full
>     adoption or sufficient adoption that you just don't care about the
>     stragglers.
>
>     ARC doesn't solve that unless every receiver is either ARC-aware
>     or DMARC-unaware.  Hence the suggestion that I think Hector is
>     making - to define a new policy p=rejectnonarc or something, which
>     means that sites which are ARC-unaware accept rather than reject.
>
>
> So this is an excellent and crucial point that has been discussed
> again and again on and off this list.
>
> ARC only works if critical mass can be reached - both of
> intermediaries who break DKIM and receivers who evaluate ARC.

Of course.  But in my opinion, the real problem, I thought, was 
finding a solution to the old DKIM Policy Model problem that began 
with SSP and ADSP, a proposed standard and now DMARC.  They all had 
the same issue. As a strong policy DKIM working group advocate, I was 
the one that illustrated the problem (the auto-unsubscribe issue).

DMARC did not resolve the reason ADSP was abandoned.  DMARC only 
obtained popularity first as a reporting mechanism which I thought was 
redundant.  It didn't prove anything beyond we already knew which was 
when a Strong Rejection was honored by receivers, it had a very high 
payoff value, so such, eventually, big domains supported it.  But it 
also eventually shows what we already knew what will happen -- it will 
cause mailing list "auto-unsubscribe" problems with accumulated failed 
Policy rejections.  This was well documented.

So if everyone supported some of the proposals which is far better 
than ARC to resolve this problem, then we would of ended this long 
time "project research" at least 4-6 years ago.

Right now, ARC is asking to stamp the mail with additional overhead. 
Its the first time I believe, that attempts to follow Dave Crocker's 
old ideas on Chain of (Mail Transport) Trust.

ARC can possibly help in that area but only if it resolves the 
unauthorized re-signer problem. That would basically mean that at 
least 1 ARC Seal only needs to be trusted, and that would be the first 
and/or last signer.  We always get back to this 100% versus less than 
100% problem and with ARC, it can be inherently or explicitly stated 
what is required.

    1) If all seals are valid, the chain is not broken, then is this an
       acceptable condition for a receiver to accept what would be 
otherwise
       a DMARC failed P=REJECT action?

    2) What if one fails?

We should let the Originating Authoring Domain have some say in all 
this.  Its how I would like to have my restricted domains treated and 
protected. I will do the same with other restricted domains.

> Fundamentally, ARC will never reach critical mass if senders now also
> need to enter into the equation with an additional flag on their DMARC
> record. This is too high a bar and increases the interoperability
> problems as opposed to reducing them.

I don't see that.  We are already creating DMARC records which is the 
big gain over ADSP. And it appears sufficiently enough to support the 
strong "DKIM Policy" p=reject concept.  But we had the same problem 
with SSP and ADSP, a IETF Proposed Standard.  The problem is that it 
didn't reach critical mass, and we also said that it didn't need to 
reach critical mass because it was well understood it would be a 
limited stream.

Yes, the protocol needs to start somewhere and if we don't offer an 
augmented policy concept for ARC, then I just don't see myself 
supporting it until there is some inherent or explicit declaration by 
the Author Domain that the payoff can be high by supporting it.  ARC 
does not have that.

> For now, there is a clear unanswered question: what coverage of
> receivers is needed for most mailing lists to achieve stable delivery
> once ARC is in the mix?

This can leave a hole that is problematic if we continue on a critical 
mass reason to exist.  What will happen when all mail is ARC sealed 
but only 5% or 10% of the domains used p=reject.   You need to have a 
declaration somewhere about what 100% or less than 100% means as part 
of protocol because if ARC does not, then there will be a high 
overhead of legacy mail and domains didn't declare anything and ARC is 
suppose to be a way to ignore "p=reject" policies.

At some point, you will have to say

      "IF you want to use P=REJECT, then you MUST|SHOULD support ARC and
       only use send signed mail on streams that use ARC seal.  This will
       allow your users to use the restrictive domains in public 
environments
       which be against the domain wishes."

The problem?

There will be domains that really, really do not want any 3rd party 
streams to interfere with their direct mail streams.  It helps protect 
their domain and reputation.  I suppose this concept and offering to 
operators.  I am asking what are the rules of the protocol game for 
DMARC and ARC.

> Knowing the landscape of receiving domains, I
> believe this to be a small number. From the above comments, I'm
> guessing you think this is a large number. We're not going to resolve
> this difference of opinion in an open forum. However, releasing ARC as
> an experiment into the wild for major lists like the IETF and M3AAWG
> will give us very clear data very quickly on what the actual landscape
> looks like, and what ARC does and does not solve.

I believe this was pretty obvious by now.  The same issues applied 
with SSP and ADSP which would technically resolve the Mailing List 
problem by augmented it with ATPS. I am one of the few packages that 
know it works in practice.  How is ARC any better to add now that 
DMARC has replaced ADSP?

What will be achieved when there is 10% of the stream versus 90% using 
ARC?  You can't treat them differently because it will leave Security 
Holes and an awful lot of waste if there is a low payoff.

> In its current form, ARC only helps mail flows, it does not harm them.

More headers adds processing, more complexity.  Lets keep in mind that 
not everyone uses open source libraries.  ARC will also add cost.

> How effective this improvement is remains to be seen, but preliminary
> information I've been hearing about (which could be totally wrong)
> makes it seem like the improvements are dramatic.

Only if there is an declaration by the authoring domain that says 
something about its mail.

> So let's get ARC
> tied off as an Experiment (thank you, Dave Crocker), collect some
> data, and see where things stand. Maybe things are great and ARC can
> move to proposed standard. Maybe it fundamentally needs more receivers
> in the mix than currently expected, and some fix for that is needed.
> But we'll know that after the experiment has begun, not before.

This sounds like repeated project research work.  We don't need a 
trillion messages to show what A) the problem is  and B) what the 
solution can be.  We can do that in theory and in practice with just 1 
message.  It was always about DKIM Trust/Reputation Model vs  DKIM 
Policy Authorization model. At some point that Policy declaration 
needs to be made. Somewhere, somehow, otherwise the problem doesn't go 
away.


-- 
HLS