Subject: Re: [MLS] [Mls] Comments on Charter

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Mar 2018 11:57:37 -0400

Hey Simon,

Thanks for the comments, sorry for the delay.

On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger <[email-masked]>
wrote:

> 1. I think key transparency should be mentioned. Key distribution is a
> huge semi-solved problem and leaving it out is not really an option. It
> seriously degrades security for the average user who does not validate
> keys.
>

Obviously, I agree that authentication is very important, but from what
I've heard talking to people, there's not energy to do KT right now.  What
we can do now is make sure there's a slot to put a credential in, so that
we can leverage things like PKI that provide some benefit over manual key
comparison, and later on we can recharter to work on KT if there's interest.

To clarify this, I added the following para:

"""
While authentication is a key goal of this working group, it is not the
objective of this working group to new authentication technologies.
Rather, the security protocol developed by this group will provide a way to
leverage existing authentication technologies to associate identities with
keys used in the protocol, just as TLS does with X.509.
"""

> 2. Federation (for example like in XMPP, where many people run their own
> servers just like for e-mail) probably doesn't require anything specific
> but it should be discussed to make sure that it works. It would also be
> good to take this into account when discussing authentication and key
> transparency to make sure it is clear which guarantees hold for people
> on other servers. I think it doesn't necessarily have to be in the
> charter but should be in any final proposal.
>

I think the critical thing to test / validate is that we have
interoperability at the level of the specification of the protocol.  Just
like BoringSSL and NSS interoperate at the level of TLS, but don't assure
interoperability of HTTP running over them, we should be aiming for a
security protocol that's interoperable between independent implementations,
but not worried about interoperability of the rest of the stack.

I did make the following tweak to the charter language, though:

"to enable interoperability" -> "to enable interoperability / federation"

>
>
> Best Regards,
>
> Simon
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 15:34:56 +0000

IMO the charter should just say we're adopting these documents as a
starting point, with an explicit disclaimer about how everything needs
consensus (the QUIC charter has some good text here). They're in a pretty
mature state and reflect what there's already been enthusiasm for.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Sun, 18 Mar 2018 15:45:19 +0000

That sounds good to me.  I've added the following text to the Google Doc
(adapted from the QUIC charter):

"""
The specifications developed by this working group will be based on
pre-standardization implementation and deployment experience, and
generalizing the design described in:

* draft-omara-mls-architecture
* draft-barnes-mls-protocol

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set does not imply that there is
consensus around the feature or around how it is specified.
"""