Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336)

Richard Barnes <rlb@ipv.sx> Fri, 24 July 2020 22:39 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 0BE243A09F7 for <mls@ietfa.amsl.com>; Fri, 24 Jul 2020 15:39:54 -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 e1BeTN7TkaX5 for <mls@ietfa.amsl.com>; Fri, 24 Jul 2020 15:39:51 -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 CC37C3A09F1 for <mls@ietf.org>; Fri, 24 Jul 2020 15:39:50 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id s23so8035721qtq.12 for <mls@ietf.org>; Fri, 24 Jul 2020 15:39:50 -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=AjU5XPHY9kGTaMknZ/a6mYVCCwC7CSRVbOqqgsr19M4=; b=e4ObzVvqmK9DYDmKCVDobvJStTpCdcdMkc+9tRAG/OdJrxDyLb3/RJHnZnqE+j6SKC f9u1Ia4GXfmE+YoQ8dco7gf3OhpvSa52YHwRUac44WiyGRGSO2+0naNQZuJuPQIsw9Ro UH86RKIrXtHZ48lPU4wnRuHSaBDuERXPp+s+90BafiI2kaNltZe03ycptLu/aEksVOYl qKvTDKJLqvJWX1Ep8FnxC5UoDouZf71kPI8D0JrpuwunGfepENSjtxPlaZw6PnltCiRZ AzDfbZ2bv+dMJXVS2q1ta4SQFPUS+qv4kTvu6HBzgFGZ3BbtRUh0t1EMsFHhIgflgFQr n/tA==
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=AjU5XPHY9kGTaMknZ/a6mYVCCwC7CSRVbOqqgsr19M4=; b=G39fDTMz+wqcXpd802h6Ey57k2MMJRJ5HuRi4tXYbASfIjVsNYCFhXeXwUq9RAIjsq W4j6jI049o66eCY9TqQrttVZ8XGr1U5eCX1IzuB602bvc5dX2y69u+Y3v1OMV/9IjBPI UBU/kqm4N3ziNzRGf62P0qa1AcQ1jmyVLJkgZcWr7Fw2rM5dxq0IKfzbZLXIiXSPK/Tx c4sq+8G5OE7kTIYr3WCdoLrgmBGp/0NvB4+NhLZHxAqi7eEcSRhbBhPys1XKHcPQol2Y XQ28m19ODSBjVstM+wZU2Q8z6Fr2E8Ob9xJRb10Md80qVPdmv3cmPR3GZ5VacFwZbEMI cfNg==
X-Gm-Message-State: AOAM531sNVFj1yKXDM6VC1MW7Ax+9alPX3nvgyNFoBbEiBJ+mcaX4yfT scVc36D1t6uHnGQe9B2EiiW6Y2n0NT3A9ASiRp3YhIAf/QtF1w==
X-Google-Smtp-Source: ABdhPJx+zQBY7G03c/tuj/6BLuK4VGXI1APMIUPEJT/1KQtMCuKYfNMIPMkTputNz3Dw6GAoLvBUkzjvfk8CgBxOBhg=
X-Received: by 2002:ac8:387b:: with SMTP id r56mr11776802qtb.353.1595630389498; Fri, 24 Jul 2020 15:39:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgTxm+OMRHvXk_34MAxk5bgit_kpkW81wigGPZriKFtebw@mail.gmail.com> <BFD5B4F7-3617-41AD-811F-C6C49A803983@nps.edu> <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> <d3c4ca24-504b-f167-f733-bf8ae5bb1d00@datashrine.de>
In-Reply-To: <d3c4ca24-504b-f167-f733-bf8ae5bb1d00@datashrine.de>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 24 Jul 2020 18:39:22 -0400
Message-ID: <CAL02cgS_xVANTvYn+pHq69CZUi4nJPgnayRp6OORXmt+k2Kn0w@mail.gmail.com>
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f2b9c05ab37a643"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/35Wd0owMgImkY_3bJBHBZBAEiOI>
Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336)
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, 24 Jul 2020 22:39:54 -0000

Picking this thread back up:

I tried to encapsulate my approach to the issues here in a few GitHub
issues and one PR:

Reorder key schedule inputs
https://github.com/mlswg/mls-protocol/issues/362

Add extensions to the Commit message
https://github.com/mlswg/mls-protocol/issues/366

Negotiate PSKs
https://github.com/mlswg/mls-protocol/issues/367

Proof of prior membership in the group / Resumption
https://github.com/mlswg/mls-protocol/issues/368

Konrad / Britta - I think those combine to cover the cases you were trying
to address in #366, but tease the issues apart a bit more clearly.  Does
that make sense to you?  What have I missed here?  If this general plan
looks good, I think we can get the details arranged and agreed fairly
quickly, as these are each pretty self-contained pieces of work.

