Subject: [dmarc-ietf] ARC RFC status to target

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jul 2017 11:09:41 -0700

G'day.

Noting the considerable efforts and progress on ARC specification, 
implementation and testing, I've given some though to the status that 
makes sense for the RFC that will result.  The obvious assumption is 
Proposed Standard.

I've come to believe that it makes more sense, at this stage, to seek a 
status of Experimental.  That's not meant as a criticism of the work, 
but rather to accurately reflect the current understanding of ARC dynamics.

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.

I think there is enough activity and commitment by a significant portion 
of the email operations community to gain the necessary understanding in 
a reasonable amount of time.  However introducing an authentication 
mechanism into a trust-assessing mechanism -- where the system dynamics 
are not yet well-understood -- seems to me to be worthy of some formal 
caution.

Experimental status is exactly for this purpose.

Thoughts?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jul 2017 14:29:32 -0400

> Experimental status is exactly for this purpose.

I always feel like experimental status ought to come with some
description of what success or failure would mean and how that would
be determined.  I think that is aligned with (but not entailed by)
https://www.ietf.org/iesg/informational-vs-experimental.html.  And it
seems to me that the reasoning in this case suggests that one might
indeed be able to offer such a description.

I know that it would have been _very helpful_ during SPFBIS if we'd
had some way of knowing what counted as evidence, and for what, so at
least for the sake of future chairs who'll have to evaluate the
"experimental" status, it might be nice to offer such guidance.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Steven M Jones <[email-masked]>
Date: Fri, 7 Jul 2017 11:57:36 -0700

On 7/7/17 11:29 AM, Andrew Sullivan wrote:
> be determined.

Would there be a proposed schedule for that evaluation to take place? I
don't so much disagree with the description of how Experimental status
/should/ work, and including evaluation criteria would make sense. But
I'm not thrilled with the idea of ARC being left on the Experimental
track for umpteen years...

--S.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jul 2017 15:12:51 -0400

> track for umpteen years...

It's a good question, but I have two responses:

1.  IETF timelines are worth approximately what one pays for them :)

2.  The lack of criteria by which to evaluate the experiment was
itself one of the reasons offered for not undertaking a move from
experimental sooner.  So not having the criteria will do nothing to
prevent the dragging on.  (Of course, not classifying as experimental
_will_ prevent that dragging on, but comes with the downsides that
Dave was suggesting.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Steven M Jones <[email-masked]>
Date: Fri, 7 Jul 2017 12:50:36 -0700

On 07/07/2017 12:12, Andrew Sullivan wrote:
>> Would there be a proposed schedule for that evaluation to take place?

:D

> _will_ prevent that dragging on, but comes with the downsides that

I may be misreading your response, but I wasn't suggesting a timeline
without criteria. I would hope to see criteria and a provisional
timeline for when to apply them. "A, B, and C will be tracked and
evaluated at IETF 101, next move to be decided then" or something
vaguely similar.

Perhaps the criteria would be included in the RFC, and the review would
be added to the WG's work items? I'm not sure how it's usually done...
Do Experimental RFCs ever get expiration dates as a forcing function,
the way Internet Drafts do?

--S.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Jul 2017 16:05:06 -0400

> _will_ prevent that dragging on, but comes with the downsides that

RFC 4408 said review after two years and we didn't get around to it for six.  
It isn't going to get re-reviewed until there is a critical mass of interest 
in doing so.  I don't think the timeline is helpful.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Jul 2017 22:57:12 -0700

> indeed be able to offer such a description.

I would expect the same, especially since the only RFCs I've ever worked on
that were Experimental had to have this sort of thing before the IESG would
let it go.  So, yeah, +1, etc.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Jul 2017 23:00:36 -0700

> the way Internet Drafts do?

For example, Section 7 of RFC6541 didn't lay out a timeline (it probably
should have, but then capping an experiment executed by volunteers seems
silly), but it made it clear that this was an experiment and someone was
collecting results and would report back.  Since there were only ever two
implementations that only involved a fingers-on-one-hand number of domains,
no report was ever made.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Jul 2017 23:05:16 -0700

On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker <[email-masked]> wrote:

> status of Experimental.  That's not meant as a criticism of the work, but
> rather to accurately reflect the current understanding of ARC dynamics.
>
> 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.
>

I think at the time DKIM went to Proposed Standard, one could've made the
same argument about it as well, especially on your last two points.  On the
other hand, DKIM back then had way more investment of person-hours on
implementations and WG list participation than DMARC and ARC do now, so I
had a lot more confidence in the final product.

