Subject: [MLS] confirming state recovery way forward

From: Sean Turner <[email-masked]>
Date: Thu, 6 Feb 2020 17:08:06 +0100

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

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Fri, 07 Feb 2020 13:51:59 +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:
> 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.
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 7 Feb 2020 14:55:18 +0100

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 <[email-masked]> wrote:
>

---

From: Raphael Robert <[email-masked]>
Date: Fri, 7 Feb 2020 17:14:28 +0100

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

Raphael

> On 7 Feb 2020, at 14:55, Benjamin Beurdouche <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Feb 2020 12:28:22 -0500

Hi!

I am going to go ahead and confirm that WG’s consensus for the plan outlined below.  I also confirmed with Emad and Jon that they are still willing to start the individual draft. The WG will then consider whether it is a good starting point. Hoping that we can review the draft at IETF 107.

NOTE: 2020-03-09 UTC 23:59 is the submission deadline for IETF 107.

Cheers,

spt

> On Feb 6, 2020, at 11:08, Sean Turner <[email-masked]> wrote:
> 
> Hi!
>