Subject: [dmarc-ietf] ARC Experimental goals

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Jul 2017 13:57:03 -0700

Folks,

By way of trying to expand on the discussion about requirements for ARC 
to /exit/ Experimental status and enter standards status/document status...

Internet Mail is a global store-and-forward service with many 
independent operators.  Most Internet Mail is subject to rather simple 
operational scenarios, because most Internet Mail travels between a very 
small number of very large operators.  Their email exchanges essentially 
appear to be one-hop between originating provider and receiving 
provider.  This statistical bias is misleading and creates a perception 
of straightforward operational behavior and requirement.

The full range of global email service has more operators and more 
handling complexity -- producing more interaction effects -- than the 
dominant environments demonstrate.  Note that the expanded use of DMARC, 
into consumer-to-consumer mail, provides an unfortunate example of this 
effect:  not many problems amongst the very large operators but very 
serious problems for some others, such as users of independent mailing 
lists.

ARC produces a /chain/ of signatures.  There is essentially no 
operational experience doing this in real time in the operational 
Internet.  We need to learn what dependencies and what fragilities are 
relevant to its use.

DKIM has demonstrated that a single signature can be broken by a number 
of existing handling scenarios, such as within some operational 
enterprises and through most mailing lists.  It is therefore entirely 
plausible that sending a message through multiple, independent operators 
that are performing ARC signing will also produce breakage -- although 
the ARC design is explicitly intended to minimize this risk.

This is worth emphasizing:  email is an essential infrastructure service 
and ad hoc expansion of the policy scope for DMARC -- another 
authentication-related mechanism -- has produced significant operational 
problems.  While it is possible that ARC will not demonstrate such 
problematic effects, it is also possible that it will.  We should 
approach this issue with due caution.

TIn terms of what it validates, the role of ARC signatures is quite 
different from the role of SPF or DKIM validations.  The nature of this 
new role seems to be a form of 'transitive trust', which unfortunately 
is not encouraging: my understanding is that operational experience with 
mechanisms relying on transitive trust -- especially across multiple, 
independent administrations -- has been problematic.

Integration of new types of validation information into email filtering 
engines has a learning curve.  So far, experience is with a tiny number 
of very large operators.  This sort of activity is amenable to 
special-case, manual configuration, which unfortunately does not expand 
into general, large-scale operation for most/all operators in the global 
Internet.

Therefore, experimental experience with ARC needs to:

      1. Demonstrate use across a 'significant' range of different email 
sending software, receiving software, mailing list packages, mailbox 
operators and mailing list operators.

      2. Demonstrate robust survival of ARC signatures.

      3. Demonstrate useful error reporting behaviors.

      4. Demonstrate stable operational integration into mail filtering 
engines, subject to a 'significant' array of usage policies -- or 
demonstrate industry consensus on a small, stable set of policies.

(Vocabulary such as significant and robust and useful are intentionally 
vague.  Or rather, intentionally subjective.  Determining the specifics 
that will satisfy them is up to the working group and IETF management.)

When these demonstrations are made, it will be possible to write a usage 
BCP that has rich and useful guidance for those wishing to deploy ARC.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Draegen <[email-masked]>
Date: Fri, 21 Jul 2017 09:17:43 -0400

> On Jul 20, 2017, at 4:57 PM, Dave Crocker <[email-masked]> wrote:
> 
> ARC produces a /chain/ of signatures.  There is essentially no operational experience doing this in real time in the operational Internet.  We need to learn what dependencies and what fragilities are relevant to its use.
> 

>     1. Demonstrate use across a 'significant' range of different email sending software, receiving software, mailing list packages, mailbox operators and mailing list operators.
> 
>     4. Demonstrate stable operational integration into mail filtering engines, subject to a 'significant' array of usage policies -- or demonstrate industry consensus on a small, stable set of policies.
> 

> When these demonstrations are made, it will be possible to write a usage BCP that has rich and useful guidance for those wishing to deploy ARC.

Dave, are you saying the production of a rich and useful BCP could mark the end of Experimental status?

-= Tim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Jul 2017 06:27:00 -0700

> Dave, are you saying the production of a rich and useful BCP could mark the end of Experimental status?

Yes.

d/

---

From: Tim Draegen <[email-masked]>
Date: Fri, 21 Jul 2017 18:36:11 -0400

> On Jul 21, 2017, at 9:27 AM, Dave Crocker <[email-masked]> wrote:
> 

Makes sense to me. Perhaps the WG should start collecting information as new deployments are happening.

Some deployers are already sharing. Why not pipe what is learned directly into a BCP.. you know.. in real time?

---

From: Steven M Jones <[email-masked]>
Date: Sat, 22 Jul 2017 09:25:57 +0200

On 07/22/2017 12:36 AM, Tim Draegen wrote:
> Why not pipe what is learned directly into a BCP.. you know.. in real time?

Hmm, perhaps some kind of "feedback report" could be used... ;)