Re: [MLS] Federation and MLS

[Harry Halpin <[e-mail]>]

----- Mail original -----
> De: "Benjamin Beurdouche" <[e-mail]>
> À: "Leif Johansson" <[e-mail]>, "Harry Halpin" <[e-mail]>, "Emad Omara" <[e-mail]>
> Cc: "mls" <[e-mail]>
> Envoyé: Mardi 26 Mars 2019 09:58:11
> Objet: Re: [MLS] Federation and MLS

> 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.

Yes, that would work well, if we wish to tie this particular metadata to the cryptographic protocol. 

Regardless, I think after the IETF meeting this week, if there is consensus on pursuing federation, then we could move this conversation to git issues. However, I thought it might be useful to get a 'barometer' of how people want to approach the issue, and I strongly side with minimalism.  I think for MLS keeping things not relevant to the cryptographic protocol, as Ehad put it, is definitely the right approach for the core architecture.

However, for MLS to be used/replace XMPP as a the IETF chatting environment of choice in an "open" setting, then we would need bindings to JSON (and even XMPP if needed). These documents could not be standards track and be outside of the Working Group, but would be useful for implementers, particularly if there ends up being test-suites. 


> 
> Benjamin