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

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

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