IETF Logo Mail Archive

Re: [MLS] MLS in decentralised environments

"Katriel Cohn-Gordon" <me@katriel.co.uk> Wed, 04 April 2018 10:16 UTC

Return-Path: <me@katriel.co.uk>
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 55FBE126DEE for <mls@ietfa.amsl.com>; Wed, 4 Apr 2018 03:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=d+UuJvwL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AxBhX3FK
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 b98UOffW4Im6 for <mls@ietfa.amsl.com>; Wed, 4 Apr 2018 03:16:13 -0700 (PDT)
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 8E8F4124E15 for <mls@ietf.org>; Wed, 4 Apr 2018 03:16:13 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A3BBD20EE2 for <mls@ietf.org>; Wed, 4 Apr 2018 06:16:12 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 04 Apr 2018 06:16:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=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=mesmtp; bh=RuYw8KLXl7Xo9XXEvMR+8vx+oZ EDwoEZ40g9akxDN3o=; b=d+UuJvwLFx8Mutn4T7AucTMYJ8lw3Q6nwESH+1PWi5 B/P0vDCefAK2n8ji4B+IVIc2h5/XVUVQAt+dyxJplSECFHboC85kDIKt8HC/iluF YOkqGhwwH0sNyhxyRk1p8tyKJIffWWr64weKqpAQX882hEJLnfj1QOPIMFzDA+iq E=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=RuYw8K LXl7Xo9XXEvMR+8vx+oZEDwoEZ40g9akxDN3o=; b=AxBhX3FKKUwER87zo1Zyv1 Ow5/5Qr+U0e+6rtq2swMOI5F8vIomu1wVmQ2oP1Fr2bg9gKFNFUm2asgdPrLpaFA Ls4WQ5esO+HXTWL8bNfC7OkCC1jgwlqeEfxmb4uhTMNTUQ4bxw9QIJe1rBaXZduj tg4eifz6sehQuKpZ2wd14cQYB44Rm9wv13b7izzVi4Z+/tFcFaPg6bMP48i1Ryw0 U/Cuwku3/8ISY0uGNVHjuGRHNj+dCufpeZj3o9ZfE7LGErFjhyEIK7IhI9Qsj6TQ OLGImlRN/bbUc05rHOAtGRBgIoyZ/72bCwZQhuNzjItwxl744sUveLEcoUntAtjw ==
X-ME-Sender: <xms:7KXEWuMU1N1PnKFBu6Z-Jzw8Qmn7Lv8gRN17OlyFt6Dhw3RMwwyDnw>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 776849E092; Wed, 4 Apr 2018 06:16:12 -0400 (EDT)
Message-Id: <1522836972.2924642.1326063696.15670680@webmail.messagingengine.com>
From: Katriel Cohn-Gordon <me@katriel.co.uk>
To: mls@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338
In-Reply-To: <CABkgnnVM9HyGxK9=e5byLgTLGBvL1K6TTeO87TLSF17+1vJkig@mail.gmail.com>
References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> <CABkgnnVM9HyGxK9=e5byLgTLGBvL1K6TTeO87TLSF17+1vJkig@mail.gmail.com>
Date: Wed, 04 Apr 2018 11:16:12 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/79QrJlIuwfAU5_xcFMxxVMNDDqk>
Subject: Re: [MLS] MLS in decentralised environments
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: Wed, 04 Apr 2018 10:16:15 -0000

On Wed, 4 Apr 2018, at 3:23 AM, Martin Thomson wrote:
> Is it possible to have a common tie-breaker process and force the
> loser to rebase?

Yes, I think so. Another one would be "the person who has least recently done an update wins ties", which would help with starvation issues. As you point out, the downside is that endpoints might have to keep quite a lot of potential state around in case an old message comes through and requires a large rebase.

I was wondering whether you could have a cap like "never rebase more than five updates ago" or something to prevent that case, but the challenge there is that without a centralised server you don't have a consistent view of how many updates have actually happened. The particularly problematic case is when e.g. A and B do a whole bunch of updates, and then C comes in and preempts them.

Having a centralised sequencing server makes this whole problem go away, sadly.

Katriel

v2.23.0 | Report a Bug | By Email