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

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 17:34:51 +0000

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 <[email-masked]>
 wrote:

> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
>
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[email-masked]>
> 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

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 03 Jan 2018 11:39:55 +1100

On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote:
> 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
> <[email-masked]> wrote:>> __
>> 
>>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>>> <[email-masked]> 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.>>> 
>> 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 [email-masked] TODAY or we will lose $IMPORTANT_CONTRACT
Body:
Thanks,
Bron.

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

> 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
  [email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 3 Jan 2018 01:56:53 +0000

On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana <[email-masked]>
wrote:

> As I went through the edits for https://tools.ietf.org/htm
> l/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.
>
> changes, information about abuses gets lost along the chain, and the final
> receiver can't tell who modified the message along the way.
>

So, if we have a message that goes through four mailing lists before final
delivery, each of which modify the subject and everyone is "doing the right
thing" (I know that's not exactly an abuse scenario), we would expect:

* ARC 1: cv=none, closest-fail=0
* ARC 2: cv=pass, closest-fail=0
* ARC 3: cv=pass, closest-fail=1
* ARC 4: cv=pass, closest-fail=2
* final recipient ADMD ARC verifier would find cv=pass and evaluate
closest-fail at 3

Is that what you have in mind?

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2018 15:48:06 -0500

>get away with the worst abuses they can without being detected.

Seems to me this makes some assumptions about the way ARC consumers
will use ARC chains to decide whether to ignore a DMARC failure.
Personally, I think the most likely scenario is that they'll look at
all of the signers to see if they all are reasonably trustworthy, and
if so, look at the i=1 seal to see if the message would have passed
before being munged, and if so allow it.  This requires having a giant
reputation database for every ARC signer, but that's not much of a
stretch beyond the reputation database you need to decide whether to
look at the ARC chain at all.

Trying to guess who changed something and whether they were malicious
seems unlikely to work.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Wed, 3 Jan 2018 12:57:42 -0800

> look at the ARC chain at all.

Yes, but since the decision with ARC was to keep the additional trace
information because it wasn't clear what was useful, to me this falls
cleanly into this same bucket.

I'll propose text for the Experimental Considerations section to outline
this around arc.closest-fail so it can be appropriately watched.

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 04 Jan 2018 10:20:40 +1100

I assume this was the one that you wanted my clarification on?

On Wed, 3 Jan 2018, at 12:56, Kurt Andersen (b) wrote:
> On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana
>>> fail" listed in the AAR.>> 
>> final receiver can't tell who modified the message along the way.> 
> So, if we have a message that goes through four mailing lists before
> final delivery, each of which modify the subject and everyone is
> "doing the right thing" (I know that's not exactly an abuse scenario),
> we would expect:> 
>   closest-fail at 3> 

Well, closest-fail on ARC 1 is meaningless.

But yes - each AMS only holds for its own message here, which means ARC
1's AMS was valid to 2, but not 3 or 4.  ARC 2's AMS was only valid to
3, not 4.  Etc.
This is the boring case, because we don't need closest-fail then.  More
interesting is if ARC 2 and ARC 3 DIDN'T change the Subject, because
then we would have:
* ARC 1: cv=none, closest-fail=0
* ARC 2: cv=pass, closest-fail=0
* ARC 3: cv=pass, closest-fail=0
* ARC 4: cv=pass, closest-fail=0
* final recipient ADMD ARC verifier would find cv=pass and evaluate
  closest-fail at 3
But let's rewrite it as oldest-pass, because that's clearer.  Your case:
* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=2
* ARC 4: cv=pass, ams.oldest-pass=3
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-
  pass as 4.
And my case where 2 and 3 didn't change anything:

* ARC 1: cv=none, ams.oldest-pass=0
* ARC 2: cv=pass, ams.oldest-pass=1
* ARC 3: cv=pass, ams.oldest-pass=1
* ARC 4: cv=pass, ams.oldest-pass=1
* final recipient ADMD ARC verifier would find cv=pass and evaluate ams.oldest-
  pass as 4.
>From which the final recipient can also see that, if they trust ARC 4
not to lie, neither ARC 2 or ARC 3 changed anything which was covered by
ARC 1's AMS.
There is no need to trust either ARC 2 or ARC 3's signatures in my
example, which is the point here.  Even if ARC 2 or ARC 3 are not yet
known or trusted, you can tell that they didn't modify this
particular message.
Bron.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 3 Jan 2018 23:28:31 +0000

> I assume this was the one that you wanted my clarification on?

Yes, thanks

> ams.oldest-pass as 4.
> ams.oldest-pass as 4.
> From which the final recipient can also see that, if they trust ARC 4 not
> to lie, neither ARC 2 or ARC 3 changed anything which was covered by ARC
> 1's AMS.
>
> example, which is the point here.  Even if ARC 2 or ARC 3 are not yet known
> or trusted, you can tell that they didn't modify this particular message.
>

Very helpful - thanks. I think that expressing it in the positive
"oldest-pass" form makes the point much clearer. Unless there is an outcry
from the rest of the group, I'd like to change to this terminology.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Wed, 3 Jan 2018 15:35:59 -0800

> from the rest of the group, I'd like to change to this terminology.

No objection

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 5 Jan 2018 00:18:35 -0500

> from the rest of the group, I'd like to change to this terminology.

Just to be clear, we're saying "*.oldest-pass" will contain the instance
number of the most recent AMS that passed?  Or is it the distance from the
verifier to the most recent passing ADMD?

-MSK

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 05 Jan 2018 17:52:50 +1100

Instance number please.  Less calculation.

On Fri, 5 Jan 2018, at 16:18, Murray S. Kucherawy wrote:
> On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b)
> <[email-masked]> wrote:>> On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana
>> <[email-masked]> wrote:>>> __
>>> But let's rewrite it as oldest-pass, because that's clearer.
>>> Your case:>>> 
>>> 
>>>   ams.oldest-pass as 4.>>> 
>>>   ams.oldest-pass as 4.>>> 
>>> From which the final recipient can also see that, if they trust ARC
>>> 4 not to lie, neither ARC 2 or ARC 3 changed anything which was
>>> covered by ARC 1's AMS.>>> 
>>> example, which is the point here.  Even if ARC 2 or ARC 3 are not
>>> yet known or trusted, you can tell that they didn't modify this
>>> particular message.>>> 
>>> 
>>> 
>> 
>> Very helpful - thanks. I think that expressing it in the positive "oldest-
>> pass" form makes the point much clearer. Unless there is an outcry
>> from the rest of the group, I'd like to change to this terminology.> 
> Just to be clear, we're saying "*.oldest-pass" will contain the
> instance number of the most recent AMS that passed?  Or is it the
> distance from the verifier to the most recent passing ADMD?> 
> -MSK
> _________________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 5 Jan 2018 16:18:16 +0000

> Instance number please.  Less calculation.

Agreed.