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

[Scott Kitterman <[e-mail]>]

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