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

[Hector Santos <[e-mail]>]

On 8/8/2017 9:59 AM, Bron Gondwana wrote:
> On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
>>
>> Is your concern that the last hop (or any other) can essentially do
>> a wholesale replacement of the message contents and that there is no
>> way to distinguish that from a semantically meaningless footer tweak?
>>
>> I'm not sure that I understand your assertion that you can forge an
>> AS any more than you could forge a DKIM signature.
>
> The whole point of verifying the chain of AS all the way back to i=1
> is that you can tell that the message went through those servers, in
> that order.
>
> But it's bogus, because AS doesn't sign anything except itself and
> some AMS and AAR.  Once AMS doesn't validate any more (any change at
> all) then you can't really tell that the message passed through there,
> just the _a_ message passed through there.
>
> So I could take an existing message that had passed through Google and
> create a brand new message and pass it off as if it had passed through
> Google before passing through my server on its way to you.
>
> In which case - the AS is meaningless.  It claims something which is
> only true if everyone plays by the rules.  But if everyone plays by
> the rules, then it's excessive.  You could just check the previous AAR
> and know that the previous site had validated the hop before it, and
> so on.  It's crypto that doesn't add anything of value.
>
> It's not actively damaging (other than the advice to do excessive DNS
> lookups), but it's also not doing anything meaningful, and it's adding
> something forgeable that looks like it means something.
>

I think we are falling back a Policy Model where we need to know what 
the all important originating Author domain desires. What is the 
expected here for mail processing by the domain?

I thought the main reason, purpose, the "PayOff" for ARC,  was to help 
deal with indirect mail breakage when a DMARC p=reject policy is set 
and more importantly, SMTP receivers with embedded DMARC support have 
begun honoring with hard 55x rejects or ACCEPT/DISCARD/SPAM local 
policy logic.

It is the same problem ADSP had, but it wasn't fully realized, only a 
proof of concept (demo) was shown (here in the list, by me). Receivers 
had yet to implement or turn on the ADSP DISCARD switch but we 
envisioned the indirect mail issue would begin when they did.  So it 
was foreseeable Mailing List members would begin to get unsubscribed 
due to perpetual erroneous receiver rejections.  DMARC proved it when 
the idea was implemented and honored and the screaming began.

ARC is trying to automate something without the help of the 
originating domain.  If ARC is suppose to help save the "message" and 
the author domain from using a p=reject on a mailing list or indirect 
mail travel,  then it leverage the DNS lookup it is already doing.

I think we have made this all too complex by resisting a policy 
concept that helps with all this main processing.  ADSP and DMARC had 
to same issue, so when was ADSP abandoned and  replaced with the 
"Super ADSP" version called DMARC,  the only difference was the 
reporting stuff, which is really not helping.

Anyway, food for thought, a DMARC Tag Extension called ArcSeal.  I'm 
just winging it, so the ARC cogs can consider, or not:

        ArcSeal=All       ; All ARC seals must be valid start to finish.

        ArcSeal=Last      ; Only the last sender/ARC signer is 
necessary (because
                            of the chain of trust).

I suppose there is a "Hops" count concept in there, but the ArcSeal 
tag does not exist, the the message is in an indeterminate state. If 
it exist, thats added value to the Domain declaring to the world what 
it expects and allows, including desirable hard rejection.

The main thing is the automation.  It help with an incentive to 
encourage implementors sitting on the fence. It can help by relaxing 
the rejection of the DMARC p=reject policy using ARC. Isn't that a big 
help?

Personally, I really don't want to waste any more years working on 
this ARC complex proposal and really, this DKIM project since the 
early 2000s.  Folks, we are approaching 15 years on this stuff!!!!  It 
has been a battle of the Trust Model vs Policy Model.  We almost had 
it VBR for TRUST and for Policy with ADSP (proposed standard) plus 
ATPS (experimental) as a possible solution to the indirect mail 
problem.  But abandoned and replaced with DMARC (Informational) which 
has the same problem ADSP was abandoned far.

Sorry for repeating the same thing, but DMARC is the same problem and 
whey we are here, no?

So if DMARC is it, can we please fix it and have it work with ARC to 
help resolve the indirect mail problem?

If not, than other than marketing bullshit, is there any "mail" 
benefit and convincing reason why ARC should be implemented?

Thanks.

-- 
HLS