[MLS] Move / Add-in-place / Compounding
Richard Barnes <rlb@ipv.sx> Mon, 22 October 2018 18:34 UTC
Return-Path: <rlb@ipv.sx>
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 C2866128766 for <mls@ietfa.amsl.com>; Mon, 22 Oct 2018 11:34:16 -0700 (PDT)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 0J4Q7i68JZjV for <mls@ietfa.amsl.com>; Mon, 22 Oct 2018 11:34:14 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 A75B61277C8 for <mls@ietf.org>; Mon, 22 Oct 2018 11:34:14 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id c23so39283678otl.9 for <mls@ietf.org>; Mon, 22 Oct 2018 11:34:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nKHtVHdJWmTmlUZBAthaGLgU3s1FOfHLEVEybfMp57g=; b=scMN6Tg6P26ZcvtAAe4FyDO2O36XC0zNWaRk5sQtCzEO3pMVd57Ofw4NpwoR4JXrd3 /qrr05YV4Z4KmzkxRIgoh1756DUCxWrujm7I+uJ576XJhjjdQ3xFaATryw+Pl6sXEsz5 5ijr6NAkCKqABGbFP/AmUgq774ikxecS+eJnZvN1rlDbcbA24EN+/RU6650crKaRrDs6 uPNAorYVIuG/+5HEthU6XuMiNLUk/o6xOzYkBCJ68BhjuXWe6QfTvmY7nm+y7eF/EizP azfP2hBnHdBjvDiSrCmD+zCh/GINCiWextyMB8H1Fn+r0M+Kt4/Vjg42z63HyrUmpmUC QYBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nKHtVHdJWmTmlUZBAthaGLgU3s1FOfHLEVEybfMp57g=; b=XK+9hG1pQpeQ9wNOdd3uGQ9kQCPdahnb3dE2lngDFcwPTQWHHZOYYBSs7oVpgrvJwa DBAioqdCEROuJWSGLoyxdbwItgREAjEiv6YhNThb7V8ZbFJwnkVWHmiVnhABim0895eN 0PJp1QsbmAUXIF78GoaOQdHG7eYV+yUn7GbNsZklvRSJrGUPE+YJpRgaYL+akwVLE297 VH0JXyDVGALbCh+4DHXVxFEk0bu+WfgNJzoO/Ot2ynbmH0OLYnNAp+x5UrlIycETBP0v 4n0hPR5wy9ie0z4n77723oJgsutA/l6s0jlhBsWSgQ4/JYTOIk/W/VGX0U9D4PbKvspK yEhw==
X-Gm-Message-State: ABuFfojCshhJCtxgsgRM+2TrNPQF+StabIRxmdP/kAwH0wYIkd2psk4l H8fNns6rebItXneZX7HKCl8e1gz2vS9D4PuY7ARzgZrm5aM=
X-Google-Smtp-Source: ACcGV60odgE+Up9ivY60UHocmcnlP8cdcRspO6S4XEWX4uJdPJ9f8/QAQtSyXSdc5ZOpvUXWpcblRnNRrQnoRkSZvy8=
X-Received: by 2002:a9d:339a:: with SMTP id u26mr31648169otc.81.1540233253651; Mon, 22 Oct 2018 11:34:13 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 22 Oct 2018 14:34:00 -0400
Message-ID: <CAL02cgTYLTkkB-WhjeBtorVcdiurPibi9eqmQmG3qib1gLhEkA@mail.gmail.com>
To: mls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f49cd10578d57f77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/d9joL5rMHiSvLDzW6Szkk4z2dVE>
Subject: [MLS] Move / Add-in-place / Compounding
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: Mon, 22 Oct 2018 18:34:17 -0000
Hey MLS folks,
tl;dr:
- Would there be interest in a Move operation?
- How about an operation to Add a new member in an open slot instead of the
right edge?
In looking at the "partial tree" stuff (#67), it occurred to me that once
you have partial trees with blank leaves, you can in principle do two new
operations: An existing member can move from one leaf in the tree to
another; and an existing member can add a new member at a leaf that is
currently blank. These operations would work roughly as follows:
- Move:
- Blank out old dirpath
- Move credential from old slot to new slow
- Send update along new dirpath
- Add-in-place:
- Blank out dirpath for slot
- Install new member's leaf key in slot
- Install new member's credential in slot
For Move, you would also want to have people step down the size of the
tree. For example, if you go from having 10 leaves (X _ X X _ _ _ _ _ X)
to four leaves (X X X X) as the result of a move, then the resulting tree
should only have height 2, not 4 (as is required for 10 leaves).
Fortunately, this is trivial with the tree math defined in the document;
you just truncate the node vector, and the calculated root gets
correspondingly smaller.
I've prototyped this out in my JS stack [1][2]. Once you've built a tree,
and removed a couple of members, you can click one of the "Move" buttons to
move that node to the lowest open slot. As you can see, it's not a ton of
code.
In any case, this seems to me to be potentially useful, since it addresses
the issue that was raised in the BoF that the size of the resources for a
group increases monotically. Move allows you to reclaim resources that are
unused (assuming some orchestration outside of MLS), and Add-in-place
allows us to be conservative with resources that are already allocated (cf.
realloc).
If folks think these sound like useful tools, I'll write up a PR and we can
discuss in BKK.
--Richard
[1] https://ipv.sx/treekem/
[2]
https://github.com/bifurcation/treekem/commit/7f470422ba61ce668c3ab1d6b2d18edd9d6e06fd
- [MLS] Move / Add-in-place / Compounding Richard Barnes
- Re: [MLS] Move / Add-in-place / Compounding Raphael Robert
- Re: [MLS] Move / Add-in-place / Compounding Russ Housley
- Re: [MLS] Move / Add-in-place / Compounding Richard Barnes