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

["MH Michael Hammer (5304)" <[e-mail]>]

> -----Original Message-----
> From: dmarc [mailto:[e-mail]] On Behalf Of Scott Kitterman
> Sent: Tuesday, August 08, 2017 10:28 AM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre
> 
> On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote:
> > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> > > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> > > <[e-mail]> wrote:>> __
> > >
> > >> . . .  If you aren't willing to agree that the most recent liar can
> > >>
> > >>   repurpose an existing chain, I'm happy to avoid making the forgery,
> > >>   otherwise I'll make up a forgery and send it to the list.>>
> > >>
> > >> But since you either trust every hop to do good checks, or you
> > >> don't trust the entire message - then the ARC-Seal is literally
> > >> adding nothing.  It adds no meaning, just extra work.  Hence my
> > >> snakeoil claim.>>
> > >
> > > 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.
> > Bron.
> 
> I think the "Once AMS doesn't validate anymore ..." argument is an
> suggestion that it's fragile, not that it's pointless.  I have concerns myself
> about the robustness of this design, but I think that's best addressed through
> deployment and experimentation.
> 
> The fail case isn't very interesting.  If it doesn't validate it, ignore it.
> 
> I'm not sure yet what exactly the pass case buys, but I'm not convinced it's
> nothing.
> 
> Scott K
> 

I think the other thing that needs to be remembered is that DMARC, and subsequently ARC, is a request to the mailbox provider/validator. ARC is presumably used as an input for local policy in consideration of overriding DMARC failures. The fact that ARC validation is successful at the mailbox provider is ultimately a matter of local policy and presumably some sort of reputation schema. 

Mike