Re: [MLS] Two poorly defined aspects of the spec

Cornelissen Eric <> Tue, 11 August 2020 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BD7A3A1089 for <>; Tue, 11 Aug 2020 06:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 p9Vweu-5yDjK for <>; Tue, 11 Aug 2020 06:47:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 226783A1087 for <>; Tue, 11 Aug 2020 06:47:35 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 2CFFB2715E8_F32A173B; Tue, 11 Aug 2020 13:47:31 +0000 (GMT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer " RootCA" (not verified)) by (Sophos Email Appliance) with ESMTPS id B5522271566_F32A172F; Tue, 11 Aug 2020 13:47:30 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 11 Aug 2020 16:47:30 +0300
Received: from ([fe80::4047:1ae:cfdf:c1a8]) by ([fe80::4047:1ae:cfdf:c1a8%18]) with mapi id 15.01.1979.003; Tue, 11 Aug 2020 16:47:30 +0300
From: Cornelissen Eric <>
To: Richard Barnes <>
CC: "" <>
Thread-Topic: [MLS] Two poorly defined aspects of the spec
Thread-Index: AQHWa9hzVoJJMfPk+kK5poDHTeMmXqkxOXWAgAG6Coo=
Date: Tue, 11 Aug 2020 13:47:30 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US, fi-FI
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_cc19f450a410431cb3be124c96417c60aaltofi_"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=its18; bh=/9+3SDPkKLC90v1OJ26CnJEqVrqmmLFv3jyzZxbunGI=; b=S0v+6GY0CoGuuWXHKGSSoKAsh1dGjy5dZLRe+3L14UgvG3JJntk7FRnrGAb3rqvtk+ZJnfQhTYq3OwDKnIp0TRLJGS+CzMHYkv+HWgkmwCelN8tZBC5vygQlYqt4iELiuu1L+kYv19rh4G66x1v+CBw+lcVOR+HutBORDbBoyBf3hEwwZqMi8pVHpjKwszZep2/xAZkEZh3ipKrn1CMjN1FVv0WVYlMl/SEsPQ+vfA0HO2wiXKIPfLjyVA0xdafMJ56CRzQkfETS4J4BazVvdvAp9QBiqv+MFfG2rugy3PFuN3Cwwx3Zrq3+bZR6g1VyJy37/tgm1Ps0i2lHsFalxA==
Archived-At: <>
Subject: Re: [MLS] Two poorly defined aspects of the spec
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: Tue, 11 Aug 2020 13:47:40 -0000

Hi Richard,

1. In that case I would agree that clarifying the indices is the way to go. I personally think just adding interim_[0] = 0 to the current definition would suffice and be clearer than your suggestion here, but that's just personal taste.

2. The "secrets" array makes a ton of sense.

If the welcome is ignored when the verification fails, then the fact that this is not strictly true seems to make it impossible to continue with a group after all but one person left (unfortunately, the paragraph doesn't specify what should happen if the verification fails). This is not a cryptographic problem, but I'd imagine this being confusing for end users if the application layer doesn't deal with it properly.

However, as I just pointed out in #385<>, it seems that we (I) made it impossible for joiners to verify group creation at all.



From: Richard Barnes <>
Sent: Monday, August 10, 2020 5:22:47 PM
To: Cornelissen Eric
Subject: Re: [MLS] Two poorly defined aspects of the spec

Hi Eric,

Thanks for the analysis here.  More good finds.

1. I think the right answer is a little of both.  If you initialize a one-member group, before any Commit messages have been sent, then it should be the zero-length octet string.  But then as soon as the group is used for something, it is updated.  Maybe the way to clarify this is to fix the indices.  If we have the interim hash belong to the new epoch, then we could have something like the following:

interim_[0] = 0
confirmed_[n] = Hash(interim_[n] || MLSPlaintextCommitContent_[n]);
interim_[n+1] = Hash(confirmed_[n] || MLSPlaintextCommitAuthData_[n]);

1.a. BTW, this raises another issue: I had thought we had removed direct dependencies on hash functions when we move from invoking HKDF to invoking the KDF from HPKE.  But this points out that we still have raw hash invocations.  I filed an issue for this:

FWIW, I think the latter course there is the right answer, i.e., to keep the raw hash invocations and clarify that the ciphersuite specifies a hash function.

2. It seems like the right reference here is probably to the "secrets" array in the Welcome message.  There's one entry there for each member being added, so if len(secrets) = len(group_info.tree.leaves) - 1, then there was only one member in the group to start with.  It's not strictly true to say that this is a new creation, since one commit could remove all but one of the members of the group and re-add a new set of members.  But this distinction doesn't really seem salient.

On Thu, Aug 6, 2020 at 6:02 AM Cornelissen Eric <<>> wrote:

Hi All,

I have two questions about things that are unclear to me in the current state of the spec as they are undefined/poorly defined.

1. What is the intended value of interim_transcript_hash_[0]?

>From the current draft I cannot definitively (i.e. with 100% certainty) say whether the value of the first interim_transcript_hash should be:

a. "the zero-length octet string" following the last line of Group state section<><>up-state>, or
b. a value derived based on the MLSPlaintextCommitAutData for the first commit concatenated with 0:
        = Hash(confirmed_transcript_hash_[0] || MLSPlaintextCommitAuthData_[0])
        = Hash(0 || MLSPlaintextCommitAuthData_[0])

The draft strongly suggests to me that it is the former, but the latter seems to more accurately reflect the statement "The confirmed_transcript_hash field contains a running hash over the messages that led to this state."

In the case that a is correct I would suggest updating the definition of interim_transcript_hash_[n] to:

    interim_transcript_hash_[0] = 0
    interim_transcript_hash_[n] =
        Hash(confirmed_transcript_hash_[n] ||

In the case that b is correct I would suggest adding a "warning" that says something along the lines of "as a placeholder value" to the place(s) where the draft says that the interim_transcript_hash of a group is initialized to 0.

2. What is the `members` array mentioned in the Group creation section<>?

In that section it is stated that "A new member receiving a Welcome message can recognize group creation if the number of entries in the `members` array is equal to the number of leaves in the tree minus one." First of all, it is not clear what this `members` array is. It seems this refers to a field of the now-removed Init struct. Interestingly this struct was removed in the very same PR that added the above sentence (see #239<>). But I wasn't able to really figure out what the draft-09 equivalent of it should be.

In addition, I'm pretty sure this technique would no longer work to detect group creation (but that would depend on how the sentence should be updated).

MLS mailing list<>