[MLS] confirming state recovery way forward

Sean Turner <sean@sn3rd.com> Thu, 06 February 2020 16:08 UTC

Return-Path: <sean@sn3rd.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 8250E120952 for <mls@ietfa.amsl.com>; Thu, 6 Feb 2020 08:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Z6hfXShXuwce for <mls@ietfa.amsl.com>; Thu, 6 Feb 2020 08:08:10 -0800 (PST)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 0F21F120921 for <mls@ietf.org>; Thu, 6 Feb 2020 08:08:10 -0800 (PST)
Received: by mail-qv1-xf30.google.com with SMTP id db9so3103236qvb.3 for <mls@ietf.org>; Thu, 06 Feb 2020 08:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=B8/ySKe8xCa1F+ZKWx7wu77POMi3PKHXhrQZg5GFsbA=; b=j1nCC8nUKrSB/zMbGTxI26DmR2mDE7meds8EGw538bg+VDfbEy9nMGJrdWUq9rUhqp Ia4hzm1y2sud/4M7Q1YYOrLdFgD/Ddv43IO5t35v9IE6xSAmK4u4pWew8Qqdsbf9/zKe M2hr25p/3fAwBq1pIgwPJyycXGfNZBb3AZj/o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=B8/ySKe8xCa1F+ZKWx7wu77POMi3PKHXhrQZg5GFsbA=; b=UFhuwbGRva9y315ei/rpk8yuwDYv9KeibdX2F+1U/KISogLlK2bKawS4oAlvZ7QOVE 6YOii6te7JfatJ3yEn6dpJ99lZ22hOtvO2TrKl0c6Nhwsq6lo01Ik3/b9y74qZ8goxVf PRO4u3JlSXChxWG0grRB9DbxHYCYPm/hipXR5akJhraTXrRRfvlPlrVMLyjbiriqmHVG K7YpJwICcQ0nVmW9FDHCJpwE6MCuVXlXJejL+BaGOL4Q47JOIbKkZjyLopqJ/Xi8xIuQ gIxP1M8YhRHYYlQbqYPFpyiSa/fGttw/V/mv40hFTwavcOQde03EvtpQcv62Fq89VGff eEUw==
X-Gm-Message-State: APjAAAXtIm77PxEiwbdXMAgQVqCWeoUfXNmd1PeE71jC3ZoGPwnh6HLe NorJjOYC/e9gdMmbZE0hleSjkh8oRBQgQ0LZ
X-Google-Smtp-Source: APXvYqxd9iPCK3qSjrXyaIP6UKgcWeHGn3vVn/b68w0XSCOnwA4MYbpdUSchrcrYicBxFAWgZOOI+A==
X-Received: by 2002:a05:6214:94b:: with SMTP id dn11mr2891905qvb.12.1581005288492; Thu, 06 Feb 2020 08:08:08 -0800 (PST)
Received: from [5.5.33.193] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id h3sm1609375qkk.104.2020.02.06.08.08.07 for <mls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 08:08:07 -0800 (PST)
From: Sean Turner <sean@sn3rd.com>
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\))
Message-Id: <BF65A8FF-7AE0-454B-A1C3-08558EDE97F9@sn3rd.com>
Date: Thu, 6 Feb 2020 17:08:06 +0100
To: Messaging Layer Security WG <mls@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/vDB0RfSd2rIiG2xgKm1lfohgU6Q>
Subject: [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: Thu, 06 Feb 2020 16:08:15 -0000

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