On Sun, Jul 29, 2018 at 3:59 PM, Bron Gondwana <br...@fastmailteam.com> 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.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
