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

[Dotzero <[e-mail]>]

On Wed, Aug 15, 2018 at 1:28 AM, Kurt Andersen (b) <[e-mail]> wrote:

> 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
>
>
+1. I understand the desire for more but I agree with Kurt.

Michael Hammer