Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

[Bron Gondwana <[e-mail]>]

On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote:
> As I went through the edits for
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1
> I was unable to understand the value added by having the "arc.closest-
> fail" listed in the AAR.
Please  read my examples again if the problem wasn't clear, because you
don't get security by imagining the best cases where everyone behaves
themselves, you get security by imagining that everybody is trying to
get away with the worst abuses they can without being detected.
Without a closest-fail from each step, or a similar way to determine
changes, information about abuses gets lost along the chain, and the
final receiver can't tell who modified the message along the way.
> Looking back through the list archives, the idea for this pvalue seems
> to have come up in mid-August, captured in this snippet:> 
> On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana
> <[e-mail]> wrote:>> __
>> 
>> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
>>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>>> <[e-mail]> wrote:>>> > 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.>>> 
>>> arc.closest_fail has been defined to accomplish this.
>> 
>> That looks great.  It adds enough information that my other questions
>> are basically efficiency concerns, which are not nothing, but at
>> least ARC signing doesn't make things worse...> 
> It seems that Bron is advocating a change in the verify process where
> by all AMS signatures would have to be checked rather than just the
> most recent one. Going through the archives showed me that the
> language in 5.2.1 should say "...the most recent AMS that fails to
> validate..." rather than "...the most recent AS that fails to
> validate..." but then the verifier actions would also need to be
> updated in section 6 (steps 3+).
Yes, it should say most recent AMS, not AS.  All AS should always
validate.
>  If we are only concerned with changes in the body of the message
>  which are being introduced by intermediaries, it seems like we could
>  just check for changes in the bh value between hops rather than
>  requiring each verifier to walk (possibly) the whole list of AMS
>  headers.
No, that's bogus.  The message is not the body, the message is
body+subject+from+to.  In particular, a bad actor intermediate
could totally change the meaning of a message by changing the
subject.  Messages where the majority of meaning is in the subject
definitely exist.
Subject: Please clean out your stuff from the fridge

Body:
Thanks,
Bron.

vs

Subject: URGENT: your need to paypal $5000 to [e-mail] TODAY or we will lose $IMPORTANT_CONTRACT
Body:
Thanks,
Bron.

Both have the same bh=, but they're very different messages.

> Does this provide enough "bang for the buck" to make it worthwhile? or
> should we cut out this field?
If we cut the field, then ARC usage guidelines need to say "don't
seal if you didn't change the message" or we're breaking the value of
the chain.
Bron.

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