Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 20 Aug 2018 12:48:17 -0700

Seth and I discussed this topic today and I think that the central problem
that is being debated has to do with *generating* the DMARC report content.
Almost everyone agrees that a broken chain is broken and unredeemable -
whether that breakage is structural or whether it is because of
non-validating signatures. There are three possible levels of processing to
be considered:

   1. validating a particular individual message for delivery to the
   recipient - this is easy: a broken chain conveys no useful information for
   local policy determination
   2. feeding ARC information into some larger reputation/ML system in
   order to provide (what I'll call) a third order policy influence - this one
   depends on whether the reputation system can make any useful conclusions on
   the basis of the broken chain. In some cases (where a signature fails to
   verify) it seems possible, but in many others it seems a bit doubtful
   3. generating the DMARC report data pertinent to this individual message
   - this is where I think that the problem lies. There is a natural desire on
   the part of senders and report processors to want all the data that they
   can possibly get; however, it is easy to devise attack scenarios which
   heavily contaminate the reports if one were to take the content of the
   entire broken ARC chain into the report

My contention to Seth is that in a multi-hop scenario, the *only* report
with meaningful data will be the one from the handler who made the "fail"
determination and any subsequent reports are untrustworthy.

If we are not concerned with "downstream" handlers of a message with a
broken ARC chain, then there is no point in attempting to seal the entirety
of a failed ARC chain.

Do the other folks on this thread agree that our main point of contention
has to do with the ability to generate the DMARC report (or the data
scoping thereof)?

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2018 22:18:43 -0400

>determination and any subsequent reports are untrustworthy.

Assuming that "subsequent" means earlier in the chain, I agree.

>has to do with the ability to generate the DMARC report (or the data

Yes.  I understand what to do with "here's a valid chain" and "it was
broken when I got it", but not "here's a broken chain you may or may
not be able to reconstruct."

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 20 Aug 2018 22:39:40 -0700

> Assuming that "subsequent" means earlier in the chain, I agree.

No, by subsequent I mean intermediaries who handle the message after the
point of initial "oh, this is broken" determination. So if I'm the 5th
intermediary (let's assume that all are ARC participating for this
discussion), and the chain on the message that I receive does not pass the
validation checks (for any of the three possible reasons), then my report
is meaningful to the sender but reports from 6, 7, 8, etc are not.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 21 Aug 2018 10:46:01 -0400

> is meaningful to the sender but reports from 6, 7, 8, etc are not.

Ah, that.  You're right.  One the chain is broken, we have no idea where 
the message came from and it's just another bit of spam bouncing around 
the net.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly