Subject: Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 17:57:49 +0000

On Fri, Dec 29, 2017 at 12:15 AM, Seth Blank <[email-masked]> wrote:

> I'm beginning a new thread to explicitly address some differences of
> opinion in the working group.
>
> Coming out of IETF99 and surrounding working group conversations (
> https://mailarchive.ietf.org/arch/msg/dmarc/5_OP8lVi-a3yHMS0hqs1clyLWj4,
> https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ,
> https://mailarchive.ietf.org/arch/msg/dmarc/X-3nVPUQgIy-AGt4tJfkbPZZTjI),
> I was under the impression that working group consensus was that ARC would
> be submitted as an Experimental draft.
>
> I know Kurt has very strong opinions that we NOT proceed as Experimental,
> and I wanted to make sure he got to state his case.
>
> 1) Unless a chair speaks up that consensus is already Experimental, we
> should have the conversation now and nail this down.
>

Citing from https://datatracker.ietf.org/doc/minutes-99-dmarc/:

Barry: When ready for WGLC?
> Kurt: New draft tomorrow, hope to be ready for LC in a week.
>   4a. Document status discussion
> Dave Crocker: Suggest experimental for now because the operational issues
> associated with the chain of signing aren't known.  Revisit when ready for
> a BCP.

Kurt: Have enough implementations to make a proposed standard.

Murray: If it's WGLC in a week, I'd prefer experimental.  If we take more
> time, then proposed standard.

<more notes about the discussion omitted here>

Decision: We will continue discussing on the list, and will not hold up
> WGLC for this issue. We need to have a working group decision by the time
> we request publication (after WGLC).

It's quite clear that my assertion of being ready for LC before the end of
July 2017 was a wild flight of fancy; but I'm glad to see that I didn't
entirely invent the interpretation of continuing on a "proposed standard"
path.

While John Levine cited the benefits of the "experimental" approach taken
for EAI (
https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw),
I'm also biased by the "let's all just play nice" mess that came from
designating incompatible "versions" of SPF as competing experiments (see
https://tools.ietf.org/html/rfc6686 for the eventual outcome of that six
year long experiment).

I think that any protocol which has not already been widely implemented is,
in some sense, experimental - if you are looking at it from the perspective
of hind-sight, you might have done some things differently/more
efficiently/etc. One might not have called IPv6 "IP"-anything or may have
chosen a longer address space for IPv4 for instance.

I'm willing to go along with the consensus of the group, but wanted to
(re)express my continued opposition to the experimental track for this.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Jan 2018 02:05:31 -0500

On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) <[email-masked]> wrote:

> for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/
> gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play
> nice" mess that came from designating incompatible "versions" of SPF as
> competing experiments (see https://tools.ietf.org/html/rfc6686 for the
> eventual outcome of that six year long experiment).
>

I'm not sure I understand the comparison.  ARC, as far as I know, doesn't
have two factions attempting to advance their own agendas in a common
space.  We have just one protocol here.  Instead, the bulk of the debate
has been about whether this WG is prepared to stand behind its processing
via the standards track, and I thought we were leaning toward the answer to
that being "no" right now, and the core issue is whether we want it to be
standards track first or have an RFC number first.  If getting it published
in some state is more critical than having it on the standards track, then
"experimental" is, to me, the only option right now.  And that's what I
think I said in Singapore.

> (re)express my continued opposition to the experimental track for this.

Dave Crocker can probably articulate this better than me, but I'll take a
run at it.

There are two primary drivers for this decision for me:

1) ARC is trying to do something that's different enough from DKIM (i.e.,
recording some kind of handling chain) that we really should have some
deployment and impact experience before we can say we have enough
confidence to call it a proposed standard; and

2) The advice that all handlers need to apply a seal to the message, to
which Bron previously and rather strenuously voiced opposition.  I believe
the decision was to defer on that issue until we've run some real-world
experiments, which to my knowledge haven't happened.  Unless I've somehow
missed a change in posture either by him or by the specification (which is
entirely possible), we're not done enough to say it ought to be on the
standards track.

The counter-argument to (1) is that Proposed Standard really is only a
proposal, but I think our goals are loftier than that here.  Then again
DKIM went out PS, right?  Well yes, it did, but we weren't in any perceived
hurry that I can recall.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Wed, 3 Jan 2018 00:04:10 -0800

> entirely possible), we're not done enough to say it ought to be on the

To be clear, Bron's concern was that "anyone can seal" destroys the signal
to final receivers about who modified the message, which might be crucially
important. The counter-argument was that ARC won't get adoption unless it's
benign and therefore easy for intermediaries to make a sealing decision, so
the compromise was to add arc.closest-fail to the AR/AAR. This way, ARC
participants can seal when in doubt and a final receiver has the data to
determine which sealers modified vs simply handled the message.

Furthermore, for me "experimental" comes from the fact that there are
several open issues on which there has been lasting discussion within this
group with no resolution that data from an experiment will quickly shine
light on. It was for these reasons that I proposed the experimental
considerations section.

I believe the argument in favor of Experimental is a weighty one, and I
think ARC fixes a meaty enough problem that getting to a published RFC is
of greater and more timely importance than getting to Proposed Standard.
And if we get to Experimental and gather data quickly, Proposed Standard
won't be far behind...

S

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 3 Jan 2018 16:04:10 +0000

On Wed, Jan 3, 2018 at 8:04 AM, Seth Blank <[email-masked]> wrote:

>
> . . .for me "experimental" comes from the fact that there are several open
> issues on which there has been lasting discussion within this group with no
> resolution that data from an experiment will quickly shine light on. . .
>

I'm less sanguine about the likelihood of the deployment "quickly"
generating data, especially since a bunch of what we are most interested in
will be cloaked within the veil of proprietary processing within individual
ADMDs.

> of greater and more timely importance than getting to Proposed Standard. . .
>

Speed of getting an RFC number issued is, to me, the salient assertion.

--Kurt

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Jan 2018 11:43:39 -0500

DKIM had a sound proof of concept when it was introduced, and I hate 
to bring it up, but its key attraction, both technically and from a 
marketing standpoint, came when it was tied to a DKIM Policy model as 
the original specification had it proposed:

DKIM/SSP proposal:

Proposed:

    o=~  NEUTRAL (signature optional [,No 3rd party?])
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

WG suggestions:

    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)

It had a solid hash bound required anchor using a Domain Author Domain 
with a published policy for rejection, filtering, classification, 
whatever local policy wanted to use including nothing at all.   So 
solid was the proof of concept, in the words of one prominent person 
in the group, "It's scary" of what people can do with a strong, 
exclusive rejection/filtering policy model.  And the best part was it 
actually worked with a low false positive rate -- except for the 
indirect, mailing list streams and years later, we are still dealing 
with the latter.

ARC has no ties to Policy.  The ARC chain concept is sensitive, 
extremely high overhead and IMO, unnecessary for what we have been 
trying to resolve related to DKIM Policy Strong rejection policies and 
how to escape it with the blessings of the originating Author Domain.

Making ARC a PS isn't going to change the fact it is a weak idea (less 
than "Half Baked") at this point in addressing the DKIM Policy 
Rejection issue with indirect mail.

Tying ARC to a policy system may move the consideration much further 
because it may start discussions on Policy Scenarios of what are 
valid, invalid ARC seals. Until then, I'll continue to watch to see 
where "yuns" are going with this expensive RFC5322 header overhead add-on.

-- 
HLS

On 1/3/2018 2:05 AM, Murray S. Kucherawy wrote:
> On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     While John Levine cited the benefits of the "experimental"
>     approach taken for EAI
>     (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw
>     <https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw>),
>     I'm also biased by the "let's all just play nice" mess that came
>     from designating incompatible "versions" of SPF as competing
>     experiments (see https://tools.ietf.org/html/rfc6686
>     <https://tools.ietf.org/html/rfc6686> for the eventual outcome of
>     that six year long experiment).
>
>
> I'm not sure I understand the comparison.  ARC, as far as I know,
> doesn't have two factions attempting to advance their own agendas in a
> common space.  We have just one protocol here.  Instead, the bulk of
> the debate has been about whether this WG is prepared to stand behind
> its processing via the standards track, and I thought we were leaning
> toward the answer to that being "no" right now, and the core issue is
> whether we want it to be standards track first or have an RFC number
> first.  If getting it published in some state is more critical than
> having it on the standards track, then "experimental" is, to me, the
> only option right now.  And that's what I think I said in Singapore.
>
>     I think that any protocol which has not already been widely
>     implemented is, in some sense, experimental - if you are looking
>     at it from the perspective of hind-sight, you might have done some
>     things differently/more efficiently/etc. One might not have called
>     IPv6 "IP"-anything or may have chosen a longer address space for
>     IPv4 for instance.
>
>     I'm willing to go along with the consensus of the group, but
>     wanted to (re)express my continued opposition to the experimental
>     track for this.
>
>
> Dave Crocker can probably articulate this better than me, but I'll
> take a run at it.
>
> 1) ARC is trying to do something that's different enough from DKIM
> (i.e., recording some kind of handling chain) that we really should
> have some deployment and impact experience before we can say we have
> enough confidence to call it a proposed standard; and
>
> 2) The advice that all handlers need to apply a seal to the message,
> to which Bron previously and rather strenuously voiced opposition.  I
> believe the decision was to defer on that issue until we've run some
> real-world experiments, which to my knowledge haven't happened.
> Unless I've somehow missed a change in posture either by him or by the
> specification (which is entirely possible), we're not done enough to
> say it ought to be on the standards track.
>
> proposal, but I think our goals are loftier than that here.  Then
> again DKIM went out PS, right?  Well yes, it did, but we weren't in
> any perceived hurry that I can recall.
>
> -MSK
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Jan 2018 08:44:56 -0800

> While John Levine cited the benefits of the "experimental" approach 
> taken for EAI 
> (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), 
> I think that any protocol which has not already been widely implemented 
> is, in some sense, experimental - if you are looking at it from the 
> perspective of hind-sight, you might have done some things 
> differently/more efficiently/etc. One might not have called IPv6 
> "IP"-anything or may have chosen a longer address space for IPv4 for 
> instance.

Both of the above examples demonstrate a corrupted use of the term, 
pretty much rendering it useless.  Such a rendering does not seem very 
helpful to the community, not does it reflect the intent of the label.

Here's some text that I think points in a more constructive direction:

      https://www.ietf.org/iesg/informational-vs-experimental.html

      "If the IETF may publish something based on this on the standards 
track once we know how well this one works, it's Experimental."

There have been some very specific descriptions of focused concern for 
fragility and interactions about ARC.  Those are what justify 
Experimental.  There needs to be explicit documentation of those 
concerns and suggestions for measuring ARC performance to assess the 
field experiences with regard to those concerns.

I offered examples of these earlier:

      ARC Experimental goals
      https://www.ietf.org/mail-archive/web/dmarc/current/msg03812.html

In an earlier note, I also noted:

      ARC RFC status to target
      https://www.ietf.org/mail-archive/web/dmarc/current/msg03707.html
      "Having intermediaries signing thing and having receivers base 
delivery and labeling decisions on those signatures is new and, I think, 
significantly different that doing that for SPF or DKIM. Who should sign 
and when isn't yet well understood. How those signatures should get 
evaluated by receiving filtering engines also is not yet well-understood."

      Re: [dmarc-ietf] ARC RFC status to target
      "From that perspective, I suspect a good target for marking 
readiness for standardization is the ability of the community to produce 
an experience-based BCP about ARC Use."

      ARC RFC status to target
      https://www.ietf.org/mail-archive/web/dmarc/current/msg03730.html

      Re: [dmarc-ietf] Question for Thursday's meeting consideration: 
extending DMARC DNS record to cover ARC
      https://www.ietf.org/mail-archive/web/dmarc/current/msg03789.html
      "ARC is an underlying authentication mechanism that calls for a 
new assessment mechanism, since the role of the authenticated entity is 
different than the entities currently being assessed by filtering engines. "

So...

These were offered to explain the significant reasons this specification 
is not likely to be well-understood at initial deployment but is likely 
to raise significant operational challenges.  And they offered a basis 
for evaluating initial use, to determine efficacy.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net