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

Sorry, posted from the wrong address, trying again.

On Aug 9, 2017 8:41 PM, "Brandon Long" <blong@google.com> 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.
>
> 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
>>
>>