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

Richard Barnes <rlb@ipv.sx> Wed, 03 March 2021 19:33 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 73E763A18F7 for <mls@ietfa.amsl.com>; Wed, 3 Mar 2021 11:33:14 -0800 (PST)
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 LIw2iZSk-dM5 for <mls@ietfa.amsl.com>; Wed, 3 Mar 2021 11:33:12 -0800 (PST)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 19F8D3A18F8 for <mls@ietf.org>; Wed, 3 Mar 2021 11:33:12 -0800 (PST)
Received: by mail-qv1-xf2f.google.com with SMTP id r5so12270926qvv.9 for <mls@ietf.org>; Wed, 03 Mar 2021 11:33:12 -0800 (PST)
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=L0wBLWMYrUW7zGTgMGTjX5bblc+ZssnZ+5sb+uEbmCA=; b=MDh3CR7OG4n7nf8FfRj4f01A4dB0oXIBs/yilbkOq2fvq/I2OCTXFIcmzsoJfbCM1T vkqfn65B6wnTD1Rgb8zyfsTWOKI5LV/+1t9uOclbyBvkwK69fhZTqZF49xdDRh5R3YSB pk6+xddDASACDOKOZp+RkwKMZEBJa7u2lQYW93ByBV9rOMXCflugV25NxI95evHj1quO l6rjPkHGvIDetIKaZ6lDwl6FO6NNbCx4DC8PXXx33p91XeptX4BGp+TDYoPyu/9COa6W /vUTo1bH3owHuteYQb7Cg12KFn2VM7zQ7M9aYMZYwnR8vbjH9NH3D9k5JwgOvPFLS/H6 KZ/Q==
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=L0wBLWMYrUW7zGTgMGTjX5bblc+ZssnZ+5sb+uEbmCA=; b=D4ZD9LI/XP1QGgoXz/fgI5+0GMTymt+abA6H64e0rvFbwVrnPbjOdcOJUMf1hh4QI8 LmYiaF5OvMMU1s+WG/7gIEaHVh0nai04lEk2ygZFXRYSK5WNQ1y7P9j3pbB4AvTm8pkd 4N5b1dI6IXwkcpKyUGsMs7qiWAELnQLDKmRneUCvTX2pxHZYTZPPxjka+BQw+SausRzz sEUpUHBszimjYt0wtpg8sloo1Ylo1b1yPoJWZJq5FPkThpebwfFQc7CLu3aKBmLYg9n2 wCgt/SY7RAjOG6Xr4N8PCkgf5TREMiOhWjKePinc162efFGgE5xhbI7RMUI6PgbCMM1T dlbg==
X-Gm-Message-State: AOAM533goj8FXM8aShL2QbgUeUVDs2sx1b0B8UcvCRzYMH9LALKk7hpr kwcm+/nf0tg8YXaayZ+opTIkEX55TP41jC6tlAwZFocGZk0X6ni6
X-Google-Smtp-Source: ABdhPJx/o7smqFTVOYAGWlF6QTo2IbFphGLdgfc6b9Qo4f3IMSqHqTDVq4NSmeTU6z0kxm39oLI2WJ3mc0G67UNqNEs=
X-Received: by 2002:a05:6214:268c:: with SMTP id gm12mr553333qvb.36.1614799988183; Wed, 03 Mar 2021 11:33:08 -0800 (PST)
MIME-Version: 1.0
References: <107abb03-e620-43ed-ac75-034ab6ed1ff4@www.fastmail.com> <8E3FEF5E-F5B5-4B58-A5BD-2464383C245A@wire.com> <924f2f66-795c-4149-b5bf-dd61bf99e678@www.fastmail.com>
In-Reply-To: <924f2f66-795c-4149-b5bf-dd61bf99e678@www.fastmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 3 Mar 2021 14:32:49 -0500
Message-ID: <CAL02cgS_feKFwkarCQ=M649KAZSGznVnAF0OoRw20FBE4f5+Vw@mail.gmail.com>
To: Hubert Chathi <hubertc@matrix.org>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000adeb8a05bca6ebc6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/EogKajJylbHkXDE3CP-iNZFAI1w>
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: Wed, 03 Mar 2021 19:33:14 -0000

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
>