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

Richard Barnes <rlb@ipv.sx> Mon, 10 August 2020 14:23 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 D8A843A15E5 for <mls@ietfa.amsl.com>; Mon, 10 Aug 2020 07:23:05 -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, 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 ET09tTVANY-x for <mls@ietfa.amsl.com>; Mon, 10 Aug 2020 07:23:04 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 CA41E3A15E4 for <mls@ietf.org>; Mon, 10 Aug 2020 07:23:03 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id 2so8429494qkf.10 for <mls@ietf.org>; Mon, 10 Aug 2020 07:23:03 -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=oG3VBdDkJoc+BHKz2GN466Jlat6tlpuV0/yZcBLoW08=; b=TwpqbQSpHPXhhBLqmL28kY9Fruk6MlJk1vugsTa6G9OvFlR6V+fNycgf5dtCWkHCka xVOAu4YvszNz5sjOZt0C1DAy0Dl9ZyurKhnfruDejIlBbdymhGgRtAMFbbajVhFmg5te 02KYpZZdtGuWXtEIPR3UEc3kbPk47fd+FrNomxLYxjynp81BunguVR2R0vQm6Ey+Xd6f 8Iiu/pSfmlJxtpoq5LE2h3OjnnHzfxkWKuHdikDlPKD6C7daFCsy5OkEo3WzcsaUn9YM w+NXK1bsy68uC63CVnpwRcvrVN8xdWlCEPFK5HZEog0z3qJ77HVBpfge06wlrBCnDSvq mHVA==
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=oG3VBdDkJoc+BHKz2GN466Jlat6tlpuV0/yZcBLoW08=; b=eEhUjreoz6uba7WDeRpzuErkCiEuBNkq7CnXlkUw2l2qUAqsWsq0MQ5AYNIPGmb5RP qOugGxwWofMDaJdQE48JhK/hnq+Rivgs78VR02KLjpisOqhaJS0hVI46e/BJBy8EPwOf FuKhcc9nzBC5ATA/N+RvAYWg1PF6fnpqPiCecONe7q+eda1aSMBkJhi3/V9ERL277xL5 PU/XF0TIxovMRRDy64IXqD1Odg0dmF2Dfi+i2GHywCiFHrT/IQ0Gd9MJ8maY2VX9jW+i rYJ2yMqRiNgZ0dUjNkzt+VjkjWKDl+xle5AFRAEky+VBxRgB/WHvBUATAt33NvhdY8bj T9lg==
X-Gm-Message-State: AOAM530VUv/G1UA8DycIGVQu627pfZtVxYNRmMpqfw3KVR2PM72k8YYg Syi65K7xwB6GCF3Xo3jJuw2wn2bukiWGC5IELuZHqA==
X-Google-Smtp-Source: ABdhPJxJnty9qjwdsKZAyKxrMRQBK/JwmWlyxkpb9TWWZdqRLqUNO368zIIF+aOvZyvyGufZERldT1FsP2LsT2C6FNo=
X-Received: by 2002:ae9:ee06:: with SMTP id i6mr25331427qkg.132.1597069382281; Mon, 10 Aug 2020 07:23:02 -0700 (PDT)
MIME-Version: 1.0
References: <af4a72d6f3ae4c809367222386340e6c@aalto.fi>
In-Reply-To: <af4a72d6f3ae4c809367222386340e6c@aalto.fi>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 10 Aug 2020 10:22:47 -0400
Message-ID: <CAL02cgRX6m_Ygo1wwWL_Sd3ygYKGZLs=TwsDVksy3V7zUqZEqg@mail.gmail.com>
To: Cornelissen Eric <eric.cornelissen@aalto.fi>
Cc: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000369ba405ac86b14b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/LpPfMsrl4VEfPYl5XJ2-rg5rRA4>
Subject: Re: [MLS] Two poorly defined aspects of the spec
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: Mon, 10 Aug 2020 14:23:06 -0000

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:

https://github.com/mlswg/mls-protocol/issues/386

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 <eric.cornelissen@aalto.fi>
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
> <https://github.com/mlswg/mls-protocol/blob/39455d2ea5e8fb42e8f0f0624bddd8c56675da0e/draft-ietf-mls-protocol.md#group-state>
> <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#group-state>,
> or
> b. a value derived based on the MLSPlaintextCommitAutData for the first
> commit concatenated with 0:
>     interim_transcript_hash_[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] ||
>             MLSPlaintextCommitAuthData_[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
> <https://github.com/mlswg/mls-protocol/blob/39455d2ea5e8fb42e8f0f0624bddd8c56675da0e/draft-ietf-mls-protocol.md#group-creation>
> ?
>
> 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
> <https://github.com/mlswg/mls-protocol/pull/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).
>
>
> Regards,
> Eric
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>