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

[Bron Gondwana <[e-mail]>]

On Thu, 10 Aug 2017, at 10:41, Brandon Long wrote:
> 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.
I would argue that if the AMS passes, the intermediate hop SHOULD NOT
add another ARC-Seal...
> 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.
Which is precisely my point above.  Consider this case

A => B => C => D

Where C is untrusted and you are D, but the AMS is

A(fail) => B(pass) => C(pass) => D

So you know that C didn't modify the message, and you can trust the
message because you trust B.
Now suppose  D modifies the message and sends it on.

A => B => C => D => E

With AMS status:

A(fail) => B(fail) => C(fail) => D(pass) => E

If you (E) trust A, B and D but don't trust C, the fact that C added an
ARC-Seal has confused a message that was perfectly trustworthy, because
you can no longer validate the fact that C didn't change the message.
That's why I say: don't ARC-Seal unless you're changing the message.

> 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.
That's fine if you have the resources of Google to know who's
intermediating a lot.
If you are B in that chain above and you can get C to forward your
messages, you could easily destroy C or D's reputation at E, even though
D knew that C wasn't modifying your messages.
> 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.
This comes down to how standard the AAR is.  If my AAR includes machine
parseable information to say that I could validate the previous AMS and
it passed, then you can walk back through the chain just as easily,
without even needing to validate the previous signatures, because I
already did that for the previous one, and they already did it for the
one before.
There are only two cases that the full ARC-Seal helps with.  You spelt
out one above: the earlier AMSes still validate, so you know the message
hasn't changed.  That's bogus to me in two ways:* the one I just spelled out (it muddies things after the next
  modification), so don't do it in the first place* if you can still validate the earlier AMS then you don't even need the
  follow the ARC-Seals - just validate each AMS from highest i= down
  until you find one that doesn't pass.  All the passing AMS must be
  trustworthy regardless of the later ARC-Seals, because they are signed
  by the domain and correctly describe the current message.
So ARC-Seal buys you nothing for the hops where AMS is passing (because
you're checking AMS anyway), and it buys you nothing for the earlier
hops, because you have to stop at the first hop you don't trust.
I will give you this - if you believe that it's likely that
implementations will exist that can successfully validate an AS chain,
and can successfully validate the previous AMS, but can NOT reliably
generate an AAR header, then ARC-Seal would have a point.  Otherwise
we're trusting sites to do all the crypto right, but not trusting them
to report the results of said validation correctly, which is really a
weird security stance IMHO.
> 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.
I believe the logic for "should I add an AMS" should be:
1) there is existing DKIM, but I'm about to break it by changing
   the message2) there is an existing AMS, but I'm about to break it by changing
   the message3) there is no DKIM  or AMS, but I trusted the message for some other
   reason which the next hop will be unable to verify (e.g. SPF passed)
In all other cases, adding a signature is bad.  Complex routing should
not break the signature, so only the process making the modifications
should be adding a new signature.
In the case of Google, that would mean adding an AMS on incoming MX only
for messages which have  no DKIM, then adding an AMS for messages which
are modified (e.g. by Groups)
> 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.
It wasn't so much this list, it was everything else in my entire mail
repository!  Not much with ARC on it yet.
Bron.

> Brandon
> 
> On Aug 9, 2017 6:26 PM, "Bron Gondwana"
> <[e-mail]> 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
>>   [e-mail]
>> 
>> 
>> 
>> _______________________________________________
>>  dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>> 
> _________________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc

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