Re: [MLS] Overflow discussion on #406

Richard Barnes <> Mon, 26 October 2020 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A5A83A0F4D for <>; Mon, 26 Oct 2020 14:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 N1pZas9_dQU5 for <>; Mon, 26 Oct 2020 14:55:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23DF93A1039 for <>; Mon, 26 Oct 2020 14:55:09 -0700 (PDT)
Received: by with SMTP id k9so9933261qki.6 for <>; Mon, 26 Oct 2020 14:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+6CRmlrQG+/macBrfotXNaQdL7Wrv95Xn2V1BceK0D0=; b=xRbivG9uJGm4fUbF8h/8YJbA0lFEIYhX0zZret7FYB2OPDlgXAlJqqRiM/XvkBZcow kTOUUgKfUpbbnSNhqrFu6rI28b3slJSQKneOxDWotPORr8/K/94OjKN9MPcOHNXELfQe /2l25F0jmdlj5rRHk1LeUSp23jMMY0usQzyrzvTBbPLRuSsfIC7jECFxzzl4hreI1xsM dPpgu6biEPUmVuL/Dxlx/WW2dVEBDrM9WKdpWrnZP3rN71+fG0w4g38DbkltX0vSipBo nwUYn5iIUl57tHz1sIZ+GGRRLHL+PbgtpZCl09IsJAzHdQ/to/VJlvOHWaolPK5doWlP 47Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+6CRmlrQG+/macBrfotXNaQdL7Wrv95Xn2V1BceK0D0=; b=N0aOh078FmpiBpAotEI66Zafo5bAz/AI6xdqZ0SXiBSjDZ89girkgpGcuTAi5eeiW2 uqqqTDj/QnT5CqNvra+mZe0BNq+RSQT3gd3bh/sU3z99DGtkZO5W9hcBBRc6bzenKwVK wveYZfLM0twWqOTvuRujH765E1tZHoCEwmh+QGD6IC/DbbpMzOp8SEM4A7624o+JDhMf 7+G/M/et01kuhoRiR+Cg5GpkONujz47mzLhZK9o/JN4e38ynI2fSacXTSiJtLsglCtzu P0VeGqFMwaPzVYHumkqPrYL6m3kGcIz3wLldVRlzjQlkjHJ2qDDaS27cIj4UijEj0OWr HLLw==
X-Gm-Message-State: AOAM5306LDoyKDt+Bh53K2y5NYL6zlB3CwMxvqFNzqIXI0lLPGbmf9i4 eDryihASA3jGB7WlxfaaQDoCMqO9YPdEYRQZ6NjkGQ==
X-Google-Smtp-Source: ABdhPJxTZIxuj1rZ2JPhKFsQwj0FM9Nm12+FyRVAl5knozN96YojA3IAkG4uPNOq6O6czYTfjMJnsaMsotrObODC9Z4=
X-Received: by 2002:a37:86c4:: with SMTP id i187mr19491862qkd.371.1603749308026; Mon, 26 Oct 2020 14:55:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Mon, 26 Oct 2020 17:54:55 -0400
Message-ID: <>
To: Raphael Robert <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000d0631a05b299fbe3"
Archived-At: <>
Subject: Re: [MLS] Overflow discussion on #406
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: Mon, 26 Oct 2020 21:55:13 -0000

Hey all,

I didn't hear an objection, but Joël did point out a pretty significant
risk to me of not having a signature over at least the HPKE public key in
the GroupPublicState.  So I have merged #406 and posted #433 as a follow-up
to add a signature over the group ID, epoch, and HPKE public key.

Please send any comments on that by Wednesday US ET.  If there are no
objections by then, I'll merge that, issue draft-10, and ask the chairs to
issue WGLC on draft-10.

While we're in WGLC, we have at least two issues to discuss:
1. Is the signature in #433 sufficient, or should it cover more of the
2. How should we refactor the tree signing / parent hash scheme to address
the issues raised by Joël, Daniel, and Marta?


On Fri, Oct 23, 2020 at 2:28 PM Richard Barnes <> wrote:

> It seems like the only outstanding question here is whether a signature is
> required on GroupPublicState.  That seems like a straightforward addition
> that we could handle during WGLC, between draft-10 and draft-11, before
> feature freeze.  That way we can go ahead and start getting wider review
> while we resolve these last issues.
> Unless I hear an objection here before Monday US ET, I'll go ahead and
> merge #406 and work on getting draft-10 out the door.
> --Richard
> On Wed, Oct 21, 2020 at 11:38 AM Raphael Robert <> wrote:
>> Thanks for writing this up, see my comments inline.
>> On 20 Oct 2020, at 20:53, Richard Barnes <> wrote:
>> Our interim call went about 30min past our scheduled end time today.
>> Since we were without chairs for the last 30min, that time was not official
>> WG time, so we couldn't make decisions about PRs.  Luckily, we only had one
>> PR remaining, and we couldn't come to agreement on it anyway :)
>> Two remaining questions on PR#406, where the first is more important:
>> 1. Should the GroupKeyPackage / GroupPublicState be signed?
>> On the one hand, having a signature would remove any concerns about
>> copy/paste recombination of the various constituent parts.  In particular,
>> it would avoid the public key for one group being reused with another (up
>> to reuse of signature keys across groups).
>> On the other hand, Raphael expressed some concern about deniability,
>> since this would be a public signature by a member of the group over the
>> whole state of the group.
>> Personally, signing seems like the conservative option to me.  But I
>> haven't done much analysis here.
>> Joel brought up a question regarding tree signatures yesterday, that he
>> said he’d describe on this list shortly. I see a lot of overlap between
>> these discussion and would like to wait for that discussion to unfold
>> before jumping to conclusions here.
>> 2. Which transcript hash(es) should be included?
>> (This is more of an engineering question than a security question)  To
>> summarize how the transcript hashes / confirmation tag work:
>> confirmed = H(interim || all_of_commit_besides_confirmation_tag)
>> confirmation_tag = MAC(confirmation_key, confirmed)
>> interim = H(confirmed || confirmation_tag)
>> In a GroupInfo / Welcome based join, the joiner needs the confirmed
>> transcript hash but not the interim.  The confirmation tag is provided in
>> the GroupInfo and verified by the joiner, and can then be used to compute
>> the interim transcript hash.  (This is a side effect of #416, which moved
>> the signature from interim to confirmed)  In other words, the joiner starts
>> at the second line above, since they don't actually see the commit.
>> In an GroupPublicState / Commit based join, the joiner is computing the
>> commit, so they start at the first line.  As a result, the joiner needs the
>> interim transcript hash, not the confirmed transcript hash.
>> I have implemented these changes (removing interim from GroupInfo and
>> confirmed from GroupPublicState) in my draft implementation of #406 [1],
>> and they do work.  I have filed a small spec PR to remove this [2] and
>> suggested the corresponding changes in #406.
>> This looks fine to me, the hashes are now swapped in the PR.
>> Raphael
>> --RLB
>> [1]
>> [2]
>> _______________________________________________
>> MLS mailing list