Subject: facilitators at [email-masked]

From: IETF Chair <[email-masked]>
Date: Tue, 23 Sep 2014 15:40:11 +0300

In July, we had a discussion both on this list and at the plenary about this list, moderation, discussion styles, tools, and participation in last call and other discussions.

We need to continue thinking about the role of this list and other bigger issues, but I plan to make one small action regarding the list discussions now: adding facilitators. Or to be more exact, delegating some of the facilitation role that I have to additional persons. Occasionally, discussions on the list get heated, repetitive, or unnecessarily personal. When that happens, I have found that quick responses on the list or to the persons often resolves the situation, and productive discussion can continue. However, I am also finding that it is difficult for me personally to stay on top the threads in real time, and late reactions are not as useful. As a result, I plan to ask two persons to help monitor the discussion and steer it towards the most useful avenues.

This is not a change with regards to roles of ADs/shepherds and last calls, or a change to how we deal with disruptive or inappropriate postings, such as PR-actions, sergeant-at-arms, or our spam tools. All those mechanisms will stay in place. The facilitators will not be able to moderate or block posting from anyone (except by reporting issues to the sergeant-at-arms, just like the rest of us can).

Comments appreciated, as always.

Jari Arkko
IETF Chair

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Sep 2014 12:31:38 -0400

> Comments appreciated, as always.

I have thought that there are many occasions where the best use of
meeting time would be to have a facilitated discussion of the issues.

Case in point, did we really need to have two completely separate
email standards? There was absolutely no possibility of common ground?

I have discussed it with the AD who made the decision and he pointed
out that before he made the two groups completely separate there was
no progress on either. But end to end email has been hurt by the fact
that we have two incompatible standards and they are both IETF
standards.

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Sep 2014 14:12:08 -0400

--On Tuesday, September 23, 2014 12:31 -0400 Phillip
Hallam-Baker <[email-masked]> wrote:

>...
> Case in point, did we really need to have two completely
> separate email standards? There was absolutely no possibility
> of common ground?
> 
> I have discussed it with the AD who made the decision and he
> pointed out that before he made the two groups completely
> separate there was no progress on either. But end to end email
> has been hurt by the fact that we have two incompatible
> standards and they are both IETF standards.

In my capacity as the document editor for one of the
specifications I assume you are referring to, I have to confess
to having no idea what you are talking about.

     john

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Sep 2014 11:32:05 -0700

>  to having no idea what you are talking about.

Surely PHB isn't saying that SMTP and the email format docs are 
incompatible?  That would be a nonsensical assertion, since they are 
separate layers (the one is used to transport the other).  Perhaps 
there are two different email standards that perform the same 
functions but are incompatible?  Perhaps S/MIME and PGP?  Or perhaps 
two different security related email specs?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Q: How many surrealists does it take to screw in a light bulb?
A: A Fish.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 16:08:03 -0400

Randall Gellens <[email-masked]> wrote:
    > Surely PHB isn't saying that SMTP and the email format docs are incompatible?
    > That would be a nonsensical assertion, since they are separate layers (the

I think he means OpenPGP vs S/MIME.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Sep 2014 16:08:53 -0400

On Tue, Sep 23, 2014 at 2:32 PM, Randall Gellens <[email-masked]> wrote:
> separate layers (the one is used to transport the other).  Perhaps there are
> two different email standards that perform the same functions but are
> incompatible?  Perhaps S/MIME and PGP?  Or perhaps two different security
> related email specs?

I meant two secure email standards. Empirically we have two right now,
S/MIME and PGP.

Since I was talking about security, I thought it was obvious from the context.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Sep 2014 13:27:14 -0700

> Since I was talking about security, I thought it was obvious from the context.

It wasn't.

And to be thorough, you also forgot PEM...

Anyhow, sometimes we need to let competitive efforts develop and then
let the market choose among them.  Artificially stifling serious
constituenies from pursuing credible alternatives is often poor
engineering and worse politics.

In this case, there really was significant effort to get some amount of
collaboration between the two groups -- the related MIME multipart
constructs were designed to allow some co-habitation -- but it didn't
get any traction.  (One of the groups was particularly political in how
it managed its activities, but neither group was all that flexible.)

FWIW, it's unlikely that the competition in this case has had anything
to do with the poor uptake of either mechanism.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Sep 2014 16:48:29 -0400

--On Tuesday, September 23, 2014 16:08 -0400 Phillip
Hallam-Baker <[email-masked]> wrote:

>> Surely PHB isn't saying that SMTP and the email format docs
>> are incompatible?  That would be a nonsensical assertion,
>> since they are separate layers (the one is used to transport
>> the other).  Perhaps there are two different email standards
>> that perform the same functions but are incompatible?
>> Perhaps S/MIME and PGP?  Or perhaps two different security
>> related email specs?
> 
> I meant two secure email standards. Empirically we have two
> right now, S/MIME and PGP.
> 

Nothing about your note made that clear -- it didn't mention
security generally and you said "email standards".  Be that as
it may, I think you are overlooking a key aspect of the PGP
versus S/MIME problem.   Suppose we actually did have two sets
of email standards, one using SMTP transport with 822-style
"field-name: value-string" headers (as we have today) and other
other of which used SMTP (to avoid making this completely
unrealistic) with ASN.1-like coded X.400-like inner envelope
header structure.  There would certainly be a reasonable
complaint that we had specified two different ways to do the
same thing with only subtle differences in capabilities between
them.

But it seems to me that S/MIME and PGP represent two
fundamentally different trust models.  The first is based on a
certificate hierarchy model, one that would have very good
international scaling properties had we actually figured out how
to make a global single-purpose PKI work and be trusted.  Worse,
absent that type of PKI, it was very hard to think about how to
bootstrap the system, at least without pushing decisions about
which certification authorities to trust back to end users who
had absolutely no basis on which to make those choices.  The
second is based on a web of trust arrangement that most of us
knew at the time wouldn't scale well internationally nor be
usable among parties who didn't have at least a second, or
possibly third, "degree" of connection but that was far easier
to bootstrap than something that assumed a global PKI.

Now it is certainly possible to imagine a message format that
would have more commonalities than we ended up with.  We
actually had standards-track specifications for such a format,
in the form of RFC 1421ff and the earlier RFC1113ff.   I think
it is reasonable to summarize PEM by saying it went nowhere
except that we might have learned a bit from it in building
S/MIME and/or OpenPGP.

So, we are now at a point at which neither OpenPGP nor S/MIME
has achieved wide adoption and use.  We have learned such things
we (at least some of us) didn't anticipate.  In S/MIME's case,
that notably includes issues of trust in CAs and the
effectively-dictatorial (or oligarchic) authority of browser
vendors to determine CA usability.  In OpenPGP's case, we have
demonstrated some of the scaling and key management issues that
some people anticipated all along.  

You seem to believe that more commonality of formats would have
left us in better shape today.  Because I think the problem is
the irreconcilable difference in trust model and relationships,
I believe it would have made almost no difference at all (even
if it were a good idea).  You could be right but, if you want to
make that case, please try to do so in a way that the rest of us
can understand rather than, e.g., making broad assertions about
causes and implications of the IETF's failure to generate a
single standard for secure/encrypted email or email more
generally.

     john

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Sep 2014 16:51:11 -0400

In case it is not clear, I believe that my recent note and
Dave's (partially quoted below) represent complete agreement.
That might be notable because this is one of the spaces in which
we often disagree.

    john

--On Tuesday, September 23, 2014 13:27 -0700 Dave Crocker
<[email-masked]> wrote:

> Anyhow, sometimes we need to let competitive efforts develop
> and then let the market choose among them.  Artificially
> stifling serious constituenies from pursuing credible
> alternatives is often poor engineering and worse politics.
>...
> FWIW, it's unlikely that the competition in this case has had
> anything to do with the poor uptake of either mechanism.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 23 Sep 2014 17:17:49 -0400

> single standard for secure/encrypted email or email more

+1.

I use both OpenPGP and S/MIME on a regular basis and in no case where I use 
one would the other be suitable primarily because of the differences in trust 
models you describe.  While they both sign/encrypt email their use cases are 
disjoint in my experience.

Scott K

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Sep 2014 21:27:39 +0000

> disjoint in my experience.

Apple's Mail.app on desktops allows an S/MIME key to bound via
Keychain to a particular correspondent, without placing any trust
in whatever CA may have issued the certificate.  This makes S/MIME
usable with a TOFU trust-model.

So for me the sweet-spot has been S/MIME with direct (leap of faith)
trust.  I am disappointed when I can't use TOFU with S/MIME in some
other MUAs.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Sep 2014 17:42:10 -0400

> single standard for secure/encrypted email or email more

Well I agree with some of the above but it is a discussion we are
currently having on the endymail list.

My intended point was that if we had had a facilitator then maybe we
could have ended up with rather less unnecessary divergence than we
did and that might have made it easier to resolve the standards war.

Having re-studied this problem in great detail in the past 18 months,
I am certain that S/MIME cannot meet every use case of PGP and
vice-versa. But I am also certain that neither meets more than a
fraction of the real user needs as currently implemented.

http://prismproof.org/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Sep 2014 17:56:05 -0400

> And to be thorough, you also forgot PEM...

No, I didn't because PEM (and MOSS) came first. The original point was
that we might have done better with a facilitator in the room with
both groups rather than both camps removing themselves to different
rooms and throwing rocks at each other in the hallways.

PEM did do one important thing and that is it acknowledged it had failed.

> engineering and worse politics.

Again the point was that we might have tried other means to resolve
the fracture rather than give up without trying.

> to do with the poor uptake of either mechanism.

The two groups think they are Harry Potter and Lord Voldemort, that
neither can live while the other survives.

In practice the continued standards deadlock is allowing both camps to
put off accepting the fact that they have not succeeded. They are both
clinging to existence in the mistaken belief that they will take off
as soon as the other is out of the picture.

PGP has a monopoly on mindshare, S/MIME has a monopoly on deployment.

Its like Betamax vs VHS. If we are going to get endymail deployed we
have to get them to move to BluRay.

---

From: George Michaelson <[email-masked]>
Date: Wed, 24 Sep 2014 09:20:34 +1000

where is CMS multipart in all this?

On Wed, Sep 24, 2014 at 7:56 AM, Phillip Hallam-Baker <[email-masked]
> wrote:

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Sep 2014 19:25:04 -0700

On 9/23/2014 2:56 PM, Phillip Hallam-Baker wrote:
>         The original point was

There were multiple facilitators in that room, back then.

Facilitators cannot help resolve differences in religion or paradigms.

And within the IETF sandbox, facilitation for paradigm differences has
been tried many other times, such as for network management and routing.

It's never been successful and sometimes has made things worse.  (Think
ASN.1 for SNMP...)

