Re: [MLS] Two poorly defined aspects of the spec
Richard Barnes <rlb@ipv.sx> Tue, 11 August 2020 15: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 D4B413A120A for <mls@ietfa.amsl.com>; Tue, 11 Aug 2020 08:23:02 -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 Ubx1QebyweN7 for <mls@ietfa.amsl.com>; Tue, 11 Aug 2020 08:23:00 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D7E733A120E for <mls@ietf.org>; Tue, 11 Aug 2020 08:22:48 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id w9so9670901qts.6 for <mls@ietf.org>; Tue, 11 Aug 2020 08:22:48 -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=q88QUhsyQkkq3E079URs2YYJRYWI1k+SGPVuvf1ZSuI=; b=TlG8HzxFp5+r17WVp5bE4PyNihptNdccErmC7PVuLOAd0xHUjzJb2G9TNmTqLSnqgd One3IBCGMsD2ODGZQAdVg4Zrm6rIYrJT4cp5b/85kb1ie8wq3IxxIy7wlpDUtHVnHdWm tvXMoLZ3coRZSkyyh/ao17C56Dwjpxh9K/8zoLq7ch+khqB38SupuuNbvFbRAiHRIEqI PlAtIj1anhfaXnVkbrZlT1m5LaJTHJ+EOpc4fio6aASRDH528RzYH48WlW5RKOAPZzX3 a8HtpRJmnAyNTfPLBdBj3SbtObhddesyEDetA5vpW8MacPJC4GtQ5HPf6kxxN7nzLotx 3hDQ==
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=q88QUhsyQkkq3E079URs2YYJRYWI1k+SGPVuvf1ZSuI=; b=Ed9/aKYij22VmBvfak9BkgbqYBua6nkW+m5iaCIlKKnSb3fTuLH7aYVjlKIJrnH5C2 qMlr3+bI/SdyNS0OCHlnCe/A3n7gAgX3jcHkBONyLXsX+b7Rr4eCz5FeZu3Zx3NlQcsc E+G74+8hF9cCf5JOOgCFI7aab1vy4BY/TSCF5D76I06G0EUX6l11817USYAv/6edmNDM NNLT180kFyqRNk70XB5El9bgvSIun622nbDwH4ZrvhLFXCxg6T1SA6wpd4KEa8Tk61O3 wyi2bGPzPPiX40Q+4UEz68bnKwv2MJHTirSMgU7dmzmOUvtE0WcPDeGOelPqLcwhpuva 4d6w==
X-Gm-Message-State: AOAM530gY0Cr7cZpl2XNDrFcH/SJlVbuOEHo/KPy0B9XLxgBmW/V4K5o FMe4YR+SUVJ21uDjGhm2guzh4pfMSYCEpMhX5QtYiQ==
X-Google-Smtp-Source: ABdhPJzvPEho4bO0picGh1EqcW4D45rhsIH2UN3h6cDR2hXLDo8/HmLb3JbfnpgblE/Zo+k4PTQsWTunhUWhYf8g5JU=
X-Received: by 2002:ac8:32dd:: with SMTP id a29mr1609028qtb.191.1597159367144; Tue, 11 Aug 2020 08:22:47 -0700 (PDT)
MIME-Version: 1.0
References: <af4a72d6f3ae4c809367222386340e6c@aalto.fi> <CAL02cgRX6m_Ygo1wwWL_Sd3ygYKGZLs=TwsDVksy3V7zUqZEqg@mail.gmail.com> <cc19f450a410431cb3be124c96417c60@aalto.fi>
In-Reply-To: <cc19f450a410431cb3be124c96417c60@aalto.fi>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 11 Aug 2020 11:22:32 -0400
Message-ID: <CAL02cgS77qKv5zT38P4BsAvsAi_vyPDs9oEWxYuYJikAyopNHQ@mail.gmail.com>
To: Cornelissen Eric <eric.cornelissen@aalto.fi>
Cc: "mls@ietf.org" <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba97eb05ac9ba41c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/8yzzZNw98LT0dnZXM38UQe1vlaY>
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: Tue, 11 Aug 2020 15:23:10 -0000
I filed #388 to fix (1) and (1a). https://github.com/mlswg/mls-protocol/pull/388 Not sure what to do with your observations about Welcome. If you have thoughts about how to clarify, please send a PR! --Richard On Tue, Aug 11, 2020 at 9:47 AM Cornelissen Eric <eric.cornelissen@aalto.fi> wrote: > Hi Richard, > > > 1. In that case I would agree that clarifying the indices is the way to > go. I personally think just adding *interim_[0] = 0* to the current > definition would suffice and be clearer than your suggestion here, but > that's just personal taste. > > > 2. The "secrets" array makes a ton of sense. > > > If the welcome is ignored when the verification fails, then the fact that > this is not strictly true seems to make it impossible to continue with a > group after all but one person left (unfortunately, the paragraph doesn't > specify what should happen if the verification fails). This is not a > cryptographic problem, but I'd imagine this being confusing for end users > *if* the application layer doesn't deal with it properly. > > > However, as I just pointed out in #385 > <https://github.com/mlswg/mls-protocol/pull/385>, it seems that we (I) > made it impossible for joiners to verify group creation at all. > > > > Regards, > > Eric > > ------------------------------ > *From:* Richard Barnes <rlb@ipv.sx> > *Sent:* Monday, August 10, 2020 5:22:47 PM > *To:* Cornelissen Eric > *Cc:* mls@ietf.org > *Subject:* Re: [MLS] Two poorly defined aspects of the spec > > 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 >> >
- [MLS] Two poorly defined aspects of the spec Cornelissen Eric
- Re: [MLS] Two poorly defined aspects of the spec Richard Barnes
- Re: [MLS] Two poorly defined aspects of the spec Cornelissen Eric
- Re: [MLS] Two poorly defined aspects of the spec Richard Barnes
- Re: [MLS] Two poorly defined aspects of the spec Cornelissen Eric
- Re: [MLS] Two poorly defined aspects of the spec Richard Barnes
- Re: [MLS] Two poorly defined aspects of the spec Cornelissen Eric