Re: [MLS] Turning mandatory extensions into fields

Raphael Robert <> Sat, 22 May 2021 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06F5A3A1F32 for <>; Sat, 22 May 2021 03:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6HlF2XdCd89z for <>; Sat, 22 May 2021 03:20:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3836B3A1F2E for <>; Sat, 22 May 2021 03:20:14 -0700 (PDT)
Received: by with SMTP id f18so3935661ejq.10 for <>; Sat, 22 May 2021 03:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=rr; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xLhjcoAw1sEJK0xTvgJvuHYsv7q6IgqdCWN1XzS9AJo=; b=t0ZL9I/c1RwWPTEhULtp/AkCn3egYnCk+vNzRWOa/jGHcz8DPjl37LGQNTBFk7ryoz 4xqZJU7OKMseuB3+qE+xGN5oBSCi8dE5i9Qs+9hTVm801c6jBuvGyGSj1KzWXTeLlajZ wo1qZ3krAsHgtIAkzqvYORH/vWXUjFbtoITKE=
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=xLhjcoAw1sEJK0xTvgJvuHYsv7q6IgqdCWN1XzS9AJo=; b=WMFNjsNVEjJmrgrO79KTrA5DisCSyi83HWtcJzeuFeWFf0mGVwTIOrARn9VjjS64ii 2FTRLnfnraWZoEAb+gsqzn4GRMxKK34QMLTmgSF3PxJ0JFnZPzT7VBfEer9o7cSv5Ilk igSgCqvxHoMRneOnZMBL6Q0tmchCXe5AfmytHG7petZ8SGo23Ez1kjBIT++f6/PoG18X 3bBglYj6taGtUhgwa/OAhZ78onj6fWO21lO7XwxCr03sZ2fLPQE6B9MAFFkQSUkDl23l EZ0pgUMmmbjeJfQq1l/tIJIp5nbybKC3yCLsus9fiLsIIP0edde9s+yzWYOvDlLBsJ6A 1MzQ==
X-Gm-Message-State: AOAM531LiMDjmQHLDDCkyrDSaQfh/VJGUh+NszKW0sS4MVGow58mSsgt ZJElgN1++pCIvEh/31ZCKysaCQ==
X-Google-Smtp-Source: ABdhPJyOA1mi2vePKLtmQUNybYaqkM2BxXY6Mgw7VxRZ9t/+GDK1t/gTfjZq2KO+LJYvzUh9c48brA==
X-Received: by 2002:a17:906:a294:: with SMTP id i20mr14617902ejz.86.1621678812055; Sat, 22 May 2021 03:20:12 -0700 (PDT)
Received: from ([]) by with ESMTPSA id z7sm1059944ejm.122.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 May 2021 03:20:11 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Raphael Robert <>
In-Reply-To: <>
Date: Sat, 22 May 2021 12:20:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?utf-8?Q?Th=C3=A9ophile_Wallez?= <>
X-Mailer: Apple Mail (2.3654.
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: Sat, 22 May 2021 10:20:19 -0000

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.



> 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