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

[Seth Blank <[e-mail]>]

On Sun, Jul 29, 2018 at 3:59 PM, Bron Gondwana <[e-mail]>
wrote:
>
> I'm not sure what you mean by "the veracity of the header field data".
> Can you give an example of a cv=fail where there's useful information still
> trustworthy in the message, because I don't see it.  To use the "chain of
> custody" analogy, if you have a bag of evidence and it's been unsupervised
> in the hands of an unknown party, the contents have no evidentiary value
> any more.
>
> There's two types of fail - fail on AMS, which could just be a
> modification by somebody, and a fail on an AS, which means there's
> definitely either buggy software or somebody screwing with the chain.
>
> But even a single AMS fail means that an unknown intermediary could have
> changed every single header that's covered by the AMS.  There's no way to
> know what they changed.  Ditto the body.  It could be a totally different
> message and there's no way to know because the chain of evidence is broken.
>
> So again - all that you can know when you see a broken AMS is that
> somebody got their hands on a message which had followed the existing chain.
>

There are two premises to keep in mind:

1) For the first chunk of ARC's life, there will be a significant amount of
ARC breakage due to intermediaries who do not properly or yet implement
ARC. Some of the data ARC collects may in isolating these intermediaries
and helping them properly adopt ARC.

2) we don't know what data is valuable yet, and would rather collect extra
data than throw out potentially useful data (Section 11.3.3)

Given these, it is worthwhile to capture the chain information even in
failing states (i.e. cv=fail should sign greedily), especially when you
consider the three major failure scenarios:

1) A good actor improperly Sealing

ALL the data in the Chain is valuable, including the breakage, because it
isolates the issue and allows that improper Sealer to get feedback and fix
their systems. Realistically, there will be a lot of work done here, as
intermediaries deploying ARC for the first time may get it wrong.

2) A good actor not Sealing

Again, ALL the data in the Chain is valuable, as it would isolate where the
breaking intermediary is and allow outreach. This will probably be the most
prevalent ARC failure we see in the wild in the near term - mailing lists
that do not yet Seal.

3) A bad actor modifying the chain

Sure, the Chain is garbage. But if all the AS's validate, then the bad
actor's been forced down two paths: either a) they are forced to extend or
replay a valid chain, or b) they must create a garbage chain using only
domains they have DNS control over. If the AS's don't need to validate,
then there are numerous malicious paths an attacker can take to modify the
chain in subtle ways.