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

[Seth Blank <[e-mail]>]

On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[e-mail]>
wrote:
>
> 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.
>

This makes sense, and should be a simple addition to 5.1.1 regarding
what/how to stamp. I'll noodle over this and suggest language.


>
> 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!
>

Do we, though? ARC has NOT ever been about localizing or understanding
changes to a message, it has been about understanding *actors* who may have
modified the message.

For instance, if we have two ARC-participating hops, and it was a
non-participating hop between them who modified the message, we could
localize the breakage to being at or between the two hops, but could not
with certainty ascribe it to either hop, which is why ARC has avoided this.


> 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.
>

So much of ARC keeps trace information that might be useful to someone at
some point, it feels very weird to throw some headers out and keep others.
I argue we keep them all, and (to the discussion around Experimental
status) see what ends up being useful after this is in the wild for a bit.
This data can always be tossed later if it serves no real world purpose.



> 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.
>

That's not quite what I said ;-)

If you throw old AMSs out, you cannot validate current ASs or walk the
chain back.


> 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.
>

All these items already get added to the h=.


>
> 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.
>

We can't remove old AMS and AS headers for the reasons listed above
(mainly, a) we're saving trace information to see what's beneficial
downstream, and b) you can't validate the latest AS or walk the chain back
if you throw out old headers).


> 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.
>

I'll suggest language for stamping "first AMS failure", but we shouldn't
strip old AMS/AS headers.

Seth


>
> Regards,
>
> Bron.
>
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   [e-mail]
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>