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

[Brandon Long <[e-mail]>]

On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <[e-mail]>
wrote:

> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:
>
> I'm just picking out the key quote here:
>
> On 8/7/2017 4:22 PM, Seth Blank wrote:
>
> When validating an ARC signed message, one verifies the latest AMS
> (which must validate), and *the entire chain* of ARC Seals, not only
> the latest. This guarantees you a list of all message signatories -
> the chain of custody we're talking about.
>
>
> Yes, I follow this bit, but then...
>
> When evaluating the chain for final receipt, there are two states to
> worry about as a matter of local policy: 1) you trust all the
> signatories on the chain 2) there is an untrusted signatory on the
> chain
>
>
> Which is why it's a bad idea to sign if you're not modifying, because then
> everybody has to trust you or their chain breaks, even though you didn't do
> anything which required signing.
>

This is an interesting point.

If there is a non-participating intermediary, either the message wasn't
modified (so the next hop passes arc) or it was (and the next hop fails the
whole chain).

If you are participating, the fact that you didn't modify the message is
lost when the message is modified down the chain.

This is a clearly worse scenario for participation, due to the lack of
information that is passed forward in the chain.

We would need to include more information in the chain in order to overcome
this, some information from hop N about which previous hop was the last
modifying hop.

[snip]

> The critical thing about the ARC Seal is that it guarantees this
>
> behavior in state #1 - if you trust all the d= values in the ARC
> Seals, they all validate, and you have cv=pass, then you know for
> certain everyone who has manipulated the message (and maybe some who
> handled but did not modify).
>
>
> In state #1, you don't need a chain of ARC Seal.  You just need each site
> to sign their own AAR and each AAR to include "arc=pass" for the previous
> AMS.  You trust the sites, so you trust them to verify the ARC status on
> ingress.
>
> So ARC Seal isn't adding anything other than complexity.  I'm not saying
> "ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security
> theater in state #1".  It's overly complex and adding no value.
>

If a message goes through two modifying hops, then there is no utility in
the AMS/AAR from the first hop, because it no longer verifies.

At that point, you only ever have the AMS/AAR from the last modifying hop,
which is exactly what we had with XOAR (or at least the Google
implementation).

The Google implementation was basically X-Google-DKIM-Signature as the AMS
and X-Original-Authentication-Results as the AAR.

Theoretically, the second modifying hop could include information from the
preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2,
which trusts hop 1, so I have to trust hop 1) is ok, because by trusting
hop 2, they could have completely replaced the message.  This wasn't done
with XOAR.

There would be no point in including multiple AMS/AAR headers, why bother
keeping the non-verifiable ones.  Or maybe, you just get rid of the AMS and
keep the AAR and have your AMS sign over all of the existing AAR records.

Brandon