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

["Kurt Andersen (b)" <[e-mail]>]

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.

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

Does this provide enough "bang for the buck" to make it worthwhile? or
should we cut out this field?

--Kurt