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

[Bron Gondwana <[e-mail]>]

On Sun, Jul 29, 2018, at 11:12, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana
> <[e-mail]> wrote:>> __
>> 
>> The only thing your ARC Seal will validate is your own ARC-Authentication-
>> Results header - which isn't nothing (it could contain the IP address
>> that you received this message from) - but if SPF / DKIM and ARC are
>> all fails in your Authentication-Results, any earlier ARC and DKIM
>> headers have no provable causal relationship with the rest of the
>> message you received.>> 
> 
> A structurally valid ARC Chain (all ARC Sets have one each of the ARC
> header fields, the ARC Sets instance numbers are 1..N inclusive, and
> each AS covers all ARC Set header fields on the message 1..its own
> instance number) where all AS's validate says a very specific thing
> about that ARC Chain: that no one has modified *THE ARC HEADER FIELDS*
> that are part of the Chain.> 
> This also means that from the first ARC Set at i=1 through the last
> passing ARC Set, you have a guaranteed list of all domains who have
> modified the message (yes, some may have Sealed without modifying)
> and the corresponding ARC-Authentication-Results each saw, which you
> know have not been modified by someone other than the ADMD which
> added them.
Modified "a message", sure.  You have proof that a message
followed that path
> This does not stop someone from taking an intact and passing ARC Chain
> and adding their own garbage on top. Fundamentally, this is how mail
> work; mail is spooled and replayed all the time by design. This is an
> issue with DKIM, and covered in 6376 sections 5.4.1 and 8.6. Since ARC
> inherits heavily from DKIM, it also inherits these specific replay
> issues. It was determined that fixing the replay issue was out of
> scope, except for providing guidance on how to contain impact.
> Sections 9.4 and 9.5 talk directly to these issues:> 
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.4> 
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9..5[1]> 
> Frankly, your concern speaks directly to the issue I raised initially.
> If cv=fail only signs itself, then there is absolutely no way to
> localize the issue and determine which Sealer decided to run amok with
> the Chain. If you see a cv=fail, you have to throw out all the data.
> At least when Sealing cv=fail, if you Seal greedily, there is in
> intact chain of Seals which can be used to make important
> determinations as to the veracity of the header field data and may be
> able to use that to determine where things may have fallen apart or
> been replayed.
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.
Bron.



--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]



Links:

  1. https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.5