Re: [MLS] confirming state recovery way forward

"Katriel Cohn-Gordon" <> Fri, 07 February 2020 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B9BE120879 for <>; Fri, 7 Feb 2020 05:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (1024-bit key) header.b=bW9sw/pE; dkim=pass (2048-bit key) header.b=ikhFUIXz
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10Yfc_7p6Db1 for <>; Fri, 7 Feb 2020 05:52:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23DD5120859 for <>; Fri, 7 Feb 2020 05:52:21 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 142B721903; Fri, 7 Feb 2020 08:52:21 -0500 (EST)
Received: from imap35 ([]) by compute6.internal (MEProxy); Fri, 07 Feb 2020 08:52:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=mesmtp; bh=fG Ryk0aybwKGMjg++uEE/JmEF71tyHekiSTpJ7s1uco=; b=bW9sw/pEEFYlDBycwA h8DUKpir5cQp7CyQ9awXAVQEcGl4SRqkeGF4PHfwegn3zkjr+oRUzgQjb/gX6A+3 hrKxIUI9w4Gx3ofNJ+va1qk7q6JBGgE5A+iFDiIIJhx7BY8IjjsrYWc8d/T6gNhS Xi6WF8V/EyAReEA4A0OkJmjFs=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=fGRyk0aybwKGMjg++uEE/JmEF71tyHekiSTpJ7s1u co=; b=ikhFUIXzKXDX6fsEQYgVbUBW7Ivne6M/6rcOHNTFvrXkWCRYy6i4o7k2K 3XRWhuw/JGv2KJcuHAzl7dOgEKuRxZ/HRzYCXRI/cC0RA+CtrRrCaedK1zhtf8+k d0+rr7aI/+nd79Q9BG0ph6VkDh2O1Q9KzDGTs5RQ6CKzAegNIAEMIade2fB9TogF wA2/huoJ6JVFbWUmZqOJK8HYAPQFGvHxb/+IAuVtNC9mYsGR1CxGWISjopnVkdNK THzXHt9Y/Pn8jE2/iKh9aT1leiTntua1fm5IAineBCrx+jzoLlWRkcTJqrm2lz18 4ZMlS+KbGL6qzZvwyM0bEpszpHF0Q==
X-ME-Sender: <xms:lGs9Xq2ZoJlc1FjTqsBIzs6emDqFkQ7hFp2avQwrIS9Pujfyt-xm8Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfmrght rhhivghlucevohhhnhdqifhorhguohhnfdcuoehmvgeskhgrthhrihgvlhdrtghordhukh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmvgeskhgrthhrihgvlhdrtghordhukh
X-ME-Proxy: <xmx:lGs9Xifw2ewSUKpuaccnl-0uU4VbJMhm1us89pgsXrH2MtiQjh0Syw> <xmx:lGs9XjExr_c6rJXk2AP7nH3Ff9apOE8hqfHZoUmTewGvNtDorSyWDg> <xmx:lGs9Xr2KCFYy6GOxLj1OLh6gJZVGtzsMqikBDV6Xd-Dc6bVGyQ8XVQ> <xmx:lWs9XniKwCNE_DBkmLeEqjKd-Zl0SoiqFbcagd1ABXX8fZIjMLQD7A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C92F14C00F5; Fri, 7 Feb 2020 08:52:19 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Fri, 07 Feb 2020 13:51:59 +0000
From: "Katriel Cohn-Gordon" <>
To: "Sean Turner" <>, "Messaging Layer Security WG" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [MLS] confirming state recovery way forward
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 13:52:24 -0000

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