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

[Brandon Long <[e-mail]>]

I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data.  That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.

Brandon

On Mon, Jul 30, 2018 at 5:42 PM John R Levine <[e-mail]> wrote:

> > The working group considered cv=invalid last year, but there was strong
> > consensus was against it. The guidance for Sealing cv=invalid Chains
> > somehow made it into this draft applied to all cv=fail Chains. All Chains
> > should be Sealed in the same fashion (your AS covers the ARC Set you've
> > added and all previous ARC Sets), unless the Chain is invalid in which
> case
> > you only Seal your own ARC Set.
>
> Ah.  Perhaps reword 5.1.1 like this:
>
> The signature of an AS header field signs a specific canonicalized
> form of the ARC Set header values, when all of the previous ARC sets
> are valid. In that case, the ARC set header values are supplied to the
> hash function in increasing instance order, starting at 1, and include
> the ARC Set being added at the time of Sealing the message.  If any of
> the existing sets are invalid, the AS header field only signs its own
> ARC Set.
>
> Within an ARC Set, header fields are supplied to the hash function in the
> following order:
>
> 1. ARC-Authentication-Results
> 2. ARC-Message-Signature
> 3. ARC-Seal
>
> The ARC-Seal is generated in a manner similar to when DKIM-Signatures
> are added to messages ([RFC6376], section 3.7).
>
>
> In 5.1.2:
>
> In the case of a failed Authenticated Received Chain, the header
> fields included in the signature scope of the AS header field b= value
> MUST only include the ARC Set headers in the newly created set, as if
> this newest ARC Set was the only set present.
>
>
> In 5.2, oldest pass is confusing, since it doesn't tell you whether
> the validation succeeds or not.  I would take out steps 5-7 and add
> something to the INFORMATIONAL at the end like "A validator can check
> the AMS headers to estimate when in a chain of forwards the message
> was modified."
>
>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>