Re: [MLS] Fwd: New Version Notification for draft-kiefer-mls-light-00.txt

[Brendan McMillion <[e-mail]>]

Hi Richard, below are some notes I had while reading

# 6. Tree Slices

This section mentions that parent hashes are verified in TreeSlices. I
believe the parent hash construction only provides security if all of the
parent hashes can be verified at once. But this may not be an issue as long
as light clients don't indicate that someone is a member of a group until
they've actually received a message from that person. In which case, parent
hashes could just be ignored.

# 7. Light MLS

The tree_info and light_path_secret extensions are not registered in
section 11.2.

I'm also confused how light_path_secret could be an extension of GroupInfo,
if GroupInfo is signed by the group member, but LightCommit is constructed
by the DS specifically for one user?

# 7.1.2. Processing a Light Commit

Why do you send LightCommits with a broken signature, instead of using a
preconfigured external sender belonging to the DS?

# 7.2. Light MLS Extension

What is the purpose of specifying the upgrade modes? Is there a problem
with allowing clients to upgrade/downgrade as they please?

Also I don't think LightMlsExtension needs to be in
`required_capabilities`, given that it is already in the GroupContext.

On Mon, Mar 4, 2024 at 11:59 AM Richard Barnes <[e-mail]> wrote:

> Hi MLS folks,
>
> A few of us have been discussing how we can make MLS faster and easier for
> lightweight clients, or normal clients participating in giant groups.  This
> draft captures an initial proposal in that direction.
>
> The core idea is to trade off authentication for speed: Allow clients to
> join a group and participate without downloading and validating the ratchet
> tree.  Obviously, such a client won't know the entire membership of the
> group, and they won't be able to commit.  But as long as they know the tree
> hash, they can validate log-sized proofs of membership for any given member
> (e.g., themselves or the member who added them).  And with a little help
> from the DS, they can process Commits and keep up with the group.
>
> This obviously makes some interesting changes from a security analysis
> point of view.  In addition to the authentication changes noted above,
> allowing light clients to process Commits requires some changes to Commit
> validation.  Karthik and Franziskus have already done some modeling on
> this, and there are some notes in the document.
>
> Feedback very much welcome, happy to discuss here or in Brisbane!
>
> Best,
> --Richard
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Mar 4, 2024 at 2:52 PM
> Subject: New Version Notification for draft-kiefer-mls-light-00.txt
> To: Richard L. Barnes <[e-mail]>, Joël Alwen <[e-mail]>,
> Franziskus Kiefer <[e-mail]>, Karthikeyan Bhargavan <
> [e-mail]>, Marta Mularczyk <[e-mail]>
>
>
> A new version of Internet-Draft draft-kiefer-mls-light-00.txt has been
> successfully submitted by Richard L. Barnes and posted to the
> IETF repository.
>
> Name:     draft-kiefer-mls-light
> Revision: 00
> Title:    Light Clients for MLS
> Date:     2024-03-04
> Group:    Individual Submission
> Pages:    17
> URL:      https://www.ietf.org/archive/id/draft-kiefer-mls-light-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-kiefer-mls-light/
> HTML:     https://www.ietf.org/archive/id/draft-kiefer-mls-light-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-kiefer-mls-light
>
>
> Abstract:
>
>    The Messaging Layer Security (MLS) protocol provides efficient
>    asynchronous group key establishment for large groups with up to
>    thousands of clients.  In MLS, any member can commit a change to the
>    group, and consequently, all members must download, validate, and
>    maintain the full group state which can incur a significant
>    communication and computational cost, especially when joining a
>    group.
>
>    This document defines Light MLS, an extension that allows for "light
>    clients".  A light client cannot commit changes to the group, and
>    only has partial authentication information for the other members of
>    the group, but is otherwise able to participate in the group.  In
>    exchange for these limitations, a light client can participate in an
>    MLS group with significantly lower requirements in terms of download,
>    memory, and processing.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>