Re: [MLS] confirming state recovery way forward

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Fri, 07 February 2020 13:55 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 A809A120859 for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 05:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 B4zyXIlDRJGd for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 05:55:21 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 340B4120048 for <mls@ietf.org>; Fri, 7 Feb 2020 05:55:21 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,413,1574118000"; d="scan'208";a="434949973"
Received: from corp-nat.untrust.par2.mozilla.com (HELO [10.235.30.91]) ([185.155.183.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2020 14:55:18 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
In-Reply-To: <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com>
Date: Fri, 7 Feb 2020 14:55:18 +0100
Cc: Sean Turner <sean@sn3rd.com>, ML Messaging Layer Security <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr>
References: <BF65A8FF-7AE0-454B-A1C3-08558EDE97F9@sn3rd.com> <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com>
To: Katriel Cohn-Gordon <me@katriel.co.uk>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/sJVn1zGzsVOydyEUGwfB_S4vh0M>
Subject: Re: [MLS] confirming state recovery way forward
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, 07 Feb 2020 13:55:24 -0000

I agree with Katriel and support this effort, writing down requirements
and explore possible solutions to determine possible impact on the
security goals feels like a good way to make progress…

B.

> On 7 Feb 2020, at 14:51, Katriel Cohn-Gordon <me@katriel.co.uk>; wrote:
> 
> I support this effort: this is one of the places where the gap between analysis and implementation is quite large, because all reliable messaging systems have a form of state recovery. While we can't necessarily fix all the issues, writing them up with a goal of at least making sure people are aware of them seems like a very good idea to me.
> 
> On Thu, 6 Feb 2020, at 4:08 PM, Sean Turner wrote:
>> Hi!
>> 
>> tl;dr: confirming new individual draft that describes state recovery 
>> (i.e., the need for ACKs/NACKs).
>> 
>> During the F2F Interim in January, the WG discussed how to address 
>> state recovery. One reason you might want ACKs/NACKS is if you sent a 
>> Commit and then some data, and the Commit is lost. In this case, your 
>> data didn’t get sent and the data needs to be resent. There are obvious 
>> implications because messages shouldn’t just be re-sent to the group 
>> after many months. After a lengthy discussion about this and other 
>> synchronization issues, the consensus at the interim was that an 
>> individual draft is needed to describe state recovery-related issues. 
>> After this draft is published, the WG can review it and decide whether 
>> it should be accepted as a workable starting point and potential WG 
>> item or be merged into an existing draft.
>> 
>> The chairs need to confirm the interim’s consensus on list, so please 
>> let the WG know by 2359 UTC 20 February whether you disagree with the 
>> way forward and why.
>> 
>> FYI: Jon and Emad volunteered to write this draft.
>> 
>> Cheers,
>> Nick and Sean
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>> 
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls