Re: [MLS] Federation and MLS

[Benjamin Beurdouche <[e-mail]>]

Hi all,

> On Mar 26, 2019, at 9:39 AM, Leif Johansson <[e-mail]> wrote:
> 
> 
>>    3) Metadata:
>> 
>>    In general, some sort of metadata will need to be shared, i.e.
>>    icons,  human readable user-names, group names. I would suggest that
>>    as this may be an application message that is simply be considered a
>>    non-cryptographic update. Any attempt to proscibe too much on this
>>    layer leads to endless bike-shedding and so should be avoided :)
>>    However, some minimal optional subset of metadata commonly used for
>>    chat could be useful, but rather than whiteboard it, it would be
>>    better to have each major MLS vendor that plans to support
>>    federation see what their common subset is with everyone else, and
>>    then just make a call that delivers just that as an MLS update. 
>> 
>> I think this will be up to the application  layer, MLS shouldn't care
>> about this.
> Won't this lead to spoofing-oportunities? Users will place trust in
> the the artifacts that are presented to them (names, icons etc) which
> means that in general such artifacts should be as tightly bound to keys
> as any properties tied to the user that are designed to be used by the
> protocol.


If I understand properly, Harry suggest to identify a subset of metadata that
should be sent inside the secure channel as a special messages and Emad
considers it should be up to the application on how to handle them.

I believe that I have an intermediate point of view on this:
I would be in favor of adding such considerations in the architecture document
with 
a section documenting the fact that some metadata that are privacy
relevant but not cryptographically relevant messages should be protected as
normal application messages in MLS and list which data usually requires such
protection. Once protected as a normal application message, it relies mostly on the
trustworthiness of the application to convey those informations properly to the UI.

Benjamin