Subject: [Mls] Draft charter

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Feb 2018 10:20:43 -0800

Hey all,

In order to establish a working group, we need to have a charter that
describes what the WG is supposed to do.  Agreeing on the charter will be
one of the major things to do at the BoF.  To get ready for that, I've put
an initial draft (based on the BoF request text) in this Google Doc:

https://docs.google.com/document/d/1OrvqnLsnVDQBN1fnlzkfBoS31vyQVk5Zs-a-tz99ku4/edit?usp=sharing

Feel free to suggest edits or put comments there, but if there's anything
that needs discussion, please reply in this thread instead.

Thanks,
--Richard

---

From: Nadim Kobeissi <[email-masked]>
Date: Mon, 5 Feb 2018 20:19:08 +0100

Dear Richard,
Congratulations on getting this list off the ground.

I think that TLS 1.3 was a revolution in how a protocol gets discussed, specified, proven secure and implemented. I think that if we are diligent and disciplined, we can expand the methodology from which TLS 1.3 benefited from a single precedent to an entire new institution.

It’s possible that the MLS Charter is a good opportunity to make sure the scope of this effort is reined it early on. One problem I noticed when first reading though mls-architecture-00 is that, while federation is specified, it seems to be spoken of quite generally:

"3.1.6.  Federation
   The protocol aims to be compatible with federated environments.
   While this document does not specify all necessary mechanisms
   required for federation, multiple MLS implementations should be able
   to interoperate and to form federated systems.”

Now, to quote the present MLS charter:

"It is not a goal of this group to enable interoperability between messaging applications.  That would require alignment at many different layers beyond security, e.g., standard message transport and application semantics.  The focus of this work is to develop a security layer that different applications can adapt to their own needs."

mls-architecture-00 and the charter and not necessarily in contradiction, but the problem is that this isn’t entirely clear. Does a federated environment include the possibility for interoperable applications? If not, are we then considering that a single application will have multiple user namespaces which will then federate? If it’s the latter, then there is an entirely new level of specification that becomes necessary, too.

This is a danger I’d like to get out of the way at some early point, especially since federation is a topic with a lot of opinions. I think we need to be very clear, from as early on as possible, what we mean by federation and interoperability, and how far we are willing to go with regards to it. It might be wise to rule it out entirely from the scope of this effort, but my preferred situation would be us being able to determine some reasonable subset of federation features that is small and self-contained enough to not grow beyond what this WG is capable of, but still capable enough to allow MLS to succeed within that dimension as well.

Thank you for this important effort. There are many other important points that I am very much looking forward to discussing with you all.

Regards,

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office

> On Feb 5, 2018, at 7:20 PM, Richard Barnes <[email-masked]> wrote:
> 
> Hey all,
> 
> In order to establish a working group, we need to have a charter that describes what the WG is supposed to do.  Agreeing on the charter will be one of the major things to do at the BoF.  To get ready for that, I've put an initial draft (based on the BoF request text) in this Google Doc:
> 
> Feel free to suggest edits or put comments there, but if there's anything that needs discussion, please reply in this thread instead.
> 
> Thanks,
> --Richard
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls