Re: [MLS] Proposal: Proposals (was: Laziness)

[Richard Barnes <[e-mail]>]

Just to confirm I understand, the key exchange protocol in this conception
would be something like, at each epoch:

1. KEM a secret to some set of people whom you believe to be the current
members of the group
2. Send that KEM'ed value out to the group together with a description of
the current membership
3. KDF the KEM'ed secret together with the prior epoch secret to get the
new epoch secret
4. Use the new epoch secret to generate a confirmation over the current
state of the group

Where the KEM in (1) would be something like TreeKEM or just "encrypt to a
list of public keys".  Then the proposals would just be a way for people to
sync up on who the current members of the group are (by leaf key).

The major thing I would be worried about in such a split is how it would
deal with authority over changes, which affect the authentication
properties of the protocol.  The current Proposals proposal maintains the
property that everyone agrees on the proposals and can verify that they
were proper, e.g., only the holder of a leaf can update that leaf.  If we
sever the connection between the proposals and the top-level transcript
entirely, then I'm not sure how you would continue to assure that, say, the
sender of a Commit didn't just swap out Joe's leaf key for the NSA.

I agree that there is degree of separation here (since, e.g., it's easy to
imagine swapping in a "list of keys" KEM for TreeKEM).  But it seems like a
fairly high degree of coupling is necessary to maintain authentication.

--Richard



On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan <
[e-mail]> wrote:

> Hello All,
>
> It seems to me that one way to think about “laziness” would be to cleanly
> separate the MLS key exchange into two different protocols.
> The first is a “classic” authenticated synchronization protocol where
> members of a group can create and modify a shared data structure (in this
> case, the group membership tree).
> The second is a novel key establishment protocol where some member of the
> group generates a fresh group secret that will be delivered only to the
> current members computed from the (current) group state.
> Currently the first and second protocols are tightly interleaved: every
> time the group data structure is modified by some member (or admin), that
> member must also generate and distribute the fresh group secret.
> The laziness proposal can be thought of as detaching the two protocols:
> the key establishment protocol can follow group modifications with some
> delay.
>
> So rather than trying to add “laziness” to the existing protocol, should
> we try to do this detachment in a principled way by defining two
> independent sub-protocols?
> It would have the advantage that we may be able to consider other designs
> for synchronization and key establishment, which may well be orthogonal
> concerns.
>
> In our model of MLS, we can already factor out the protocol in this way,
> but it makes the security invariants a bit harder to express in a
> user-friendly way.
> Still, I would prefer to compose proofs for simpler sub-protocols rather
> than try to prove security for a single complex protocol with lots of
> options.
>
> Best,
> -Karthik
>
>
> On 23 Aug 2019, at 10:48, Richard Barnes <[e-mail]> wrote:
>
>
>
> On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell <
> [e-mail]> wrote:
>
>>
>> Hiya,
>>
>> On 23/08/2019 15:10, Richard Barnes wrote:
>> >
>> > I'm not clear on what you mean by "meaningfully handled by members".
>> >
>>
>> I'm assuming that MLS protocol data will likely be
>> handled by a library. ISTM more likely that such a
>> library might default to, or be carelessly used to,
>> honor anything the server proposes if this is an MLS
>> protocol feature rather than an application layer
>> feature. That'd be an example of not meaningfully
>> handling this:-) We have seen similar kinds of
>> failure with applications and TLS libraries in the
>> past where certs aren't checked etc.
>>
>
> Oh I see.  That would actually be a pretty difficult policy to implement,
> at least without turning off authentication altogether, at least in the
> envisioned protocol.  By which I mean:
>
> - Right now, clients are expected to maintain a list of members' signing
> keys
> - So signers are just indicated by their index in that list
> - The obvious way to add non-member signers is to reserve a block of
> indices (say 0xFFFFFFxx) that can correspond to application-specific
> entities
> - Then clients need to get configured with which server keys go with which
> reserved indices
>
> Assuming we go in that direction, the natural, "I don't care about
> server-initiated stuff" library design would be to just not implement any
> special handling for those reserved indices, in which case you'll reject
> anything from the server.  I would expect a library that does anything else
> to have an API for the configuration required in the last point.
>
> The obvious screw-up case would be, "Treat a signature from the reserved
> block as trusted".  But that's actually a little hard to implement; because
> the public keys aren't provided, you would have to also not do any
> signature verification at all, which means you're now totally open to the
> world.  Hopefully that would raise some red flags for developers.
>
> So it's not impossible to screw up, but not trivial either.  At least if
> you want to maintain authentication for group members.  If you turn that
> off too, I don't think we can save you.
>
> --Richard
>
>
>
>>
>> I do accept the argument that it can happen at the
>> application layer if not defined in the MLS protocol,
>> but doing this kind of thing at the application layer
>> seems safer to me.
>>
>> It's also not clear to me that all MLS applications
>> would need this feature. (That may be true, I just
>> don't know.) If they don't, then again, it seems to
>> be more conservative to leave it to applications.
>>
>> I agree that there are sharp edges however this kind
>> of thing is done though.
>>
>> Cheers,
>> S.
>>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>
>
>