I also think there's enough in flux about the current base document for ARC
that I would argue pretty hard for Experimental if we were pressed to
publish sooner.  It doesn't feel "done" to me.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 8 Jul 2017 06:10:30 -0700

On 7/7/2017 11:05 PM, Murray S. Kucherawy wrote:
> On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>     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.
> 
> I think at the time DKIM went to Proposed Standard, one could've made 
> the same argument about it as well, especially on your last two points.  
> On the other hand, DKIM back then had way more investment of 
> person-hours on implementations and WG list participation than DMARC and 
> ARC do now, so I had a lot more confidence in the final product.

      0. I should note and stress that my suggestion is not based on any 
concern about the very low-level mechanics of ARC.  First, signing an 
object is an extremely well-understood algorithmic component mechanism. 
Second, ARC derives from DKIM, which moves the component mechanism 
maturity question out from general theory to specific practice.

      1. The components and dynamics of DKIM are quite straighforward. 
I think the only construct that might be called problematic is the 
selector, and the problem is one of nuance, not basics.  Anyhow, the 
IETF wg DKIM spec was really version 4 of the work.  Yahoo had done 2 
versions and the ad hoc private consortium that created DKIM did 
another.  So although the wg changes were substantive, they were not 
fundamental and DKIM was really quite mature, far beyond IETF norms for 
Proposed.

     2. The mechanics of cascading signatures that ARC does /is/ unusual 
and possibly unique. I believe the only operationally established 
exemplar in this space is the X.509 cert signature hierarchy.  However 
it is an relatively static, offline-signature model for signing the cert 
hierarchy -- as opposed to the dynamic act of using the cert to sign 
payload -- while the cascading ARC signature sequence is entirely on the 
fly. Both technically and operationally, this is a non-trivial point. 
The simplest aspect of this is that we don't know how fragile this will 
prove.

    3.  Having the receiver filtering engine evaluate intermediaries in 
the way that ARC enables is, I believe, new.  In terms of the usual 
filtering models I also believe it is conceptually quite different, or 
at least not widely appreciated.

    4.  Whether or how to evaluate the origination identifier, through 
