[MLS] Turning mandatory extensions into fields

Théophile Wallez <theophile.wallez@inria.fr> Fri, 21 May 2021 21:04 UTC

Return-Path: <theophile.wallez@inria.fr>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815763A207E for <mls@ietfa.amsl.com>; Fri, 21 May 2021 14:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REEMuLV9FKQV for <mls@ietfa.amsl.com>; Fri, 21 May 2021 14:03:59 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD50D3A2084 for <mls@ietf.org>; Fri, 21 May 2021 14:03:58 -0700 (PDT)
IronPort-Data: =?us-ascii?q?A9a23=3ApmrETqJeVSCdRLeQFE+RzpclxSXFcZb7ZxGrkP8?= =?us-ascii?q?bfHC81D1w0zNVmGNLW22DPvjYMWD3Kd9wbYi18xxU7J7Vm4NqS1BcGVNFHysb8?= =?us-ascii?q?5KdbTi6Bh6tZH3KdpWroHqKXqzyU/GYRCwPZiKa9k3F3oTJ9yEmjPnVHOOkUYY?= =?us-ascii?q?oBwgqLeNaYHZ44f5cs75h6mJYqYDR7zKl4bsekeWHULOW82Ic3lYv1k62gEgHU?= =?us-ascii?q?MIeF98vlgdWifhj5DcynpSOZX4VDfnZw3DQGuG4EgMmLtsvwo1V/kuBl/ssIuD?= =?us-ascii?q?8yvCiLR1MG+KCe1LV1E8+t6qK2UcE/3NolPxhb7xGMhk/ZzahxridzP1RtZG3U?= =?us-ascii?q?QcoOqCKh+0ZVxRKOyB4J6xPvrHdSZS6mZfDlRSbKiW0mp2CC2lzZ+X04N1fBGV?= =?us-ascii?q?V3f0VND5LaQqM799aaprTpvJE3ZtldZaxetlF4Tc6lm+xMBrveribK42i2DOS9?= =?us-ascii?q?G5YahhyIMvj?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ATQtjR6tQ/8jxt9FZw3U13EQN7skDb9V00zEX?= =?us-ascii?q?/kB9WHVpm6uj+PxG/c526faasl0ssR0b+exoW5PsfZq/z+8X3WB5B97LYOCMgg?= =?us-ascii?q?WVxe9ZjLcKjweLJxHD?=
X-IronPort-AV: E=Sophos;i="5.82,319,1613430000"; d="scan'208";a="382151601"
Received: from unknown (HELO [10.178.148.236]) ([37.172.223.236]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 21 May 2021 23:03:55 +0200
Date: Fri, 21 May 2021 23:03:56 +0200
User-Agent: K-9 Mail for Android
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----TRMF0O7SG1WVDRR2M0HO1OKXXP0DWJ"
Content-Transfer-Encoding: 7bit
To: mls@ietf.org
From: =?ISO-8859-1?Q?Th=E9ophile_Wallez?= <theophile.wallez@inria.fr>
Message-ID: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ucWsEppB9BqchJtcAOzL8A0xsEQ>
Subject: [MLS] Turning mandatory extensions into fields
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 21:04:05 -0000

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