[MLS] draft structure feedback and suggestions

Franziskus Kiefer <franziskuskiefer@gmail.com> Thu, 17 September 2020 11:19 UTC

Return-Path: <franziskuskiefer@gmail.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 807513A03F4 for <mls@ietfa.amsl.com>; Thu, 17 Sep 2020 04:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id plXCJYARtUz5 for <mls@ietfa.amsl.com>; Thu, 17 Sep 2020 04:19:06 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 96BA93A03EE for <mls@ietf.org>; Thu, 17 Sep 2020 04:19:05 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id ay8so2073116edb.8 for <mls@ietf.org>; Thu, 17 Sep 2020 04:19:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LEu5ypn5Oo8SLeTrl+eMl7zCP4o+stT49XB/yCPJhQc=; b=fTeC06FauWpiVe9Wgk2nasVoS/aDjdj42/1AD1rEg45fnmtWhNosB1Gv/Dwh6dp2a4 rHIcnEdrWe945HZvW3rGcGSFjaniu4GnRJ4eGWdOSBnfMjcBWndwZcK5mauSBp5vtXht mF9/7+UNQVP4pvqM0K7aBgP4QM7bR2CzMXjb9tKv8kKoTLdbHsE44FWoTQItLYPn0eyB lAfgL02OoIcsT9DLDhPZBwVMv1Yz9Q2D5q8yDrctLYYEZ6fwf/DB1SCth6r/74mQZuU5 nVmg/98h40Apdejib1taG2iGl2dPeaJCUTckNTf/NU/KP4Yp83EUdoIRep34l8CpR2iu uHmw==
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=LEu5ypn5Oo8SLeTrl+eMl7zCP4o+stT49XB/yCPJhQc=; b=aY/HXxVGNyvE4WppuoKNKFWGVLN0lj8YNi/hNM9QDdj3GFWgTyo20FPFnpdXRryNHe Ke9cwtK7KSQkUlkzkENVxan1fA4ak/jcT8TZR2BBViHfYJKb9eG8dtUmkMoAq86lJmFS 1FBv5V1EfUcpT8MCIsBFLS+xyEUEkWAm8yufGL6KOeTLGAmvHaeNkf0+yOVZV37S91u8 leg4M3wAQ7wK0uISKQU2Oza73wpcRc1gB9MYRGk5HetoaOm30HyMnOscbTxN6wv8oRdz RPMJ4CFZleLT+0b+3wi3nND37FE2SLeaZLNlXp7Ha5VrIztJ91ajlaEZyqi+Ynj7+ulj vVxQ==
X-Gm-Message-State: AOAM531OccxHF+WM86dWYmH0M6OWJrPSY66pDfRyNmZIxNWIDeI43EJn 63+hgk/7ODWn8A4+MHpn9uvlFJ3sEd6Gm4gTPlTAavCODq4=
X-Google-Smtp-Source: ABdhPJxWi0LcI9VtY/MDFpf5wFUamXBs0HoGNrYrnkcaLF54JMQZxxIqXHAONHjSy/ldC/apr+jP5Iv/M6nBXVNZv3E=
X-Received: by 2002:aa7:db02:: with SMTP id t2mr32065494eds.95.1600341543475; Thu, 17 Sep 2020 04:19:03 -0700 (PDT)
MIME-Version: 1.0
From: Franziskus Kiefer <franziskuskiefer@gmail.com>
Date: Thu, 17 Sep 2020 13:18:52 +0200
Message-ID: <CAJowLmNnFz9odPJ=zdXk7yZgU2ZcJWFq_je+u=ZF-mdHZuw2GA@mail.gmail.com>
To: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037dfa105af808d50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ZOy80Yp5bRhoM8fsQMGVwmFFEzY>
Subject: [MLS] draft structure feedback and suggestions
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, 17 Sep 2020 11:19:08 -0000

Hi all,

While trying to implement the MLS protocol from scratch I ran into a couple
issues and I think there’s a general problem regarding the structure of the
draft. Note that these are all editorial issues.

Right now I see no straightforward way to implement the spec as there’s no
clear structure. To implement even the basic tree structure it’s necessary
to jump through the entire document. There’s also a lot of prose and
examples and very little implementable parts.

Let me give some examples:

Section 5 (Ratchet Trees) reads like a non-normative section (or paper).
The really interesting bit related to trees is in Appendix A. I suggest
moving the formal description of the tree from Appendix A to this section.
It’s impossible to implement this from the hand full examples here.

There’s no description in here on how the tree actually works. For example,
adding a node to the tree is defined in 10.1.1 (Add).

The ratchet tree nodes as described in Section 5 don't hold a KeyPackage.
But Section 7 says “As the KeyPackage is a structure which is stored in the
Ratchet Tree and updated depending on the evolution of this tree”.

The tree nodes have a parent hash field, which is of course part of the
ratchet tree but shouldn’t be necessary for the description of the tree

Also, the description of the tree hash (Section 7.5) follows the definition
of the parent_hash extension in Section 7.4 such that it is not entirely
clear which parent_hash is used there (extension or node value).

Section 5 also talks about commit messages without linking to them or
introducing them. Having to talk about commit messages in this section is
also a little confusing.

The term “handshake message” is first used in Section 7.8 (Key Schedule)
but never introduced. This should probably happen in 10 (Group Evolution),
which doesn’t talk about handshake messages at all until 10.3 (Ratchet Tree

There are probably plenty more issues like this. But I don’t think
addressing any of these issues individually makes sense. I therefore
suggest having an overhaul of the document structure.

The way I see MLS there are a set of high-level structures and components
that should be clearly described and built upon each other. There’s a data
structure (tree) that is used to represent a group. Then there is the MLS
group that implements a specific semantic on the tree. Operations to modify
the group are specified in the handshake protocol. And application messages
define messages encrypted with keys derived in the handshake protocol with
the *key schedule*.

The tree is a basic left-balanced binary tree and defines functions to
create a tree, and add and remove nodes.

A group is the main part of MLS, a tree with nodes of a certain type. So
this part should describe what nodes look like and how the tree is used to
compute tree invariants and keys.

The handshake protocol defines all messages needed to perform operations on
the MLS group.

This is certainly not exhaustive and would need further refinement. But
it’s the high-level structure I’d expect from the document. I’m sure other
structures would work as well. But what we currently have isn’t what is
needed to implement MLS imho.