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

We discussed this exact situation extensively during several M3AAWG
meetings, so I don't think we're missing something... but maybe.

With AS I can trust the chain and use the older hops AAR.  And whether to
use a given hops AAR is based on my trust level for that hop.

As long as the AMS passes, you can ignore hops you don't trust and keep
walking.

Once you reach a hop where the AMS doesn't verify, you can only walk back
to hops you trust, and untrusted hop ends your walk back.

So, you can copy and entire chain on to whatever message you want, but that
only works if I trust you.  If you do this a lot, we won't trust you any
more.

This doesn't mean that some messages can't abuse the trust relationship and
make it through, and we specifically say that standard spam/phishing/abuse
analysis should still be done.

With your proposed AAR signed by the AMS, I can only trust your AAR, and
whatever you choose to put in it, not anyone in front of you.

With XOAR, we have experience with that type of single hop working system,
and it's not complete enough, we see too many complicated routing policies
which go through many hops, and the last hop data isn't always enough.  We
work around it with from header rewrites and signing as the intermediary
domain, but then we need to make decisions on when to do so since dkim
means something different than ams does.

Also, you wouldn't expect to see arc signed messages from this list until
it starts doing them itself, unless people are posting to it though another
intermediary or you receive it through a separate intermediary.

Brandon

On Aug 9, 2017 6:26 PM, "Bron Gondwana" <brong@fastmailteam.com> wrote:

> On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
>
> 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.
>
>
> It's not fragility, the older AMS is supposed to not validate any more,
> because it's a signature over a bunch of headers and the body - any change
> in those will break it.  That's fine so long as the chain of custody exists.
>
> My problem is that ARC-Seal only actually shows the chain of custody back
> to the first bad actor.  That's also fine, because any bad actor means the
> whole message is tainted and should be discarded.
>
> The thing is - ARC-Seal and verifying every Seal only gives more integrity
> than checking the previous AMS and signing your own AAR unless this is true:
>
> * There exists a site which correctly checks ARC-Seal and adds new
> ARC-Seals, but does not generate an accurate AAR.
>
> I do feel like nobody understands what the hell I'm trying to say here
> based on the responses I've seen so far, so maybe I do actually need to
> find an existing ARC-Sealed email and forge a change to it.  Seth asked to
> have a phone chat about this, and I'm happy to have a phone chat with
> anybody if it will help explain my point.
>
> I'm not saying that the underlying concept of ARC are wrong - the idea of
> chain of custody is sound.
>
> The problem is that ARC-Seal makes claims it just doesn't deliver on -
> it's not adding value, and it is adding cost and fragility (the need to
> successfully do DNS fetches for every seal in the chain at every point,
> plus the cost of checking that crypto) - and yet any one site can still
> falsify all the earlier items in the chain.
>
> Sadly I only have a few message in my entire mailbox that have ARC-Seals
> on them.  They're from a Mozilla Thunderbird list of all things, and they
> have some Google ARC headers on them.  I'd prefer to impersonate someone
> from this list if I'm going to make a proof of concept to show what I mean,
> but nobody appears to be sending messages with ARC headers on them here!
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   brong@fastmailteam.com
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>