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

["Kurt Andersen (b)" <[e-mail]>]

On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker <[e-mail]> wrote:

> On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
>
>> Sign one" (I think you mean "seal one") remains ambiguous to me, because
>> as Seth said, once I see "cv=fail", I don't care about anything else.  Now
>> I have a seal nobody cares about, which means the sealer shouldn't be
>> bothered with generating it, irrespective of what gets fed to the hash.
>>
>>
> +1*10**inf.
>
> There has been a persistent desire to find a way to continue to process an
> ARC sequence that is broken, as if that will somehow make it unbroken or,
> at least, /less/ broken.
>
> It won't.
>
> As soon as a broken ARC chain is detected, ARC is -- or at least should be
> -- finished.  ARC-aware not should stop processing ARC for that message.
> Completely stop.
>
> If there is a clear and compelling counter-argument of clear benefit that
> can be achieved, will be achieved, and is desired by receivers, what is it?


Looking at how ARC chains can fail through the lens of the the validation
protocol (
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15#section-5.2):

   1.  steps 1-3 are all pre-crypto structural checks.  Most of the
   discussion and concern has been in regard to these sorts of structural
   failures being introduced by broken implementations or mis-behaving MTAs in
   the intermediary stages. Up through version 4, we designated such
   structural failures with a "cv=invalid" flag and A-R(arc)=unknown so that
   no one would waste further time or resources looking at them;
   2. step 4 validates the most recent AMS. If it is broken, then we know
   nothing about the content being conveyed so "cv=fail" + A-R(arc)=fail makes
   sense or we could get more specific with A-R(arc-ams)=fail (not currently a
   defined designation);
   3. step 8 (should be 6 if the sub-items had been properly indented)
   validates the sequence of AS header values. If those do not validate, then
   the integrity of the chain itself is unfounded. We currently also designate
   this with "cv=fail" and A-R(arc)=fail but we could distinguish it from
   failure mode 2 with A-R(arc-as)=fail instead.

The only reason to affix a seal with "cv=fail" on the end of an ARC chain
is to spare all subsequent handlers from having to venture past step 2 in
the validation process. Without that, every intermediary and the final
receiver (at least those which validate ARC) will have to repeat the entire
sequence of validation up to whatever point in the process a failure is
determined. If we want (for some reason that I still don't understand) to
have a broken chain "preserved" for hypothetical forensics, we can't do it
under conditions of malformation because we have no deterministic list of
ARC header fields *to* seal. We could do something defined for failure
cases 2 and 3 and some structural violations, but not for all structural
violations. That's why I remain convinced that what is currently called for
in the spec is the only workable approach.

--Kurt