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

[Bron Gondwana <[e-mail]>]

On Fri, 18 Aug 2017, at 16:46, Kurt Andersen wrote:
> So I was able to retrace our design steps which led to the 3-piece
> model (AAR + AMS + AS) and the reasoning for the AS, signing just the
> ARC header sequence was to provide the verifiable chain of custody
> trace (though, of course, only from participating intermediaries).
> Some of the recent tweaks to the spec to deal with malformed sets of
> ARC header fields have weakened that original idea.
The problem with the verifiable chain of custody trace is that isn't
actually verifiable, because anybody can break an old chain at any point
and mint a new link that looks as if the message was sent to them.
You can take an email that went

A => B => C => D => E with an intact ARC chain and chop the top off,
edit everything and create:
A => B => X => Y

If you're X, and there's no way to tell from the ARC headers that B
didn't originally send a message to X.
> In keeping with Bron's general idea to simplify, I'd suggest that
> having an AAR + [optional AMS] + AS would be a close approach for
> handling steps which do not break the ingress signature. Skipping the
> AMS would be a sign to downstream intermediaries that the prior DKIM
> or AMS was still valid upon egress. (certain details would have to be
> worked out)> 
> Does that help the conversation?

 On this I agree with Seth.  removing AMS breaks AS, and I see even less
 value in keeping AS if it doesn't even keep verifying all the way back
 to the start.

Bron.--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]