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

[Seth Blank <[e-mail]>]

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.

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

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.