Re: [MLS] Turning mandatory extensions into fields

Richard Barnes <rlb@ipv.sx> Fri, 25 June 2021 12:57 UTC

Return-Path: <rlb@ipv.sx>
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 3A38C3A161B for <mls@ietfa.amsl.com>; Fri, 25 Jun 2021 05:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 Cyhs1NArDDZ7 for <mls@ietfa.amsl.com>; Fri, 25 Jun 2021 05:57:34 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC133A161A for <mls@ietf.org>; Fri, 25 Jun 2021 05:57:33 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id q190so18936798qkd.2 for <mls@ietf.org>; Fri, 25 Jun 2021 05:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gvi53sv9b10k3Zl07ZDSgsIzmmJenWRMm34A08siG48=; b=qFYlzCR+BnT/pcdeywLet4QKz2nqAk2Z7NJM2+IYQvLI7sAMIb1ACVpRVgCrhEtYAF VfCdz/bXxPfOou2CqQ8WE+VWhpX1wjdqlfMMVT3cVvMUe0YvjsR7bWKmTgf810VAffLO 6joTAbP2ap3kzVvb57Ht9W3zdzx/yPYl7V7IDnLhWOJi+fqZb/SanK8Xh+FtFlv5YYpJ dH90xQ0LXOmIEgh2pM6OlTYOYmZ3Ii1gyuG8iz0HZ0FXarzqcLCScZxl54w1SAzT3nY+ 9bKbmnCq1giB0kGQxhUcLlUMgsig+eXoDG56ikgtHIWjfpkEVYpTXiV93e/NV/SBRUpu KlLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gvi53sv9b10k3Zl07ZDSgsIzmmJenWRMm34A08siG48=; b=aLKNdKYZ32qbUAv6X9f8SqToexRH9eVbeaM0oBpeXXjn85UHDZZNAe68z2Gfzdb7Bn 13hfFLzS90RJBOMGdbGnDPtsof2WrWNdrHyEL2/UtIEYsaF/PfZp65m7e+ybeKO1q5KK 9z16RwjAxKr/3/HbXqOWKNMQE8ssYMfGbv3f1J3RMA3WZ+YiMgWLoV1HJfBDQZbgmEy8 e9o7e7UkMLEjGHQ1wRagT/k0Nh9bWfs3qAfB72uqD2TO/lGazLDe9aVCv6qeihWaVmMI +mCfTBrybWFlMLXZ9S8OGJVlj13GZcqOba0NZ7nvxEYCt5BCNhcnttsX7gPDQRy/yJlN metQ==
X-Gm-Message-State: AOAM530AHtUpCfB2xvAPTByugicHEOHBbt4fbpgfRB5XmEDk5jDvBnTW FincocD2h3jZUquKKjca8gQ/jSGd5u2zQckrgZ9Xeg==
X-Google-Smtp-Source: ABdhPJxYZ7KNEbzzhpBngyES6FWcIEGpxSN1Zwnh0Ke3EiGe6LlRmex4uWHlnw9uhxu6E7lX46VGXDVbuF4OgGxezOY=
X-Received: by 2002:a37:63c2:: with SMTP id x185mr6981174qkb.159.1624625851576; Fri, 25 Jun 2021 05:57:31 -0700 (PDT)
MIME-Version: 1.0
References: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> <CA46F1F3-DA2D-4CCA-AAF2-7A2F126505CA@raphaelrobert.com> <073ddbb9-df13-10e1-c151-bbb52617dfaa@inria.fr> <1913706681.187825.1624276616584@office.mailbox.org>
In-Reply-To: <1913706681.187825.1624276616584@office.mailbox.org>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 25 Jun 2021 08:57:20 -0400
Message-ID: <CAL02cgSp56Qg=xc+2grHwvVNKAM1Jc-6Zh_NABtC+=tVBeAQ9g@mail.gmail.com>
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: =?UTF-8?Q?Th=C3=A9ophile_Wallez?= <theophile.wallez@inria.fr>, Raphael Robert <ietf@raphaelrobert.com>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6c63405c596ae00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/LK0F-7uD83upExPGPZAf_IzIqxk>
Subject: Re: [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, 25 Jun 2021 12:57:39 -0000

I would oppose such a big change this late in the game.  There is
substantial overlap in what is needed from KeyPackages and leaf nodes in
the tree, and designing some new leaf struct would require significant
reinvention and revalidation to ensure that we haven't damaged the
authentication properties of the protocol.

--RLB

On Mon, Jun 21, 2021 at 7:57 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de>
wrote:

> Hi Théophile,
>
> thanks for bringing this up!
>
> I believe splitting the two structures would be a good idea. It would also
> allow us to have a second private/public keypair in the init key struct for
> better FS as suggested in the past by Joël.
>
> That being said, I believe we need the lifetime field/extension in both
> structs, as init key structs should also have an expiration date. If
> anything, the lifetime extension could be omitted in the leaf struct, as
> I'm not sure what the consequence would be if a leaf key package expired in
> an active group. (Would other group members still encrypt to the leaf key?
> Would they reject messages from that member that are not updates? This
> would have to be defined in the spec. Or is it already?)
>
> Cheers,
> Konrad
>
> > Théophile Wallez <theophile.wallez@inria.fr> hat am 21.06.2021 13:04
> geschrieben:
> >
> >
> > 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,
> >
> > Théophile.
> >
> > 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 <
> theophile.wallez@inria.fr> 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
> > >> MLS@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/mls
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>