Re: [MLS] Async Add

[Brendan McMillion <[e-mail]>]

>
> b. "Init with KEM" - You could generate a key pair off of the key
> schedule, use some KEM-based operations to derive the next init secret.
>

This is a really smart idea and seems like it wouldn't break PCS of the
group like the initial proposal or a public init secret would

On Tue, Sep 22, 2020 at 7:56 AM Richard Barnes <[e-mail]> wrote:

> Thanks for posting this, Raphael.  I agree with Joël that this is a
> feature that is likely to get some use.  And the PR is pleasantly short
> (though I think it might need a bit more elaboration).
>
> On the topic of entropy from the last epoch, I'm wary of the current
> all-zero approach.  It seems like there are at least two other approaches
> available:
>
> a. "Public init secret" - Alongside the regular init secret, derive a
> "public init secret" from the key schedule.  Then use this as the init
> secret for external commits.
>
> b. "Init with KEM" - You could generate a key pair off of the key
> schedule, use some KEM-based operations to derive the next init secret.  In
> the early days of MLS, we used DH for this.  Nowadays, we're KEM-only, but
> I think the HPKE exporter might be pressed into serving a similar purpose.
>
> Looking forward to the discussion...
>
> --RLB
>
>
> On Tue, Sep 22, 2020 at 9:24 AM Joel Alwen <[e-mail]> wrote:
>
>> My initial 2 cents: this is not just a corner case. MLS should specify
>> how to
>> support such functionality but as an optional mode and making explicit
>> the price
>> in security it entails.
>>
>>
>> I believe such a feature would be used quite a bit if it where available.
>> E.g.
>> My phone is the only device on my account. It breaks. I get a new one and
>> log
>> back in to my account. Now I want my re-join my old groups. In most
>> deployments
>> I'd expect that to be permitted by group policies. But how can I re-join
>> w/o the
>> help of someone else in the group actively "pulling" me in? If I'm not
>> mistaken
>> then this PR provides an answer.
>>
>>
>> The solution does come with a price though. Some things that come to mind:
>>
>>  - It seems to require storing public group state on the DS (or some other
>> server) which isn't great for E2E metadata protection.
>>
>>  - An external commit provides weaker security guarantees than a normal
>> commit.
>> It throws out the old init_secret. Ergo, if ever an HPKE sk to which one
>> of the
>> UpdatePath secrets was encrypted to leaks then the entire application key
>> schedule of the new epoch is compromised. (Not to mention that further
>> epochs
>> may also be compromised depending on the particulars of the execution.)
>> For
>> normal commits that's not the case because the adv. also needs the old
>> epoch's
>> init_secret.
>>
>>
>> - Joël
>>
>> On 21/09/2020 20:15, Raphael Robert wrote:
>> > Hi all,
>> >
>> > Over the course of the past weeks when assessing how well MLS would fit
>> into existing messengers, it became obvious that adding new members is
>> still problematic. The operation – while technically asynchronous – still
>> requires two parties to be online in many cases.
>> >
>> > Rather than writing a lot of prose here, I attached a presentation that
>> explains the problem and offers a potential solution.
>> >
>> > I also created the following PR:
>> https://github.com/mlswg/mls-protocol/pull/406
>> > I will bring this up at the interim tomorrow for discussion.
>> >
>> > Raphael
>> >
>> >
>> > _______________________________________________
>> > MLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mls
>> >
>>
>> _______________________________________________
>> MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>