Re: [MLS] confirming state recovery way forward

Raphael Robert <raphael@wire.com> Fri, 07 February 2020 16:14 UTC

Return-Path: <raphael@wire.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 BB19A12094D for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 08:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.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 kr7x26RL6hEL for <mls@ietfa.amsl.com>; Fri, 7 Feb 2020 08:14:37 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D91120940 for <mls@ietf.org>; Fri, 7 Feb 2020 08:14:31 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id c9so3337308wrw.8 for <mls@ietf.org>; Fri, 07 Feb 2020 08:14:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sNreh1qZGwjzMjVXk/lCP4mxQX+Avi6tn9AEaFj+mmY=; b=JUYIXBZ1lQvQ3CKQ9rAELNsjmRrMOlkvSwAUJLXJrqwpHuOm8Parft6+FvHYbGZmm4 nf7of7jvexdQvBm7lvMtMtF2qSg9kJUbQOSvy7j7pTMlRtoOXInQZ/hNpcO8RSw2XoOt zm8MlCQwemTPtB1YpTWn1zzTBSxfX1TwSx9fXdlS9mBm4DMyialYzw0q3w7H/rvONA3b doJPi7bRosUMSRsBYgiV1XFE6FhjKSJUk4oZvf/hx5zpp0iwFvO3qQkam4KkJ27O/dAc NMEUoz19imwIBXOWMqsQep6JbVLqrPEFmXY3XscLrc8ui7eSMxJf5P9ogITOmfw1GJY8 i5uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sNreh1qZGwjzMjVXk/lCP4mxQX+Avi6tn9AEaFj+mmY=; b=hA+v1tiHD1t5OZGP5mENX3S0/OdC+rh/86Tla0epssz+pIZpwozE3p/foqRn8kgH7w ZzqlE6KsCEoY2JSAZHApVeqfMfheHghBjFooCLupvU4XrOTg+AgPuBzyEuWNpcYBWdIO o7uCMzVyw28OXqhASWBcC+1arAOhSY6nxKVhiF+FYYv55Zn0ePr1U6jA32I+WSeB7kLu MDE+b0le7okay4WnotJuMlUoikzCH7hbzDVlNwVQkOGcGaWpsoiZbMrvSw0XW1yr9tu2 59EXr5fsQa6JQzUivpWhvlbptd5Jgwk3sUCpGd2nlGLvYOUwgo3Wxc/C3Oj2e5ffi5Xi jWYQ==
X-Gm-Message-State: APjAAAVdEAlAl+NGCrGXnnu3DF91xI9f1y1OGBIaApW8quTzhhHXB8rS kd3hg2MfHjoagaYYgRkGKXztdg==
X-Google-Smtp-Source: APXvYqzDIBl8YV2LpFab0+CNa7YPxRyV3qmxp3mo4LiqdTNy90ytiSvfyaEMxUuoYsiT4z9p96oRPg==
X-Received: by 2002:a5d:438c:: with SMTP id i12mr5319009wrq.51.1581092070238; Fri, 07 Feb 2020 08:14:30 -0800 (PST)
Received: from [10.54.170.200] ([88.128.88.49]) by smtp.gmail.com with ESMTPSA id l131sm3954191wmf.31.2020.02.07.08.14.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 08:14:29 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Raphael Robert <raphael@wire.com>
In-Reply-To: <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr>
Date: Fri, 7 Feb 2020 17:14:28 +0100
Cc: Katriel Cohn-Gordon <me@katriel.co.uk>, ML Messaging Layer Security <mls@ietf.org>, Sean Turner <sean@sn3rd.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA069996-896A-4D0A-97AC-8E8044A5D3C4@wire.com>
References: <BF65A8FF-7AE0-454B-A1C3-08558EDE97F9@sn3rd.com> <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com> <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0EY_sqcLRewkS3LBjQEvSxuIZWA>
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 16:14:40 -0000

I also agree with this for all the reasons mentioned above.

Raphael

> On 7 Feb 2020, at 14:55, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
> 
> 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
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls