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

Richard Barnes <rlb@ipv.sx> Fri, 07 August 2020 16:06 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 2EB2B3A0B3B for <mls@ietfa.amsl.com>; Fri, 7 Aug 2020 09:06:10 -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 N-M6hFB8h9dR for <mls@ietfa.amsl.com>; Fri, 7 Aug 2020 09:06:06 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 585CC3A0B46 for <mls@ietf.org>; Fri, 7 Aug 2020 09:06:06 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id x69so2192807qkb.1 for <mls@ietf.org>; Fri, 07 Aug 2020 09:06:06 -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=yF0uzHy4WP4xT0NZASx8DOHztGyIi2AcyOFnOto4WpA=; b=MvH3dviiq37Gqs6UcVkZH2UNLHbnt9FTv0Zj4pjKRDVEAq5ccAoDnfEezbW+xKd7oy EiOT2mljCIKaFP/DSNr/KU1d8bN6WYJn6uON/uZg5PGXDJPfLadmEAy6lezer2gYPuSO zptKlxJnBmK6kl7YwWDhPL9xGjBK8QUeNNyXP9JLykdFR3A9vgAVMiAV0eD310bJbG5q aBi0JfYMM2wEiNBFVUE9gvZ7KtqbOwePFsek9TTMX4kEzIraLKH1qlDadopYSp6XEFPi IygVPklKOIrwRdMmM6UZzLYfdCuzjRI5o3pSMag98GNYhgabDWYlqSs7wJkoExdxVBhO SOmA==
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=yF0uzHy4WP4xT0NZASx8DOHztGyIi2AcyOFnOto4WpA=; b=A86v2FK1gJZ/pNHgk119aqgTBi3AzDawLcrAMF0ypy3ScDkTGVPRxdpZOou6q0NvFr fpZ9UM9KWe8IuezqCyRoM6h2OaWkiqAAFopA9IYJgOl/kN+9OaF1rn0Q+rXc1DUeL7aX kfZbotGBujhqXnsh8v3jl18msuC+alyxQvwUhmTTdj2HJDb0d0P7G+XgnNVXmaOBek7z GGPVsmWOAVwhO0VmH2uemTUC+jlGjKdz5NB0UA7bc4WQcF/an32UHkWGTy4WZ3tQk2Ac j3ETq2kb6HgZXgIcSDTjML3OLPJyQw4H8ixm4ct6XDM4MaRNhTw29pQgr4lR5Uupb9kf jsXw==
X-Gm-Message-State: AOAM533DSfnR+LJ+kiTji5v//VRZBkYnluHYWaQQHNdzMD7Aw2o9TMdJ 1zFpu3KtT76hUmnpK9pxl4HqV1IeURsOFRTrvQcz2cnKJCCpLQ==
X-Google-Smtp-Source: ABdhPJwUqNV+6eltyhfP+ljdjduCMzlLnqPF/+cSvwIGil3ccPttq4Cd79NkEIJaOotzTvUv3sHsjeDU8jGjbzErMUA=
X-Received: by 2002:a37:99c7:: with SMTP id b190mr14710924qke.347.1596816365177; Fri, 07 Aug 2020 09:06:05 -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> <CAL02cgS_xVANTvYn+pHq69CZUi4nJPgnayRp6OORXmt+k2Kn0w@mail.gmail.com> <CAL02cgRMtZgc6vfcSjMzWQ1wguXB-764BaRn6X8qBa=gB9iLdA@mail.gmail.com>
In-Reply-To: <CAL02cgRMtZgc6vfcSjMzWQ1wguXB-764BaRn6X8qBa=gB9iLdA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 7 Aug 2020 12:05:50 -0400
Message-ID: <CAL02cgStRwiFpZ8A6-puRFW+C8u6FyMod1oTesntyGQryS8vjw@mail.gmail.com>
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000037e61805ac4bc8fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/kTtE1mFPqHCqp0IS75rSXqbR_z4>
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, 07 Aug 2020 16:06:11 -0000

Konrad, Britta and I just sync'ed up and drafted a plan of action on these
issues:

- For Commit Extensions (#366), PR#369 is fine, we'll focus on landing that
- Konrad/Britta are going to draft a new PR for how PSK are signaled and
included in the key schedule, using a Commit extension (#367)
  - For simplicity given that PSKs are optional, injection will be in two
phases: (1) combine the PSKs into a derived_psk and (2) inject the
derived_psk into the key schedule
  - So some of the nPRF stuff might get pulled in for that first stage
- PR#336 will get refocused on defining how resumption is done using the
PSK mechanism (#368)
- Konrad/Britta will either make a new PR for Authentication Codes (or
whatever we call them) or keep them in #336

One significant design question for the group: Should we have a Proposal
that allows group members to request that a PSK be injected?

On the one hand:
- Having a Proposal would bring the full PSK lifecycle within the scope of
MLS.  In particular, the request would be authenticated within the group
and included in the transcript.
- If the DS wants to instruct the group to inject a PSK, they could re-use
the proposal-from-outside machinery that already exists

On the other hand:
- It's not clear that including the request for a PSK in the transcript is
all that useful (as opposed to just the instruction to use it)
- We would probably want to solve the general problem of new proposals
(#383) if we do this, which is a nontrivial amount of complexity

Overall, my inclination is to not have a Proposal, since the benefits of
extra authentication don't seem to merit the complexity.  But feedback from
others would be useful here.

--Richard

On Tue, Jul 28, 2020 at 1:37 PM Richard Barnes <rlb@ipv.sx> wrote:

> Actually, noticed one thing that isn't accounted for in that list:
>
> Derive an "authentication secret"
> https://github.com/mlswg/mls-protocol/issues/374
>
> A fun question for the list is what we should call these things, since
> there are a bunch of terms in the prior art, for example:
>
> - Authentication secret [PR#336]
> - Short authentication string [ZRTP, TLS]
> - Safety numbers [Signal]
> - Security codes [Zoom security whitepaper]
>
> Personally, I'm inclined against things that include "authentication",
> since the thing we're defining here is a backstop to the primary
> Authentication Service.  Among the above list, "Security Codes" might be my
> favorite.  Otherwise, maybe something like "group state verifier"?
>
>
> On Fri, Jul 24, 2020 at 6:39 PM Richard Barnes <rlb@ipv.sx> wrote:
>
>> 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
>>>
>>