Re: [Mls] Draft charter

Nadim Kobeissi <nadim@symbolic.software> Mon, 05 February 2018 19:19 UTC

Return-Path: <nadim@symbolic.software>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D156112D949 for <mls@ietfa.amsl.com>; Mon, 5 Feb 2018 11:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=JYIASVIQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fqFtq8uC
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_gQXH4-2clh for <mls@ietfa.amsl.com>; Mon, 5 Feb 2018 11:19:10 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B695A1275AB for <mls@ietf.org>; Mon, 5 Feb 2018 11:19:10 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1798F20D1A; Mon, 5 Feb 2018 14:19:10 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 05 Feb 2018 14:19:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JcJ1R1 UdRv3jgtoh96LczOmzGE11oFI2chrBNNSX6ag=; b=JYIASVIQdfnxRbV9s/wS0g az8nbnG4caivIS8oZ86F4xKPjA3VV/zb6UiJuSqvoOn77gh7Bzb8NLr72CpmvOeT 4JbhW0Y0HmVDVSyS/1hhawqxyy0nAMp04x8k60XgNGd78UyoqAK6yeJ5B+aZh0FK v7sT0SnQPCAmQPMmcBoUb1WgF3Lv/8itK0OWIl1A8JdMp2s7nBfhhjsa0htdXo/W wfUJwT5FaA5MKdqcEjwVAPZsv+OkNUaLaB0xtm/Qkx9ibAY91WFEZGQH3l9rxvmE 6lRTlolLScXT+8hdGXi1d0w3HTzI7kcw3C3PVNyPJL+QmDwwXZ2+6zI5/JCt9b9g ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JcJ1R1 UdRv3jgtoh96LczOmzGE11oFI2chrBNNSX6ag=; b=fqFtq8uCfUcFp14USqXm0b 2ujsMZISdlwLsq/2xr7kw3kllX58kz3xI307VgL7tiSDZLvxr/bGK0mZIMITUv6y HLN0fdOjUKB5OWl11WiWXkXY1NvjU4AGH5DdpUd7/ERdEZhcvd5WghOgMu4uPlzJ sETgF8QTcj79YQrZ4c6MwfS+A+zYtg2Ik2VdZGftyfrIzSkzeUk7N3BRCKUfJKQR 0ZFSo35yWcxRdsvgrI3qOJt5+a3x0WzHAxVnSFsMh8m0/S7S6XHe+/ad+ioQEXW0 QH6wGWeu/ooFWb9YhVo0tB1pDBstkgVGNZrT9TWwWJz15wczpCW3HxYbS/NevR3A ==
X-ME-Sender: <xms:Lq54WgAvRrJxYmJDmoF4Rjka8euBnPg0Me36k4_1JIwWO838weJ8Jw>
Received: from [10.209.6.150] (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B2D6245F1; Mon, 5 Feb 2018 14:19:09 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Nadim Kobeissi <nadim@symbolic.software>
In-Reply-To: <CAL02cgRkZPxB-3G0DyKBGp8XpJ18CV=h_y1v1ay+kAq66eDCeA@mail.gmail.com>
Date: Mon, 5 Feb 2018 20:19:08 +0100
Cc: mls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <73F9E545-26B9-4299-B578-3BF1343A07CB@symbolic.software>
References: <CAL02cgRkZPxB-3G0DyKBGp8XpJ18CV=h_y1v1ay+kAq66eDCeA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/cvsV37GKCFcfYxOvjeCJXKGVe7U>
Subject: Re: [Mls] Draft charter
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 19:19:59 -0000

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 <rlb@ipv.sx> 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:
> 
> 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
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls