Re: [MLS] -mls-architecture: resolving encrypted group operations

I have a preference for #249. The idea that we are guilting people into
doing something hard or inefficient with this recommendation is not true.
Deploying MLS with encrypted handshake messages is actually easier! There
is less to do, fewer moving parts. Even if an application doesn't go "all
the way" by providing anonymity, handshake encryption still protects
metadata at-rest. And for the group sizes used by consumer-facing
messengers (~1000 max), the efficiency impact is minimal.

On Thu, Mar 14, 2024 at 3:08 AM Benjamin Beurdouche <ietf@beurdouche.com>
wrote:

> Hi,
>
> I have a preference for the other #249 which keeps the recommendation but
> I would be fine with either.
>
> My main reason is that, in the rest of the architecture document, the idea
> is to have the strongest
> security target possible as a recommandation and take explicit action to
> relax properties when needed.
>
> In that spirit I don’t see an issue with encrypting group operations even
> in the case you need server assist,
> the tradeoff being an additional ciphertext explicitly providing the
> information to the expected server
> and only that server…
>
> Ben
>
>
> > On 14 Mar 2024, at 04:56, Sean Turner <sean@sn3rd.com> wrote:
> >
> > Hi! Last we met, we talked about how to resolve the issue related to one
> of the encrypted group operation’s recommendations [1]; also, thanks to
> Brendan for starting this thread [2].  This thread is intended to help Nick
> and I call consensus on which of the two PRs to direct the authors to land.
> If it is not clear from this thread, we will discuss at our session at IETF
> 119.  The two PRs follow:
> >
> > 1. PR #246 [3] rewords the issue description and removes the
> recommendation; this change keeps us (the royal us) from looking silly when
> the first protocol to call out MLS does not follow the recommendation.
> >
> > 2. PR #249 [4] keeps recommendation but state that applications may use
> unencrypted operations if they have an explicit reason to.
> >
> > Cheers,
> > spt
> >
> > [1] https://github.com/mlswg/mls-architecture/issues/210
> > [2]
> https://mailarchive.ietf.org/arch/msg/mls/1ohlP2TZr_LBuLyM7rfDKnM9Jo8/
> > [3] https://github.com/mlswg/mls-architecture/pull/246
> > [4] https://github.com/mlswg/mls-architecture/pull/249
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>