Re: [MLS] Syntax and mechanics for external commit

Raphael Robert <> Wed, 14 October 2020 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4E3C3A1483 for <>; Wed, 14 Oct 2020 03:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KlCxP5mgZV6c for <>; Wed, 14 Oct 2020 03:43:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319B23A1477 for <>; Wed, 14 Oct 2020 03:43:06 -0700 (PDT)
Received: by with SMTP id t20so2577612edr.11 for <>; Wed, 14 Oct 2020 03:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dV73KVb3fbuUaW93zn1BmuTiF7kgTYruptVXGMYjP8o=; b=qzbuljzvGPs0ZPXBwZfCVnQBEV8dKk9ZWqWsuQ+vcNNXeA9av1U3eh4chnZaRPq+fh wN4+vmNHuqbrjqVvdjgULp8ZVzH/LhKDxst3ZFNASmkm8Zqi2b3sKUO7ViCcdG31ZxC7 04K7vpd1JDtIjf/0cALDJ/uWVk8z5J7niVMu6LpKCWZItNMIz/rO/DpYnvqXyMwZ+ZVe Gsu3s+Dx1DM0WZmpX+9FOBQ1iLtTGKATexWi1xYaCW2EiZ2Ev9HsRW2fU8WbMZXaVy8B lo91po4baSIEu0XvbIWqfYVXCYcl+y9nh1Zz4SGzySUAm0qiEiLqDiYPVzNapc+xkZOk HDdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dV73KVb3fbuUaW93zn1BmuTiF7kgTYruptVXGMYjP8o=; b=FFPGlICJCTaCnA7i/7oVhF3Lg0LGznwFZCXZLRPOS/KagzQcipcfHXDVySftS/RVCy 5OkUdTzExTYYp76rKwXwIKujY8+ymPiNxCsWQiXEK+5xr+Duur9zLlIRdWbLlYmInTR6 JAmkFCM1b3Yvfr8rKYHG21TR0Cgj91zD65zuxqJomROthtB8fYcfbLF69/56+nRozaAl VOZai1yrrNScHwNQHtNrQbv9CqPZ5B2JcVkZm271mtCAViWDEfdKh5ej7y6FJXdrpna5 GTrJq99N9kBrevfMSSUXJHRxE8tReB7LCFhlbHL9aTbOUsDJir5lt3L1muR5cMkBf0VY tDwA==
X-Gm-Message-State: AOAM533VDoa2/g338tiI6+xUvEiUNiTO24aDNB3G5sLTRfe285hcpElN RGuE8IB08SORSlgTLSelumkjhA==
X-Google-Smtp-Source: ABdhPJzozgeDrGmRZjvMHJ9wZjPbAtE+kyGSiFmkAcwN9rOgcMVyga53Tw2osb2Xfam6EzzA7MIy+g==
X-Received: by 2002:aa7:c9c3:: with SMTP id i3mr4503942edt.236.1602672184551; Wed, 14 Oct 2020 03:43:04 -0700 (PDT)
Received: from ([]) by with ESMTPSA id bn2sm1495301ejb.48.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 03:43:03 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Raphael Robert <>
In-Reply-To: <>
Date: Wed, 14 Oct 2020 12:43:02 +0200
Cc: Richard Barnes <>, Brendan McMillion <>, Messaging Layer Security WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Joel Alwen <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [MLS] Syntax and mechanics for external commit
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: Wed, 14 Oct 2020 10:43:08 -0000

That’s a good question. I can definitely think of cases where the explicit Add Proposal is desired, for example when an external party (like a server) issues that Add Proposal. In the scenario where the new member issues the Add Proposal, it does seem a bit redundant, like you say. Because an Add Proposal for the new member might already exist, this mechanism has to be optional, otherwise we would have to force drop proposals.

I see two options:

a) We keep it as is. In the case the new member issues the Add Proposal, it could be an inline proposal (once we have that mechanism) and therefore the only overhead would be increased payload size, since the KeyPackage is repeated, but there is no overhead coming from additional signatures.

 - Clarity and simplicity when parsing Commit messages

 - Increased payload size

b) We infer the Add Proposal from the External Commit if it didn’t exist so far. Internally clients would have create the Add Proposal and add it to the beginning of the list. This complicates the parsing logic a bit, but saves the repetition of the KeyPackage. The complication comes from the fact that this can really only be optional (as mentioned above).

 - Optimal payload

 - More complicated logic

I don’t see any negative impact on security just yet, to me it just looks like a tradeoff between logic simplicity and payload size. I don’t have a strong opinion on this either way, maybe Richard can comment on the potential increase in complexity?


> On 14 Oct 2020, at 11:35, Joel Alwen <> wrote:
> Quick question: is an *explicit* add proposal for the external commitor needed?
> Or can we leave that implicit since an external commitor is always being added
> and their new leaf key package is already specified as part of the path field in
> the commit.
> - Joël
> On 11/10/2020 21:19, Raphael Robert wrote:
>> This is what we currently already have in the PR:
>> - External Commits MUST reference the Add Proposal that adds the issuing new
>> member to the group