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

[Hector Santos <[e-mail]>]

On 8/11/2017 8:19 PM, Bron Gondwana wrote:
> On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote:

>> by 'strategy DKIM uses' what do you mean exactly?  I'm guessing you mean
>> having the signature cover more of the header and all of the body, but
>> please confirm or clarify.
>
> Sorry - yes, to clarify...
>
> DKIM signs the entire body plus parts of the header.
>
> In the strategy I am proposing, site "X" modifying a message in
> transit (e.g. a mailing list) would add their own DKIM-like header
> (ARC-Message-Signature is a perfectly fine name for it) which signed
> the new "body and parts of the header", including a statement that
> site "X" had verified the message authentication before modifying it
> (ARC-Authentication-Results is a perfectly fine name for that statement).
>
> That gives a complete chain of custody.

Its a great idea.... but it still suffers from the long time 3rd party 
signature registration problem.   This is why we are here.  All the 
DKIM policy models, including DMARC with a p=reject policy) suffered 
this issue.  ARC is suppose to save 3rd party signed indirect messages.

The "Arc-Authentication-Results" header can claim this but it still be 
phishing, forged mail -- no trust at the downlink receiver level 
and/or MUA client when DMARC p=reject rejection results are seen.

What is needed is the Originating Domain making this claim that 
authorizes X as a legitimate modifier.  We can either lookup that 
information (ATPS, https://tools.ietf.org/html/rfc6541) or we pass it 
as a new DKIM-signature. Levine had a DKIM Conditional proposal that 
does this. It wasn't a lookup concept, which I prefer, but Levine's 
idea was the next best option that touches base with a "3rd Party 
Authorization" concept:

    https://tools.ietf.org/html/draft-levine-dkim-conditional-02
    Abstract

    This experimental specification proposes a modification to DomainKeys
    Identified Mail (DKIM) allowing advertisement of third-party
    signature authorizations that are to be interpreted as equivalent to
    a signature added by the administrative domain of the message's
    author.

I'm not against ARC other than it seems like complex, overhead that 
doesn't address the main issue of authorized 3rd party routes.   If we 
even have a DMARC ARC Policy concept, than that may be enough to begin 
pursuing the high cost of experimentation and development here.

-- 
HLS