Re: [MLS] draft structure feedback and suggestions

Brendan McMillion <brendan@cloudflare.com> Mon, 05 October 2020 18:12 UTC

Return-Path: <brendan@cloudflare.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 3DBFF3A0B6B for <mls@ietfa.amsl.com>; Mon, 5 Oct 2020 11:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 XPKDljlROIMt for <mls@ietfa.amsl.com>; Mon, 5 Oct 2020 11:12:07 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 D019E3A0F67 for <mls@ietf.org>; Mon, 5 Oct 2020 11:12:07 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id q63so13023690qkf.3 for <mls@ietf.org>; Mon, 05 Oct 2020 11:12:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KycArNUlfqfBn3OgpyUq/2XRj4rxdAvaqFLg8GgT1pM=; b=gmGUf2PegG4U/TV6JcKGvrBuaw2PBZKLLNWjwUzN99Dr0in96yk61LiyWUz5aIRFyv VzipkcAxnrV6k5Ve/8u7eXXjC5zeGsVGaRr0DV4W+/OZtGyfAiBgJWaHuZ0lFDZLDsTW 3ZCbYNus14gc3rkaZFAak8xdEfQIyRZYJ0olI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KycArNUlfqfBn3OgpyUq/2XRj4rxdAvaqFLg8GgT1pM=; b=TbPpWpIcWWlVtKhhVdIwlXBEf2BJyYjGXvoCh/vo2CXoHmeNfVr8uWjJkcTBdGnvga J/R0Sz1dcZwiN23H6fFw4XuXzaRx0SxFnGBnLNEF3XfvFN4HwV7epRzf9mpGQhDMQHm2 Ctx7WkyPhRJ0HFfljoNz55LKfCb7RE7NSqLfNM6G5+ZO4/jnOb/GUjI+YhgCHpMVQj6j 2R/yKFBUJs7EMCCSEFdo6Ck036dVXqgtRhz8twZdOO2OBAzVe3ZwigyQAodR+Yoih+EM RkP6CexVCJoVc0NMworYNSTmOsSNMNAqbAYicYht02hBv1TCRvUkDAKq5s+fZqn/P/PE BJ1w==
X-Gm-Message-State: AOAM530WVjuhgVh9z0Q07UtcRjro/E3JvNlvfjO5Ly4lLG/ccdb8CiSC UwP9NSat/FlYiogktEXTW3EAcvwm6x6FtWi3b1tlpA==
X-Google-Smtp-Source: ABdhPJw87lXPiNPtVHwTq4p0a3JGA0i3VtREjhAzAnyTofT0h54fEOpsfpD/7GXzHygLXOqeCwLKB/ehVwkLkITKkxU=
X-Received: by 2002:a05:620a:795:: with SMTP id 21mr1225561qka.131.1601921526643; Mon, 05 Oct 2020 11:12:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowLmNnFz9odPJ=zdXk7yZgU2ZcJWFq_je+u=ZF-mdHZuw2GA@mail.gmail.com> <781922648.117964.1601901336014@office.mailbox.org>
In-Reply-To: <781922648.117964.1601901336014@office.mailbox.org>
From: Brendan McMillion <brendan@cloudflare.com>
Date: Mon, 5 Oct 2020 11:11:55 -0700
Message-ID: <CABP-pSQfsMaW7wN6v7gRfYTJ-J_SVn_LiNgdjMYww+wnKJG2TA@mail.gmail.com>
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: Franziskus Kiefer <franziskuskiefer@gmail.com>, "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008de66305b0f06b5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/f7s91tobZ9MJMYQp-D2Yc2QXpaw>
Subject: Re: [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: Mon, 05 Oct 2020 18:12:10 -0000

I don't think this belongs on the agenda. What Franziskus says is right,
the MLS protocol document has become nonsensical over time. But right now
we're focusing on substantive changes to the protocol and can rearrange
when we've finished.

On Mon, Oct 5, 2020 at 5:35 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de>
wrote:

> Hi everyone,
>
> I think Franziskus make some good points here. We've been making
> individual changes all over the document, but the structure hasn't really
> changed for quite a while. Maybe this would be a good time to take a look
> at the document as a whole?
>
> In addition to his mail below, Franziskus has also filed an issue
> https://github.com/mlswg/mls-protocol/issues/409.
>
> @Sean: Any chance we can put it on the agenda for the meeting tomorrow?
>
> Cheers,
> Konrad
>
> > Franziskus Kiefer <franziskuskiefer@gmail.com> hat am 17.09.2020 13:18
> geschrieben:
> >
> >
> > 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
> structure.
> > 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
> Extension).
> >
> >
> > 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 MLSgroupthat implements a specific semantic on the tree.
> Operations to modify the group are specified in thehandshake protocol.
> Andapplication messagesdefine 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 whatnodeslook 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.
> >
> >
> > Cheers,
> > Franziskus
> >
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>