Re: [MLS] confirming state recovery way forward

Sean Turner <> Tue, 25 February 2020 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23F0E3A110B for <>; Tue, 25 Feb 2020 09:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.585
X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EY55zfqzw6rx for <>; Tue, 25 Feb 2020 09:28:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B9053A110A for <>; Tue, 25 Feb 2020 09:28:25 -0800 (PST)
Received: by with SMTP id l16so225131qtq.1 for <>; Tue, 25 Feb 2020 09:28:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=DFKFUQXFBTFnNRjIvntqrc3Mj3vOGZqv/oqB5OSFzqg=; b=NQjLWjrimsm0rFI6RV2isASSkpZ3GYVlFHFp/n+Jvf8+KghXgcsqbnH4vUlPRtZDjY E9yOYPs4HCFOB93/IRsIr32kjsW+j7DHouOxo7QT1xZ9g0aHct/9AKIcav+Gw+Ekg9yv gYG3HJ6qLS/WM7liOq8Z+OQdxsMvOMn4/7BmU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=DFKFUQXFBTFnNRjIvntqrc3Mj3vOGZqv/oqB5OSFzqg=; b=YU3/wR9JwfnvXEdn6cVEMrLTzAl7+fNvxhh7oFzcAfIoZkQKXuysI8W8EBQb7IXaZ5 wDwnt4CSyr5wPIvwvuIS2m6rzDq0Pb+r9Jgopfj22liWcJCU8UtCrU5JhoA7igcFM763 V9QXVDbSvMPp0PV492fXl2CZiI5nxM4N9Jk4jxEEd7apu+MRPPf1oQg3K/op+X+KQWnu /SJCAf69P2Tt9tbSc2WxXzp2Ox+jnEcfHwQzIJ+601E8PXS4kaHyLAWFpi8Jc1aootXo /GY4H1LGFuxu3PCWdhfkYRVHJuDw7+j7WOhmw3LLfStpOg28+APIdvRpc/FMg3Btoivm 2NtA==
X-Gm-Message-State: APjAAAVxdr6sJcb6ZA63t0bF/9kHvFmxJcJzpa8z4btf422Y5HQkT8kS jMC7nTgorAzJHlf2gv5QyNAwAtxp7H8=
X-Google-Smtp-Source: APXvYqzXJxIJgk9HvKlxKqkDGF5l7DhyeU8qp7lvMsZVF82u9AVVaFAfsW/UtJfv9g7+HGytDCUcFg==
X-Received: by 2002:ac8:741a:: with SMTP id p26mr53694675qtq.76.1582651704209; Tue, 25 Feb 2020 09:28:24 -0800 (PST)
Received: from sn3rd.lan ([]) by with ESMTPSA id i5sm7849611qtq.12.2020. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:28:23 -0800 (PST)
From: Sean Turner <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 25 Feb 2020 12:28:22 -0500
References: <>
To: Messaging Layer Security WG <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Tue, 25 Feb 2020 17:28:27 -0000


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.



> On Feb 6, 2020, at 11:08, 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