Re: [MLS] question about group contexts and deriving epoch secrets

Hubert Chathi <hubertc@matrix.org> Fri, 05 March 2021 22:53 UTC

Return-Path: <hubertc@matrix.org>
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 C2E0B3A1132 for <mls@ietfa.amsl.com>; Fri, 5 Mar 2021 14:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=matrix.org header.b=WtOEce6T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yb0cL3mc
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 DorJrXvMfzIW for <mls@ietfa.amsl.com>; Fri, 5 Mar 2021 14:53:11 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555A43A112A for <mls@ietf.org>; Fri, 5 Mar 2021 14:53:11 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1DB621401; Fri, 5 Mar 2021 17:53:10 -0500 (EST)
Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Fri, 05 Mar 2021 17:53:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matrix.org; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=XZRAPV5bAezu+n6MdCFuM9Juk/O1vW/ +s0vYGO2fHpU=; b=WtOEce6TGGz56bWOx3pOfoYXIy7dxhmGReVkOThMcsOPbCF iBr53tLYn1KD2zgSoT+FNl/VQhW433pD6BUzFQNNGd8EdYXAU+Vod12wRRhKy8Xo h5vABGmg7qFBNK/9rd5z/kKiWpScg7EOHb/5jlG5BQioeuFK1GmLbhKgnuPpgYWJ wt1OHF+a4zc/yIM4ywX27fav/ixOr0nfc4kIr5UHsCnGI9Q3CgTj+Kt/kcSbxAzg p3mYqw5DK/CUi8DA1B4dtST9vQYyUDHglBegBlW+8gCzIempSe6M62gI85jkGgCE HAYUL0xORvcb1E7CTtLCJNb9k1Y8i03JYPMv1sg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XZRAPV 5bAezu+n6MdCFuM9Juk/O1vW/+s0vYGO2fHpU=; b=Yb0cL3mck3Dm/3AFwLplXw ehZZWWQ7/87XPsgm9iQ6BAot9DwDfQ5B85Hv+ch5EASYRJDbaweLAiZ+OHfXf4aX AKWWettrFIm4ItGOZpflTl0djtFlsrei9Wu+YVi3rOt2TtC+rU50cQ34IaVdk3Cl 0p0DTKIH79e0jmzHYfu+0qODqB1OcKE+4dFFX1IL0PgRI++dkC+yx3WYVhUkeMtb WTDAZ2PGhRCacq9l5mxVWWAWZKk2JogmwGj3EDnudQm1VcD1j1c+sS8szUNgKiPF goKxdCI2emDxLuIPNiDJv6akiMrtOY+8rue7iJYOGVdvbuzrUj4nkHm353Fx14fA ==
X-ME-Sender: <xms:VLZCYDmZRroIUofjpImNoqgbeQvXQIMSGVNGy5nrnVGbcOit3GjStg> <xme:VLZCYG2POrTGXgoaIUnlxZXemRYfinf_VD4iX4luI1ubZ_zDh11n9IXZVvAtl7Xzl GC_YqF8CBVphFaRPi0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtjedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfjfhusggvrhhtucevhhgrthhhihdfuceohhhusggvrhht tgesmhgrthhrihigrdhorhhgqeenucggtffrrghtthgvrhhnpeehvdetfefgjeejffffke etvdfhuedtgfdviedvvedtgeehgeevfedvuedthfeujeenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh ephhhusggvrhhttgesmhgrthhrihigrdhorhhg
X-ME-Proxy: <xmx:VLZCYJpXpw_a_y45JfbMxckN5oWKQrLdixZqC4vZHJTqvFWampT14g> <xmx:VLZCYLkU0JV1IWdQr-ucHFy7pa_NZ5aV-JWmZ_ZNkU4tsa6SR94JXw> <xmx:VLZCYB3NBoEa7s-MR0BuOOX9i_mbBx5mI2MWs_TIDS3FbGCyV8kuVg> <xmx:VbZCYKyP-kGMDAQ5L0aY2tyYtLCc3IqlJVgbq3gGmL6D54GxP69ZHg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90DD362C0062; Fri, 5 Mar 2021 17:53:07 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <4f956d6b-87c4-44ad-b9d4-1a810c9c0170@www.fastmail.com>
In-Reply-To: <CAL02cgS_feKFwkarCQ=M649KAZSGznVnAF0OoRw20FBE4f5+Vw@mail.gmail.com>
References: <107abb03-e620-43ed-ac75-034ab6ed1ff4@www.fastmail.com> <8E3FEF5E-F5B5-4B58-A5BD-2464383C245A@wire.com> <924f2f66-795c-4149-b5bf-dd61bf99e678@www.fastmail.com> <CAL02cgS_feKFwkarCQ=M649KAZSGznVnAF0OoRw20FBE4f5+Vw@mail.gmail.com>
Date: Fri, 05 Mar 2021 17:52:23 -0500
From: "Hubert Chathi" <hubertc@matrix.org>
To: "Richard Barnes" <rlb@ipv.sx>
Cc: "Messaging Layer Security WG" <mls@ietf.org>
Content-Type: multipart/alternative; boundary=a0f56aa0eece4e26b423a7c4bae8a90b
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/4lklA6H8MA2cp2PgGzT92NStnh0>
Subject: Re: [MLS] question about group contexts and deriving epoch secrets
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, 05 Mar 2021 22:53:14 -0000