...
> put off accepting the fact that they have not succeeded.

Competition has often been quite successful.  Think SNMP/CMOT again, and
various other IETF-based contests.

So while your point sounds like reasonable theory, I doubt it has any
objective basis, since most discussions about the failure to adopt
end2end confidentiality cite barriers in key management and human
factors usability (for end users and for sysadmins.)

IPv6 "won" long ago, but after 25 years still has only modest uptake.
DNSSec stabilized 10-15 years ago, but still has only modest uptake.

Competition is not the barrier causing these sorts of adoption problems.

d/

---

From: IETF Chair <[email-masked]>
Date: Wed, 24 Sep 2014 15:37:45 +0300

Randall,

> This seems reasonable.

Thanks.

> My only questions are why a formal role is 
> needed and why only two people?  I would have thought any of the 
> calmer heads could send private notes to people who get caught up in 
> emotions during a mailing list discussion.  Perhaps it works better 
> to have this done by a very small set of officially-designated people.

I think the two (plus me) is sufficient for the task without overly large effort on any of us. But two wasn’t a hard limit, it was a something to get started with.

I’m not sure how formally we should take this. And certainly all of us follow the discussions and put in a lot of effort to keep the discussions going to the right direction, and react when something isn’t right - thank you for that. This “calmer heads” model needs to continue :-) But at the same time, having designated persons who know they should monitor the discussions is helpful, and ensures that we do have some people looking at the entire traffic.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Sep 2014 16:11:23 +0300

> Facilitators cannot help resolve differences in religion or paradigms.

FWIW, the facilitator model that I announced will be useful, I think, but it is at a different level than resolving fundamental differences about technology direction. I think we can improve discussion style at the IETF (and have, I’d argue). But while having good, civil, rational, and fair discussions is a great thing, it doesn’t remove the situations where, for instance, different groups of people have very different goals or use cases in mind.

> have to get them to move to BluRay.

Like others on this thread, I think the issue has not been so much in the differences between two partially deployed solutions. The crux is having something that works for a broad range of users, easily. And we are *not* there today.

> trust.  I am disappointed when I can't use TOFU with S/MIME in some

Yes - I have a lot of sympathy for this point of view. Taking this slightly more towards the end-user view, not sure I care about what bits are underneath, as long as I can achieve what I need to achieve. For a lot of users that appears to be hierarchical/unconditional trust for their employer’s organisation _and_ the ability to TOFU for the authentication with their friends, family, and external entities. Perhaps TOFU not just with individuals, but also with organisations.

The question is, how much of this is protocol machinery and how much UI design? Maybe we need to put the main e-mail app developers into a room and not let them out until they have prototypes of usable TOFU *and* hierarchical security in their apps :-) I’m joking of course, but it is also true that if the industry needs to do something, they have in many cases come together even as competing entities, and taken on the challenge. Interops, world v6 launch, etc. But I’m not the expert. You guys are - what would help?

Jari

---

From: Nico Williams <[email-masked]>
Date: Tue, 30 Sep 2014 10:53:36 -0500

> Yes - I have a lot of sympathy for this point of view. Taking this slightly more towards the end-user view, not sure I care about what bits are underneath, as long as I can achieve what I need to a…

Right.  S/MIME can be used non-hierarchically, and PGP could be used
hierarchically.  There are very few PK protocols I can think of where
trust mesh or trust hierarchy are so deeply embedded that you cannot
co-opt the protocol to work the other way.

(The one example that comes to mind is DNSSEC, and even there
TOFU/mesh is not unthinkable, just ETOOHARD too manage because of how
removed from the user DNS is.)

This leads me to believe that letting TOFU vs. trust mesh vs. trust
hierarchy lead us to having two end-to-end e-mail security standards
was a mistake, and the trust model discussion is mostly a red herring.

> The question is, how much of this is protocol machinery and how much UI design? Maybe we need to put the main e-mail app developers into a room and not let them out until they have prototypes of us…

For e-mail the protocol is completely separable from the trust model.
Trust hierarchy does not let the UI off the hook, so we might as well
design UIs supporting all PK trust models, not just one.  After all,
an MUA that implements S/MIME and PGP will have to anyways...

Nico
--