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

From: Kurt Andersen <[email-masked]>
Date: Mon, 5 Nov 2018 10:35:23 +0700

Taking this back to the dmarc list instead of the IETF-wide one:

On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <[email-masked]> 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.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Nov 2018 04:12:55 +0000

>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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2018 13:54:33 +0900

Given the intended status is Experimental, is this something that's a
showstopper?

We have the debate about "fail" versus "invalid" that I believe we consider
to be a showstopper for Proposed Standard, but we're willing to let slide
for Experimental.  Is this the same?

-MSK

On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman <[email-masked]> wrote:

> 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
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Nov 2018 00:25:24 -0500

I don't think it's something we should delay on.  In my, admittedly limited, 
experience with these things, once something is in an experimental version of 
an RFC, then it 'has' to be preserved in the name of interoperability with the 
installed base.  I think now is the time to remove obvious fluff.  This 
documents makes my head hurt enough as it is.

If anything, it should be a separate document as it's got nothing to do with 
ARC, per se.  Any utility of AMS past the immediate previous one is entirely 
speculative.  Let's lean towards easy, not hard.  Now is the time to prune 
this.

Having reviewed the thread that Kurt pointed me to, it seemed like this is 
something only one person wanted.  It didn't appear to have a lot of push 
behind it.

Scott K

On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote:
> > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <[email-masked]>
> > 
> > wrote:
> > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <[email-masked]>
> > >
> > >wrote:
> > >> 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
> > >
> > >> 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
> > >
> > >> Later, after there is more experience with ARC, if it's established
> > >
> > >that
> > >
> > >> 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
> > >
> > >> 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
> > >

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 5 Nov 2018 13:31:50 +0700

Explicitly looping in that one person to see if his thoughts have changed
over time.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2018 17:12:51 +0900

On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman <[email-masked]> wrote:

> installed base.  I think now is the time to remove obvious fluff.

That's the opposite of my understanding of Experimental.  Rather, I believe
explicitly calling it an experiment means we reserve the right to mutate or
even jettison portions of ARC we discover, through experimentation,
interfere with interoperability either among ARC components, or with the
operation of adjacent protocols, or provide more complexity than utility.

If there's ambiguity around what "Experimental" means, we should take the
time to sort that out and, if needed, add text to make it clear.

This documents makes my head hurt enough as it is.

I've felt that on occasion too.

> something only one person wanted.  It didn't appear to have a lot of push

Based on my understanding of Experimental, I think a one-off feature is
fine to include, again with the understanding that it could be omitted from
a Proposed Standard version because it isn't widely useful.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 5 Nov 2018 16:28:20 +0700

> a Proposed Standard version because it isn't widely useful.

Throwing it in because we were aiming at the "experimental" designation
seemed to be the easiest way to resolve the non-progressing discussion when
it initially cropped up in August 2017. The topic was permuted from
nearest-fail to oldest-pass in January 2018 to make the calculation
algorithm and interpretation of the data point a bit clearer but I don't
think that anyone has changed their mind much from their positions in
August 2017 - unless, as Scott pointed out, the one person who insisted on
this has done so silently.

--Kurt

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 06 Nov 2018 04:51:53 -0500

On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote: 
> On Mon, Nov 5, 2018 at 3:13 PM Murray S. Kucherawy <[email-masked]> wrote: 
>> Based on my understanding of Experimental, I think a one-off feature is fine to include, again with the understanding that it could be omitted from a Proposed Standard version because it isn't widely useful. 
>  
> Throwing it in because we were aiming at the "experimental" designation seemed to be the easiest way to resolve the non-progressing discussion when it initially cropped up in August 2017. The topic was permuted from nearest-fail to oldest-pass in January 2018 to make the calculation algorithm and interpretation of the data point a bit clearer but I don't think that anyone has changed their mind much from their positions in August 2017 - unless, as Scott pointed out, the one person who insisted on this has done so silently. 
 
I don't think any of my objections to being unable to distinguish between "sealed and didn't modify" and "sealed and modified" cases have changed. 
 
Having said that, it's easier to add an additional field than to take something out, so I don't object to simplifying and seeing what happens. Particularly since we're experimental. 
 
Bron. 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 7 Nov 2018 07:21:26 +0700

On Tue, Nov 6, 2018 at 4:52 PM Bron Gondwana <[email-masked]> wrote:

> I don't think any of my objections to being unable to distinguish between
> "sealed and didn't modify" and "sealed and modified" cases have changed.
>
> Having said that, it's easier to add an additional field than to take
> something out, so I don't object to simplifying and seeing what happens.
> Particularly since we're experimental.
>

Since we are now pretty much through even the IESG last call period, I'm
loathe to make any changes without a groundswell of assent across the
entire group.

Please take a look at the new Appendix B (
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-20#appendix-B)
which was mocked out with Mail::DKIM. There are traces of where changes
happened in the AAR from the ARC chain validation - the motive A-R headers
were manually created by me and did not include the newer pieces since the
system that generated the A-R did not have access to the info. It's not
quite as easy to parse, but the info is there.

--Kurt