On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker <dcroc...@gmail.com> 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
