Re: [MLS] Overflow discussion on #406

Richard Barnes <> Fri, 23 October 2020 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC5583A0A07 for <>; Fri, 23 Oct 2020 11:28:24 -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 QCPCnuVniIXg for <>; Fri, 23 Oct 2020 11:28:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E04763A09EF for <>; Fri, 23 Oct 2020 11:28:22 -0700 (PDT)
Received: by with SMTP id 188so2051173qkk.12 for <>; Fri, 23 Oct 2020 11:28:22 -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=vaNIc/ZRvXKjSof8s49P2B4UiKn0aH9uGqOb2ar7lBs=; b=xuKn/xVKrXXm9jkiiyWV5MSJzx2bL0fqx+5tph95uyDje+l5XnJTNmF6xq3bcrFxV+ TenMC8DaGm3j6QwZzX4/BpVN0vRqSr8xC8BnCK4ciO5EGTE06HDrVULVzblmnwDYMoGr 17uEEvykiSl7tdAzErGoRVfA6oIxic5tyTsGh0l2+Tf5HLuXQyEqoj+9K83g2g/n85zR zACSFppBqbWOemdxEg+w/woGODZnW1QLGKSE1fNDZt/5FYjDyBJ61PhHCP0sqe/3r9Ew Vp3LTsYINBpqMKZQ0wfoxfo0dEJIzWYUFkkVSNIpq42ocqseTCMtTTEURFepglfI3UtV EjZw==
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=vaNIc/ZRvXKjSof8s49P2B4UiKn0aH9uGqOb2ar7lBs=; b=jbOa1UdzBxIxABArdeBXhF4/8vkYDtbvozJ2abL+ug/PfHWntyqZuHG6/PyAaD4YoB u3cl1VcM4XlSO7YVcfxUASykf/19kLsVeyq8wloIaGQH+plLSvw3ejUJn2sDkriXlIW8 1o/RMJGZYmSFwqr4vg39tMKYsBgcFBPJlvRBrxtHYlOxeVPkgnaZa79RrqzXyNDk5Pb5 CjSgsvWdsS/zcnrkbSAyWacDAo9/K7/Fyhp3WubT/+OnDT3E0wtpvpIfUKsrVEL2Owyl sD5OPBSlxcNb8kiWc0AUc5wz/50gXSvMZo3SkLIS8AyMtWzTmGmJFAbTqv9Hq5/BXtIA Td8A==
X-Gm-Message-State: AOAM530wtVN6PpK8dCP+gVp6Hhvrzu+MkKQh0xqwKHsDWMtJiVBP6PET UGD6lUa9BaBpyIGc1AFClf8BHOafdGYi1YyvXTUTgMonf6o=
X-Google-Smtp-Source: ABdhPJynRGBcuPgm1I/kfn+TdGCwpWhxz+YzlgQZo4GpezKla3yM5tR5N13/VZsrGtT5chgiqKb2IBuy7DsdfKVLffw=
X-Received: by 2002:a37:86c4:: with SMTP id i187mr3608253qkd.371.1603477701371; Fri, 23 Oct 2020 11:28:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Fri, 23 Oct 2020 14:28:01 -0400
Message-ID: <>
To: Raphael Robert <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000cbc25b05b25abec8"
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: Fri, 23 Oct 2020 18:28:25 -0000

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.


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