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

[Bron Gondwana <[e-mail]>]

On Tue, 15 Aug 2017, at 05:42, Brandon Long wrote:
> 
> 
> 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.
That seems like it would be enough to fix that objection.  An additional
"first AMS failure" header at each hop would give you a list of who
actually modified the message.
> 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.
Right.  That's the bit that we do absolutely need, regardless of
everything else.  Every link in the chain has to be trustworthy or they
can just repurpose an existing chain valid chain.  If you didn't have
that with XOAR I can see how an intermediate could have falsified the
chain of custody under XOAR without being implicated for reputation
purposes.  We definitely need to be able to know who the injection point
for bad content!
> 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.
Yes, that makes sense - So long as each AAR includes the signing domain
that it checked against for its arc=pass, then no information is lost.
I just had a really good chat with Seth on Skype half an hour ago about
this.  He was unable to find a case where having a full AS,AMS,AAR adds
any provable value over just checking the most-recent AMS and having AAR
signed.  I do like your proposal of signing ALL the existing AARs,
because they're the thing of value.  Old AMS have no value, and old AS
have no value either so long as you have a cv=pass on the current AS.
So if we had this:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc=pass, dkim=fail, spf=fail
AAR: i=3, arc=pass, dkim=fail, spf=fail
AAR: i=2, arc=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

That would give you everything.  The one downside is that every ARC
layer added another item to the h= header in the AMS.  One nice thing
about AS is that you don't need the h=, because it's implied.
But overall I'd say removing the other AMS headers and all the AS
headers still leads to a smaller payload than adding one h=arc-authentication-
results for each hop.
Unless I'm missing something, this design is just as robust as the
existing AS,AMS,AAR for tracking chain of custody back to the first
untrusted site, and neither design is any good for knowing things for
certain about the changes made before the first untrusted site.
Of course - this design doesn't tell you which of the steps modified the
message any more (my first point above).  I do like the idea of tagging
the message with data about which hops modified it... which is an
argument for not stripping AMS while is still validates.  You would wind
up with something like:
AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=3, arc2=pass, dkim=fail, spf=fail
AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-results:[...]AAR: i=2, arc1=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

Which tells you that i=3 and i=4 didn't modify the message, because arc2
passed when i=4 validated it (proving that i=3 didn't modify it), and
the AMS for i=2, i=3 and i=4 all pass now.
If the next hop was to modify the message it would add:

AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail

then strip all the existing AMS and add its own:

AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
Which signed that it verified hops 3 and 4 as non-modifiers.

Regards,

Bron.


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