[MLS] P2P operation of MLS?

Ian <ianopolous@protonmail.com> Fri, 14 June 2019 16:57 UTC

Return-Path: <ianopolous@protonmail.com>
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 5E344120186 for <mls@ietfa.amsl.com>; Fri, 14 Jun 2019 09:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
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 9QB8XHVia0bC for <mls@ietfa.amsl.com>; Fri, 14 Jun 2019 09:57:53 -0700 (PDT)
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4BD1205FC for <mls@ietf.org>; Fri, 14 Jun 2019 09:57:51 -0700 (PDT)
Date: Fri, 14 Jun 2019 16:57:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1560531469; bh=kZnE5uMT1EvDUPA5IevvM6GDn6kk8Z3cqKn5si0B1+s=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=LCCgIyblKI8zNresgE4tVumm+7UftoIFvcHczIixu45imU+K4C/HdZ6X+P2DrEBHv iq0ptvuTaghV/pNxiktR0sBhYVf7mE3GTsOmdzrFfYwVDJUIziEQBGR09jH98KfzBQ iMCMzVvyahOzxgF9K4jTS7RJuf1IUkNWsO2IKfR0=
To: "mls@ietf.org" <mls@ietf.org>
From: Ian <ianopolous@protonmail.com>
Reply-To: Ian <ianopolous@protonmail.com>
Message-ID: <Ta-Q2sJ3KLUsT_X185rtwilKxvEnEBMH-3IqNActDdcfrH7cepYS7oPBbYEv5guPt6b4fU0eRB_bEWGD3a_ZwygO7JocO6DMYC-0EeKm7Ew=@protonmail.com>
Feedback-ID: H1veCrExs7KBsBDnLUM0Kd8bl1OyJ7rKqET0jLFaSel3aFjbg1QfbnTy5F7ptCUBzu0p5GVlzoBculqXLGFxiw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c5431713387cd5910384d98eee34995"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/qQrT8H-VkNXqUwGBd66fNqyU0l8>
Subject: [MLS] P2P operation of MLS?
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Jun 2019 16:57:56 -0000

Hi All,

I'm the founder of Peergos [1], a decentralised end-to-end encrypted storage and social network built on top of IPFS [2]. I'm looking for an appropriate protocol for large group chats and was pointed toward MLS. I am looking into the possibility of implementing and using MLS in Peergos in the future.

The main thing I currently have questions about is the delivery service (We have a pki that fits perfectly the authentication service). The main question is whether MLS will still work in a fully P2P store and forward network. The setup I'm imagining is logically equivalent to each member of a group storing their own append only list of messages in the group. When they themselves send a message they just append to their own copy. Other members have access to each other member's version, and periodically merge in any new messages to their own copy. This preserves the order of messages from a given user, and ensures that dependent messages are before those that depend on them. Would this suffice?

The other related question is if there is a network partition, my understanding so far is the two halves of a group can still continue messaging amongst their partition (in their view the other half is just offline), and eventually the halves could reconnect and merge and receive all the messages from the other half, updating the treekem as they go. Is this correct?

One small comment on my readings so far: In my opinion the directory service where the initial key material is obtained from is logically distinct from the delivery service and should be described as such, giving three architectural dependencies.

p.s. I live in Oxford (UK) and would love to meet the Oxford based members if they are interested.

Many thanks,
Ian Preston

[1] https://github.com/peergos/peergos
[2] https://ipfs.io

--
Dr Ian Preston
Peergos
@peergos
https://peergos.org