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

[Bron Gondwana <[e-mail]>]

On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
> 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.
Excellent, thanks.

>  
>> 
>>> 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.
Sure, but knowing which actors may have modified the message and which
actors definitely didn't modify the message is super useful.
It means that if you trust the next hop, you don't need to trust the
intermediates that couldn't  modified the message without colluding with
that next hop.
> 
> 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.
If you trust hop 2, you can confirm that it was modified since hop 1 (or
that hop 1 can't form a valid signature).
 If you don't trust hop 2, then you don't know anything at all about the
 message before hop 2, regardless of any signatures.
If that isn't clear, then I didn't explain myself very well on our call!
Unless you trust hop 2, everything before that is meaningless,
regardless of ARC headers.  An ARC chain through an untrusted hop 2
could be totally fiction.
>> 
>>> 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.
"might be useful to someone at some point" - that kind of wooliness is a
crock, sorry.  Once  crypto doesn't validate it has no meaning if all
the data is present elsewhere - and everything that an AMS claims except
for the crypto over the message is duplicated in the next hop's AAR.
If that's not the case, we should fix it so that it is.

"see what ends up being useful after this is in the wild for a bit"
makes sense for informational records.  It doesn't make sense for
cryptographic data.  Either the crypto is sound and it means something,
or it's actively misleading.  A no-longer-validating AMS contains
nothing that the next hop's AAR doesn't contain.
>  
>> 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 ;-)

OK, did I misunderstand?

You  couldn't quote a case where AS,AMS,AAR adds provable value over
an AMS that signs the most recent AAR.  If you can find that case, I
will eat all my words, because I've spent a lot of time thinking
through the cases.
I agree with what Brandon seemed to be saying above - that it should be
all the AAR being signed, not just the top one.  Otherwise an
intermediate could strip or modify earlier AAR without breaking the
authentication, and that would be bad.  Each AAR contains real,
valuable, meaningful data.
As far as I see, we're quibbling over how much cryptographic
infrastructure is needed to maintain the integrity of the chain of
AAR headers.
> If you throw old AMSs out, you cannot validate current ASs or walk the
> chain back.
So what.  AS is bunk.

A current AMS over all AAR gives the same auditability, since AAR is the
only thing that has meaning.  AMS only has meaning while it still
validates, and AS only has meaning because it ties AMS and AAR together.
Those meanings don't add value.  None of them mean jack once you've been
through an untrusted site, all previous headers are suspect regardless
of whether they have crypto that still validates, unless that crypto
covers facts about the message which we actually care about.
>> 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=.
>  

Of AS in the current draft, yes.  If we added AAR to AMS and kept AMS as
a DKIM signature structure, then we would want the h= key to contain the
full list of headers.
>> 
>> 
>> 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).
 Forget AS when reading my examples here, because I was assuming no AS.
>> 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.
This is where we disagree.  We shouldn't create AS headers in the
first place.
We should have AMS sign all the AAR and that's it.  No AS, no need to
retain broken AMS.
It gets you all the same machine readable chain of custody as AS+AMS+AAR
in the unbroken case, and it breaks at the same place with the same
detectability in the fraudulent-actor case.
There are no other cases.  There's no middle here.

Please do prove me wrong if you can think of another case, I
really can't.
Bron.

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