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

Hi! As always I think privacy is terribly important and I think both PRs work towards that end. I have a slight preference for #246 because it actually recommends that “Applications that use unencrypted handshake messages may take additional steps to reduce the amount of metadata that is exposed to the intermediary”.

Raphael

> On 14. Mar 2024, at 14:14, Brendan McMillion <brendanmcmillion@gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:MLS@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/mls
>> 
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org <mailto:MLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mls
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls