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

[Bron Gondwana <[e-mail]>]

On Tue, 8 Aug 2017, at 09:22, Seth Blank wrote:
> On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana
> <[e-mail]> wrote:>> *AS adds nothing over just having AMS signing its own AAR, and then
>> you only have to verify ONE signature, the most recent.*>> 
>> <snip>
>> 
>> You either trust the most recent signer and trust that THEY validated
>> the previous signer/SPF (and so on) or the chain is broken anyway, so
>> why add a parallel, easily falsified, chain of signatures?> 
> There's a critical reason the ARC Seal exists that you're missing:

I'm not missing it, I'm saying it doesn't work.

> ARC is about maintaining a chain of custody so that a final receiver
> can be certain of which domains modified a message in transit. Like
> DMARC, DKIM, and SPF, we're trying to ascertain if the message was
> handled by the domain it said it was handled by - we're not passing
> judgement on the contents of the messages itself.
Yeah, I believed that was true until I thought about the crypto.  Except
we don't know that the message was handled by a domain it says it was
handled by.  We only know that _A_ message was handled by the domain it
says it was handled by.  That could be any message.
> 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.
Except it doesn't, because all the AS before the first liar could have
been grabbed from a different message and you can't tell.
> 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
> 
> In state #1, you're done - if you trust the signatories then you trust
> they're not playing games with the AMS and AAR contents or
> manipulating the message in malicious ways. Now you can make a
> delivery decision as local policy dictates.> 
> In state #2, you're also done - if you don't trust all the
> signatories, then there are a multitude of routes for the message
> to be garbage, including but not limited to everything you've
> outlined above.> 
> 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).> 
> Without the ARC Seal this determination is not possible and there is
> no way to evaluate the ARC chain for delivery as a final receiver.
Sure there is.  In case #1, you can check who signed each AMS and check
that each of them had an associated AAR in which they validated the
previous AMS.  No chain required.  In fact, you can just check the most
recent AMS, because you know they checked the previous one.  You trust
them to have done the checks they claim to have done.
AS just adds theatre.

I'm not sure if there's a point to me proving this by forging a message
with an AS of a site that it never went through.  If you aren't willing
to agree that the most recent liar can repurpose an existing chain, I'm
happy to avoid making the forgery, otherwise I'll make up a forgery and
send it to the list.
But since you either trust every hop to do good checks, or you don't
trust the entire message - then the ARC-Seal is literally adding
nothing.  It adds no meaning, just extra work.  Hence my snakeoil claim.
Bron.

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