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

[Konrad Kohbrok <[e-mail]>]

I think the question Extension vs. Proposal will come up again at some point in
the future, for example when we introduce the next generation of TreeKEM-like
primitive. So maybe it would be worth taking a more methodical approach and
tackle the problem now rather than later, when we already have a bunch of
extensions that would better fit as proposals.

But I don't have too strong an opinion on this and if the rest of the group
would prefer getting on with finalizing the spec, then that is ok by me. I just
think that that complexity will come sooner or later.

Konrad


On 07.08.20 18:05, Richard Barnes wrote:
> 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 <[e-mail]> 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 <[e-mail]> 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
>         <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>             on behalf of Richard Barnes <[e-mail]>
>             >> *Date: *Wednesday, June 17, 2020 at 3:54 PM
>             >> *To: *Messaging Layer Security WG <[e-mail]
>             <mailto:[e-mail]>>
>             >> *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
>             >> [e-mail] <mailto:[e-mail]>
>             >> https://www.ietf.org/mailman/listinfo/mls
>             >>
>             >
>             > _______________________________________________
>             > MLS mailing list
>             > [e-mail] <mailto:[e-mail]>
>             > https://www.ietf.org/mailman/listinfo/mls
>             >
> 
>             _______________________________________________
>             MLS mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/mls
> 
> 
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>