Re: [MLS] Turning mandatory extensions into fields

Théophile Wallez <> Mon, 21 June 2021 11:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A3CB3A003E for <>; Mon, 21 Jun 2021 04:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.334
X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BAqZAaxk3n9B for <>; Mon, 21 Jun 2021 04:04:24 -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 82BBE3A003F for <>; Mon, 21 Jun 2021 04:04:23 -0700 (PDT)
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ALi2gP6m+5oNAQxfI/Y8VyISGVgPpDfIt3DAb?= =?us-ascii?q?v31ZSRFFG/FwWfrCoB1p726StN93YgBFpTngAtjkfZqyz/9ICOUqUotKGTOW2l?= =?us-ascii?q?dAT7sSjrcKoQePJ8SWzIc06U4jScRD4bbLZmSS4/yR3OD1KbYd/OU=3D?=
X-IronPort-AV: E=Sophos;i="5.83,289,1616454000"; d="scan'208";a="385668395"
Received: from unknown (HELO []) ([]) by with ESMTP/TLS/AES256-GCM-SHA384; 21 Jun 2021 13:04:20 +0200
To: Raphael Robert <>
References: <> <>
From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= <>
Message-ID: <>
Date: Mon, 21 Jun 2021 13:04:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [MLS] Turning mandatory extensions into fields
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, 21 Jun 2021 11:04:29 -0000

Hi and sorry for the late answer,

Is there any good reason to merge the two structures (init keys and leaf 
content) other than the overlap they have?
The overlap seems quite small to me (e.g. compared to the "Message 
Framing" section), it looks like it is only an HPKEPublicKey, a 
Credential and a signature.
The non-overlap seems quite big to me, for example:
- ProtocolVersion, CipherSuite only belong to init keys
- parent hash, lifetime only belong to leaf content

I think it would be a good idea to split the two structures again, I 
believe this would simplify the implementations by making parent hash 
easily accessible, and by removing unused values of the leaf content 
(what should we do with ProtocolVersion and CipherSuite, should we check 
that it is consistent with the group state? should we ignore them?)

Thank you for your comments,


On 22/05/2021 12:20, Raphael Robert wrote:
> Hi Théophile,
> The current scheme was introduced a while ago when we merged the the KeyPackages that clients publish ahead of time (previously called init keys) with the KeyPackages that clients use in their leaf nodes.
> The reason was that there was quite some overlap between the two structs and the logical consequence was that data that differs for the two use cases was expressed as extensions.
> I’d be open to discussing disambiguating this again and I think I’m not the only one. This would also pave the way for Joël’s proposal to have an additional public key in the init keys in order to improve FS for members who don’t update quickly.
> Thanks
> Raphael
>> On 21. May 2021, at 23:03, Théophile Wallez <> wrote:
>> Hello All,
>> The MLS spec includes some extensions that are mandatory.
>> Considering that this is v1 of the spec, why not just make these into fields and take them out of extensions?
>> In particular, in the current draft, the parent hash is only an extension, but it is mandatory when the leaf is generating an UpdatePath.
>> Let us make it a field in KeyPackage?
>> Having it as an extension hides its importance for security, and makes the draft confusing to read.
>> Also, it is a bit weird that parent_hash is a field in ParentNode, and it is an extension in KeyPackage.
>> We propose the following changes:
>>> New structure:
>>> struct {
>>> opaque parent_hash_value<0..255>;
>>> } ParentHash;
>>> New field in KeyPackage:
>>> optional<ParentHash> parent_hash;
>>> This optional field must be present in the `leaf_key_package` of an UpdatePath (same constraints as the current extension).
>> Or:
>>> New field in KeyPackage:
>>> opaque parent_hash<0..255>;
>>> `parent_hash` must be non-empty in the `leaf_key_package` of an UpdatePath (same constraints as the current extension).
>> Best regards,
>> Théophile, Benjamin, and Karthik_______________________________________________
>> MLS mailing list