the ARC-signed Results packaging, is also new and involves a model of 
indirect trust that I believe has not be done before (or, again, at 
least not widely.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 8 Jul 2017 10:55:42 -0700

1. The components and dynamics of DKIM are quite straighforward. I 
think the only construct that might be called problematic is the 
selector, and the problem is one of nuance, not basics.  Anyhow, the 
IETF wg DKIM spec was really version 4 of the work.  Yahoo had done 2 
versions and the ad hoc private consortium that created DKIM did 
another.  So although the wg changes were substantive, they were not 
fundamental and DKIM was really quite mature, far beyond IETF norms for 
Proposed.

     2. The mechanics of cascading signatures that ARC does /is/ unusual 
and possibly unique. I believe the only operationally established 
exemplar in this space is the X.509 cert signature hierarchy.  However 
it is an relatively static, offline-signature model for signing the cert 
hierarchy -- as opposed to using the cert to sign payload -- while ARC 
is entirely on the fly. Both technically and operationally, this is a 
non-trivial point.  The simplest aspect of this is that we don't know 
how fragile this will prove.

    3.  Having the receiver filtering engine evaluate intermediaries in 
the way that ARC enables is, I believe, new.  In terms of the usual 
filtering models I also believe it is conceptaly quite different, or at 
least not widely appreciated.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 Jul 2017 11:24:30 -0700

On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker <[email-masked]> wrote:

> and possibly unique. I believe the only operationally established exemplar
> in this space is the X.509 cert signature hierarchy.  However it is an
> relatively static, offline-signature model for signing the cert hierarchy
> -- as opposed to using the cert to sign payload -- while ARC is entirely on
> the fly. Both technically and operationally, this is a non-trivial point.
>    3.  Having the receiver filtering engine evaluate intermediaries in the
> way that ARC enables is, I believe, new.  In terms of the usual filtering
> models I also believe it is conceptaly quite different, or at least not
> widely appreciated.
>
>    4.  Whether or how to evaluate the origination identifier, through the
> ARC-signed Results packaging, is also new and involves a model of indirect
> trust that I believe has not be done before (or, again, at least not
> widely.)
>

There's interest verging on anxiety to get this deployed, and thus there
are both private and public implementations of it that are relatively
stable (modulo some open questions about the draft content).  It won't be
long before we're able to gather efficacy details based on live operation,
even if the draft hasn't been given an RFC number yet.

But you're right, there's some new stuff here, and strange side effects
could take a while to manifest, or it could take us a while to figure out
how to deal with them when they appear.  So if it's more important to get
an RFC published than it is to wait for some modicum of deployed maturity
-- which will take months, at least, I would guess -- then Experimental is
indeed something we should consider, and I also agree with Andrew that the
experiment should be reasonably well described and bounded.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 8 Jul 2017 11:45:05 -0700

On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote:
> stable (modulo some open questions about the draft content).  It won't 
> be long before we're able to gather efficacy details based on live 
> operation, even if the draft hasn't been given an RFC number yet.

I think the document can introduce itself better and give a more helpful 
conceptual framework at the start.  But that's not a comment on the 
technical details.  While it's possible that there is some interesting 
technical deficiency lurking there, I'm not especially worried about that.

Rather...

> could take a while to manifest, or it could take us a while to figure 

It's these sorts of issues.  I'm reacting from intuition here, not a 
specific bit of insight or concern.  Just a general feeling that the 
operational dynamics of this require some breadth of experience.

> out how to deal with them when they appear.  So if it's more important 
> to get an RFC published than it is to wait for some modicum of deployed 
> maturity -- which will take months, at least, I would guess -- then 
> Experimental is indeed something we should consider, and I also agree 
> with Andrew that the experiment should be reasonably well described and 
> bounded.

If I thought that bench-testing would suffice, then I'd suggest doing it 
and holding the RFC until we get the results.  But I think the question 
of dynamics and operations is more complex and requires some breadth of 
deployment experience to resolve.  (Even if 'resolve' means a solid 'no 
problems' comeback rather than any interesting statements about nuance 
or implication.)

On the matter of a goal for the experiment I'll repeat that I think we 
merely need to target development of a Deployment and Use BCP.  When we 
have good community support for the contents of such a document, based 
on significant experience, then the spec will be ready for standards track.

(The formal rules for Proposed do not require field experience or even 
implementation.  Except sometimes.  And there's no clear rule about when 
it's required.  My own sense of the rule is "when we don't adequately 
understand how it will work in the real world and especially when 
problems could have an infrastructure effect."  I see this as one of 
those cases.)

d/

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 9 Jul 2017 08:44:37 +0100

> On 7 Jul 2017, at 20:50, Steven M Jones <[email-masked]> wrote:
> 

No expiration date by default.

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2017 01:22:35 -0000

In article <[email-masked]>,
Murray S. Kucherawy  <[email-masked]> wrote:
>same argument about it as well, especially on your last two points. 

Sorta kinda.  At that point there wasn't any question that people
would use it to tie messages to domain names, since domainkeys already
did that.  We still have no consensus on what you do with the domains once
you have them.  With ARC, I expect it'll be pretty clear whether stuff
forwarded through mailing lists and the like is getting through.

>publish sooner.  It doesn't feel "done" to me.

Agreed.  I expect that after a six months or a year we'll have a lot
better idea whether ARC is fixing the mailing list issues and what
tweaks might help.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 11 Jul 2017 08:39:12 -0700

On Sat, Jul 8, 2017 at 11:45 AM, Dave Crocker <[email-masked]> wrote:

>> . . . if it's more important to get an RFC published than it is to wait
>> for some modicum of deployed maturity -- which will take months, at least,
>> I would guess -- then Experimental is indeed something we should consider,
>> and I also agree with Andrew that the experiment should be reasonably well
>> described and bounded.
>>
>
> and holding the RFC until we get the results.  But I think the question of
> dynamics and operations is more complex and requires some breadth of
> problems' comeback rather than any interesting statements about nuance or
> implication.)
>
> have good community support for the contents of such a document, based on
> significant experience, then the spec will be ready for standards track.
>
> understand how it will work in the real world and especially when problems
> could have an infrastructure effect."  I see this as one of those cases.)

Now being back at the keyboard after our "Christmas in July" break, I see
lots of threads going on about the spec. I will endeavour to have at least
some talking points regarding a proposed goals and evaluation framework for
an experimental foray as well as seek to integrate all the other feedback
into a draft update.

Regarding timelines, I think that we can have wishes and hopes, but, since
we will now be holding our seventh(!) interop event during the IETF99
hackathon, I don't expect that "months" is even the right scale upon which
to base our expectations. Maybe thinking that we could draw some
conclusions before IETF110 would be more aligned with reality (and yes, I'm
keeping in mind that even _this_ is subject to the planning fallacy). But I
don't think that it will provide any benefit to put this into the draft.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Jul 2017 20:35:59 -0700

> don't think that it will provide any benefit to put this into the draft.

IETF 110 is in March 2021, location TBD.  Isn't that a bit of an aggressive
timeline for this kind of work?  ;-)

-MSK