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

[Seth Blank <[e-mail]>]

On Mon, Aug 14, 2017 at 6:31 PM, Bron Gondwana <[e-mail]>
wrote:

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

We get that with you suggestion above "first AMS failure"


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

That's also how I see it.


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

Nope, we're in agreement.


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

So there have been two years of discussion about this on the list, and the
consensus was that ARC will include trace information - like all
non-originating AARs - because that information might be interesting or
useful to some party at some point. Google has many instances where a
non-originating AAR has the information that matters to them. But the tl;dr
here is simply that the decision was made at its inception to include extra
information that might be helpful later, and that the working group wasn't
open to re-evaluating that decision because the body of ARC was built on
it. If that's the design decision, then we need to be consistent in its
application - which means not throwing out excess data, especially if
someone says "that might be valuable to me."


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

I said the AS forces anyone who modified the chain to sign. In the obvious
"all trusted" and "clearly untrusted" signers cases, the AS doesn't seem to
add much value. But if a bad actor finds a way to send a chain through a
good intermediary, then not having an AS would allow this message to be
delivered. This is an edge case, and maybe doesn't matter - but the AS
certainly protects against it.

The spec already covers all AARs by the AS.


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

I thought our discussion ended with the AS adding an extra layer that was
benign at worst, and protected against future unknown attacks at best. And
your concern was the overhead of evaluating the AS on DNS, especially for
long chains. I thought where we ended was your suggestion that the spec
only requiring validation of the latest AS and AMS, and implementations MAY
validate all AS's if they wish.

If this is the case, then we can't throw out any AMS because none of the
ASs would validate any longer.


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

This is 180 degrees from where we left off on the call.


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

I'll let someone who's more familiar with where ARC started from - my
understanding was that ARC stemmed from something similar to AMS+AAR being
insufficient, but I don't have enough context here to provide meaningful
insight.

Seth

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]
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>