Thanks,
--Richard

On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok <
konrad.kohbrok@datashrine.de> wrote:

> We just briefly touched upon this PR in the virtual interim on July 14th
> and I
> think we agreed that the discussion should be continued on the mailinglist
> and
> then tied up at the IETF 108 meeting.
>
> I think continuing the discussion on the mailinglist is a good idea,
> however,
> neither Britta nor myself are going to be present at the IETF 108 meeting.
> Maybe
> we can push the discussion to the next virtual interim meeting instead?
>
> Cheers,
> Konrad
>
>
> On 18.06.20 16:29, Konrad Kohbrok wrote:
> > Hi,
> >
> > Just a small addition to Britta's response:
> >
> > For #3: We already mandate that the parent group must not be used
> anymore if a
> > Re-Init proposal is included in a commit in lines 2341-2342 of the PR
> (although
> > "to send messages" might as well be removed). We could also get rid of
> the
> > proposal and simply have the intent to re-initialize be implicit in
> sending a
> > Welcome message with a corresponding PSK Id. The idea behind the
> Proposal was to
> > make that intent explicit such that the intent, as well as the target
> > ciphersuite and MLS version are all entered into the transcript and thus
> agreed
> > upon. Even though the group is terminated after the proposal is
> received, this
> > agreement can be verified by using the authentication key technique that
> Britta
> > proposed, i.e. each party can check that their authentication key
> corresponds to
> > the one the committer uploaded.
> >
> > I'm also ok with splitting it into multiple individual PRs if that makes
> it
> > easier to review and discuss.
> >
> > Cheers,
> > Konrad
> >
> >
> > On 18.06.20 04:07, Hale, Britta (CIV) wrote:
> >> Hi Richard,
> >>
> >>
> >>
> >> Thank you for the comments and careful read of the PR.
> >>
> >>
> >>
> >> For #1/#2: I am amicable to the idea of adding an extension field to
> the commit
> >> message. As a general comment, we may want to consider if there are
> other types
> >> of commit extensions worth adding or, alternatively, how the field may
> be abused
> >> (e.g. treated as AD by an application).
> >>
> >> It terms of objection to the current form though, your argument is not
> clear.
> >> PSKIds should uniquely identify PSKs, and a joiner (or anyone) should
> be able to
> >> identify the correct PSK given the PSKId, if they are in possession of
> it. PSKs
> >> must only be used in an Add if the joiner is a past group member (line
> 2055) and
> >> therefore has the correct PSKId/group_id/psk_epoch, although this is
> nullified
> >> if we make the change discussed in #4. In that case, the issue for Adds
> goes away.
> >>
> >> The PR already allows for a PSK in the Welcome message.
> >>
> >>
> >>
> >> For #3: Currently, in the PR, there is a recovery_secret derived
> per-epoch. When
> >> a member wants to re-initialize, they issue a Re-Init proposal. They
> may then
> >> re-initialize the group by sending a Welcome message (see lines 1923,
> 1948, and
> >> 2349) with the PSKId for the parent group/epoch and a psktype that
> indicates
> >> that they are re-initializing the group with the stated PSKId. So this
> seems to
> >> already be what you describe below as “have the initiator of the child
> send a
> >> Welcome that has a pointer back to the parent”. However, you are right
> that more
> >> detail can be added; in particular a requirement should be added to
> terminate
> >> the parent group and that the terminating member/re-init proposer must
> also
> >> create the new group.
> >>
> >>
> >>
> >> For #4: There was a discussion at the first virtual interim in late
> April
> >> (Interim #11-2020) wherein some expressed a desire for this feature.
> Namely,
> >> instead of re-syncing the entire group, there were use cases for
> re-syncing the
> >> odd member when necessary. Its inclusion in the PR arises from that
> later
> >> request. I am favorable to removing it since, from security standpoint,
> it is
> >> not ideal. However, the motivation for this was pushed from the
> implementation
> >> standpoint. Consequently, now is a good time for anyone to speak up who
> wants to
> >> push for this.
> >>
> >>
> >>
> >>
> >>
> >> One item: you made point of specifically requesting – a few times – at
> the
> >> virtual interims #11 and #12 in April/May that this PSK PR and as many
> other key
> >> schedule-related PRs be combined into a single one. Raphael made a
> similar
> >> request under git issue #325. In fact, the authors of this PR had
> pushed back on
> >> that insistence to limit the current PR down to the items it currently
> covers,
> >> instead of merging in other key schedule changes as well. Are you
> saying that
> >> you have changed your mind?
> >>
> >> We can, of course, accommodate a revised preference if needed.
> >>
> >>
> >>
> >>
> >>
> >> Britta
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> *From: *MLS <mls-bounces@ietf.org> on behalf of Richard Barnes
> <rlb@ipv.sx>
> >> *Date: *Wednesday, June 17, 2020 at 3:54 PM
> >> *To: *Messaging Layer Security WG <mls@ietf.org>
> >> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group
> Branching (#336)
> >>
> >>
> >>
> >> Hey all,
> >>
> >> Sorry for the late review on this PR, I have finally gotten a chance to
> really
> >> dig into it, and ... I have some concerns.  My current thinking is
> consistent
> >> with my earlier comments that the general thrust of this PR is OK.  But
> I think
> >> the actual approach needs to change a fair bit.
> >>
> >> As its title implies, this PR is trying to do several things at once,
> which seem
> >> to me to be fairly separable:
> >>
> >> 0. Update the key schedule so that PSKs are injected at the right point
> and
> >> multiple PSKs are supported
> >> 1. Signal that a PSK should get injected into a given epoch
> >> 2. Request injection of PSK at join / in Welcome
> >> 3. Re-initialize the group with different parameters
> >> 4. Re-sync group members that have lost state
> >>
> >> For the most part, I think these are worthwhile goals, but they should
> be
> >> accomplished in different ways than the PR proposes.  Detailed thoughts
> by
> >> objective:
> >>
> >>
> >> # 0. Update the key schedule so that PSKs are injected at the right
> point and
> >> multiple PSKs are supported
> >>
> >> This part of the PR is fine, but I think is ultimately done a bit more
> elegantly
> >> with the n-PRF stuff in #337.
> >>
> >>
> >> # 1. Signal that a PSK should get injected into a given epoch
> >> # 2. Request injection of PSK at join / in Welcome
> >>
> >> (These go together)
> >>
> >> The PR proposes (heh) an EPSK proposal or an Add proposal, but then
> requires
> >> that only one EPSK be used.  I actually don't the proposal for
> including PSKs in
> >> Adds actually works.  The joiner would have to know all of them plus
> the EPSK,
> >> and there's not even any syntax in the PR to tell the joiner which ones
> to include.
> >>
> >> I would propose that instead we add an extensions field to the Commit
> message,
> >> then add a Commit extension that specifies the PSK ID for the PSK to be
> added.
> >> That extension can then also go in the Welcome message corresponding to
> the
> >> commit, so that joiners know to add the PSK.
> >>
> >> This change actually doesn't make a difference in terms of what ends up
> in the
> >> transcript -- either way, only the PSK ID selected by the committer
> goes in the
> >> transcript.  It seems better not to deliberately have proposals
> floating around
> >> that never get included in the transcript.
> >>
> >>
> >> # 3. Re-initialize the group with different parameters
> >>
> >> The PR proposes another proposal type for reinitialization, but it's
> really
> >> under-specified what you do to re-init.  For example, what goes in the
> ratchet
> >> tree?  Clearly you need a brand new tree, since the one you have might
> be tied
> >> to the wrong ciphersuite.  What you really need is something like a
> Welcome message.
> >>
> >> And that's how I think we should actually arrange things.  Instead of
> having the
> >> parent group do something to spawn, have the initiator of the child
> send a
> >> Welcome that has a pointer back to the parent.  So we have another
> Welcome
> >> extension (`parent_group`, say) that has a pointer to the parent group
> by group
> >> ID and epoch, and instructs the joiner to take a secret from that
> group/epoch's
> >> key schedule and add it into the new group's key schedule.
> >>
> >>
> >>
> >> # 4. Re-sync group members that have lost state
> >>
> >> We should not do these.  At the January interim, we decided not to drop
> the
> >> resync issue (#93) given that there were some subtleties depending on
> exactly
> >> what state had been lost, and that it could be cleanly done in a
> separate spec.
> >>
> >>
> >> # Conclusions
> >>
> >> Given the above, I would propose we break this into separate issues to
> be closed
> >> with individual, smaller PRs.  Assuming that (0) will get addressed by
> the n-PRF
> >> PR, that leaves us with:
> >>
> >> #XXX Add Extensions to the Commit message
> >> #XXX Signal use of external PSKs in Commit/Welcome (=> extension to
> >> Commit/Welcome messages)
> >> #XXX Allow Welcome to signal the inclusion of information from a prior
> group (=>
> >> Welcome extension)
> >>
> >> Happy to write those up, and contribute to PRs.  Sorry again for the
> slow
> >> progress here.
> >>
> >> --Richard
> >>
> >>
> >> _______________________________________________
> >> 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
>