Re: [MLS] Async Add

[Richard Barnes <[e-mail]>]

To expand on what I said on the call: My proposal would be that we use the
HPKE exporter function

https://github.com/cfrg/draft-irtf-cfrg-hpke/blob/master/draft-irtf-cfrg-hpke.md#secret-export-hpke-export

So the scheme you would end up with would be something like:

init_priv = KEM.DeriveKeyPair(erstwhile_init_secret)
enc, ctx = SetupBaseS(init_priv.public_key, "") // on the send side
ctx = SetupBaseR(enc, init_priv, "") // on the receive side
init_secret = ctx.Export("mls 1.0 init", secret_size)

That "enc" value is the additional data that needs to be conveyed from the
sender to the receivers.  I'm sympathetic to Brendan's argument that if
this is good enough, we should just do it all the time.  What is missing
for me is an understanding of how the following two transformations relate:

epoch_secret --DeriveSecret-> init_secret
epoch_secret --DeriveSecret-> erstwhile_init_secret --DeriveKeyPair->
init_priv --SetupBase{skE},Export-> init_secret

(Aside from the latter involving a lot more steps!) Either way you have
transformed one secret to another; in the latter case, it is also available
to whomever holds skE.

--RLB



On Tue, Sep 22, 2020 at 11:09 AM Brendan McMillion <[e-mail]>
wrote:

> 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
>>
>