Hi Richard,

Thanks for responding.  I think that more-or-less matches my understand of how it was supposed to work, which means that I think that the joiner is missing some information.  But it's been a while since I've looked at it, and I'll have to double-check.

Hubert

On Wed, 3 Mar 2021, at 14:32, Richard Barnes wrote:
> Thanks for raising this, Hubert, I agree that it's ambiguous in the  current text, but I think there is a solution here that we just need to clarify :)  Basically, I think the "provisional" GroupContext morphs into the "new" GroupContext over the course of generating / applying a commit.  Let me try to articulate my theory of how things work here, then if that makes sense, we can try to turn it into spec text.
> 
> The joiner side seems unambiguous.  The joiner gets the GroupContext for the epoch in which they're added -- in fact, the GroupInfo carried in a Welcome is basically just a signed GroupContext.
> 
> When creating / verifying a Commit, you need a GroupContext at three points:
> 1. When you encap/decap the UpdatePath
> 2. When you ratchet forward the key schedule
> 3. When you sign the MLSPlaintext of the Commit
> 
> All three of these need to be different:
> * Case (3) uses the GroupContext from the old epoch, i.e., the one that corresponds to MLSPlaintext.epoch, so that recipients can verify the signature before processing the message
> * Case (2) uses the GroupContext for the new epoch, after the proposals and UpdatePath have been applied, so that joiners can compute the epoch_secret
> * Case (1) uses a "provisional" GroupContext that  captures the state of the tree at the time the UpdatePath is computed:
>     * epoch = old_group_context.epoch + 1
>     * tree_hash reflects the tree with proposals applied
>     * group_id, confirmed_transcript_hash, and extensions stay the same
> 
> Looking at this in chronological order for the Commit generator:
> * Cache the old GroupContext for use in signing later
> * Apply proposals to the tree
>     => provisional GroupContext
>     => compute UpdatePath using provisional GroupContext
> * Sign Commit using old GroupContext 
>     => update confirmed_transcript_hash
>     => new GroupContext
>     => epoch_secret
>     => confirmation_tag
> 
> Does that make sense to you?
> 
> --RLB
> 
> 
> On Tue, Feb 9, 2021 at 6:46 PM Hubert Chathi <hubertc@matrix.org> wrote:
>> On Tue, 9 Feb 2021, at 04:56, Raphael Robert wrote:
>> > I think “new GroupContext” and “provisional GroupContext” are synonyms.
>> 
>> I'm not so sure about this.  The "provisional GroupContext" is created after applying the proposals (line 2532), but before the UpdatePath is applied to the tree (line 2559).  Whereas, from what I understand, new members are only given the tree after the UpdatePath is applied, which would give a different tree_hash and hence GroupContext.  I don't know if I'm just misunderstanding something.
>> 
>> > Creating the Commit:
>> >  - Use the confirmed transcript hash (old intermediate transcript hash 
>> > combined with new commit content from current MLSPlaintext)
>> >  - Create new provisional GroupContext with new provisional epoch (old 
>> > epoch  + 1), new tree hash (after proposals were applied to old tree) 
>> > and confirmed transcript hash from above
>> > 
>> > Applying a Commit as an existing member:
>> >  - Same as creating a Commit
>> > 
>> > Joining a group from a Welcome message:
>> > - Create GroupContext with epoch from GroupInfo, tree hash from 
>> > GroupInfo and confirmed transcript hash from GroupInfo
>> > 
>> > Does that answer the question?
>> > 
>> > If you think the spec is wrong/confusing feel free to file a PR.
>> 
>> Yes, once I manage to understand what's going on, I plan on filing a PR.
>> 
>> > 
>> > Raphael
>> > 
>> > > On 9. Feb 2021, at 00:45, Hubert Chathi <hubertc@matrix.org> wrote:
>> > > 
>> > > When deriving the epoch secret, you do "ExpandWithLabel(., "epoch", GroupContext_[n], KDF.Nh)", so you need a GroupContext.  As far as I can tell, there appears to be a contradiction about which GroupContext to use: in the "Key Schedule" section (Line 1404), it says to use "The GroupContext object for current epoch", but in the "Commit" section under the part talking about a group member who applies a Commit message (Line 2660), it says to use the provisional GroupContext.  (The part talking about the group member who creates the Commit message doesn't say which GroupContext to use.)  If we are supposed to use the "new" GroupContext (after applying both the proposals and the update), but if we are supposed to use the provisional GroupContext, then I don't think that a new member has access to the tree_hash or confirmed_transcript_hash to create the GroupContext needed to derive the epoch secret.  So it seems like the "new" GroupContext should be correct, but Line 2660 is pretty expli
>> > > cit about using the provisional GroupContext.
>> > > 
>> > > _______________________________________________
>> > > 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