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

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Jul 25, 2018 at 2:34 PM, Seth Blank <[e-mail]> wrote:

> When we introduced the concept of cv=invalid last year, the advice was to
> only sign your own ARC Set, because there was no deterministic way to know
> which header fields to sign when those ARC header fields were not properly
> intact (the definition of invalid). We then decided to abandon the
> cv=invalid path and only have cv=fail.
>
> Somehow, in the current doc this advice for invalid chains now applies to
> all chain failures. Section 5.1.2's title even mentions it is for the
> invalid case, but the text as written applies to all failed chains.
>
> Without the ARC Seal covering the ARC header fields in the failing chain,
> all the data in the failed chain can be modified as it is not covered under
> the latest signature.
>
> The proper guidance should be that the ARC-Seal MUST sign the ARC Chain in
> its entirety, unless that is structurally impossible, in which case it
> should only sign itself.
>
> I believe the proper text for this section (replacing the first paragraph
> for 5.1.2 in its entirety) should be:
>
>    In the event that it is not possible to generate a deterministic list
> of previous
>    ARC Sets to sign (such as when the chain undergoing validation
>    is structurally invalid), the signature scope of the AS header field b=
>    value MUST only include the latest ARC Set headers as if this newest ARC
>    Set was the only set present.
>

I think it's weird that the body of content that gets hashed by the sealer
in this case varies from what would normally happen.  A verifier might have
to try two different verification algorithms if, for example, it doesn't
determine that the chain is structurally invalid.

If I receive a chain that was apparently valid at the last sealer and
determine that it is no longer so, could we simply decline to re-seal it at
all?

-MSK