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

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

On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank <[e-mail]> wrote:

> On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy <[e-mail]
> > wrote:
>>
>> But (and I think this proves my point) I don't know if "cv=fail" refers
>> to an invalid chain or a failed chain.  I have to run the verification to
>> figure that out.  But you're saying you just stop when you see "cv=fail".
>>
>> I remain confused..
>>
>
> I don't understand what you're exploring. The algorithm in
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2
> is clear and the separate paths you're describing don't factor it.
>
> On validation, you grab the highest instanced ARC set (step 1), and then
> start a process to set the chain validation status of the inbound ARC Chain.
>
> If the highest instanced ARC Set has cv=fail in it, you're done (step 2).
> No cryptographic checks have even been performed at this point, because in
> either scenario the chain is dead. If the AS validates and you have
> cv=fail, then the chain state is fail. If the AS does not validate, then
> the chain state is fail.
>
> Crypto isn't checked until step 3, and we never get there. If you're doing
> analysis and want to understand what caused the chain to fail, you're now
> outside of validation and outside of matters that affect interoperability.
>

And therefore, if I'm a sealer and I've decided I'm going to mark the chain
failed, why wouldn't I just do "cv=fail" with a bogus or empty signature?
The verifier isn't going to use whatever signature I've put there anyway;
as you point out, the verifier sees "cv=fail" and stops.

And if that's all correct, then I don't understand why we're talking about
what exactly you seal if you're the one attaching "cv=fail", because it's
moot.

-MSK