Re: [dmarc-ietf] Last Call: <draft-ietf-dmarc-arc-protocol-18.txt> (Authenticated Received Chain (ARC) Protocol) to Experimental RFC

[Scott Kitterman <[e-mail]>]

On October 23, 2018 3:07:47 PM UTC, The IESG <[e-mail]> wrote:
>
>The IESG has received a request from the Domain-based Message
>Authentication,
>Reporting & Conformance WG (dmarc) to consider the following document:
>-
>'Authenticated Received Chain (ARC) Protocol'
>  <draft-ietf-dmarc-arc-protocol-18.txt> as Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final
>comments on this action. Please send substantive comments to the
>[e-mail] mailing lists by 2018-11-06. Exceptionally, comments may
>be
>sent to [e-mail] instead. In either case, please retain the
>beginning of
>the Subject line to allow automated sorting.
...

I have reviewed the latest version of the draft in some detail, primarily with an eye towards updating the implementation that I help maintain (dkimpy) to the current requirements.  It's been some time since it was updated (rev -08 and we're at -18 now).

I was pleasantly surprised to find that most of the changes in the document were focused on making it more understandable.  It has a few rough edges, but nothing I think is problematic for this level of maturity.  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.

If it's decided to leave it in, it needs a MAY construction rather than OPTIONAL.

Scott K