Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: <draft-ietf-dmarc-arc-protocol-18.txt>...)

[Scott Kitterman <[e-mail]>]

On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <[e-mail]> wrote:
>Taking this back to the dmarc list instead of the IETF-wide one:
>
>On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <[e-mail]>
>wrote:
>
>> . . .  I understand the desire to just ship it at this point so more
>> operational experience can be gained before another update.  With one
>> exception, I agree with that approach.
>>
>> In Section 5.2.  Validator Actions, I think it's highly unlikely that
>Step
>> 5, AMS (ARC Message Structure) validation of AMS header fields beyond
>the
>> one immediately prior in the chain is useful.
>>
>> Failure doesn't change the ARC result, so there are no
>interoperability
>> implications for removing it from the draft.  The only reason to
>specify
>> anything is the notion of 'oldest-pass'.  This looks like a dubious
>and
>> premature optimization to me.
>>
>> I didn't and don't plan to implement it.
>>
>> Later, after there is more experience with ARC, if it's established
>that
>> validation of AMS beyond the immediately prior step in the chain has
>> utility and there is sufficient efficiency associated with
>'oldest-pass',
>> it can be added then.  'Oldest-pass' seems like an easy way to get
>around
>> having downstream validators do AMS validation up the chain (by
>always
>> adding arc.oldest-pass=1 to all messages).
>>
>> ARC is complicated enough without this and it seems like any easy win
>for
>> simplicity in design to take this out for now (and we'll see about
>the
>> future).  Deleting it also reduces the IANA considerations.
>>
>
>I'm not by any means arguing with your analysis and plans to skip this
>component, but I did want to point you, for informational purposes to
>the
>WG thread which was the genesis of this concept. It was originally
>proposed
>as "closest-fail" but then inverted to be "oldest-pass". You can find
>the
>thread from January 2018 at
>https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI
>which references an older discussion circa August 2017.

Thanks.  I've reviewed it and my opinion is reinforced.  It ought to be removed.  Nothing other than the immediate prior AMS matters for evaluation of the ARC result.  Everything about prior hops is purely for receiver edification, not needed for the protocol.

Scott K