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

["John R Levine" <[e-mail]>]

> 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