Re: [MLS] Federation and MLS

[Emad Omara <[e-mail]>]

Thanks Harry for the thoughts. Just to be clear, the federation effort is
mainly focused on the crypto layer, other application specific details are
left out of the scope of the draft.

On Mon, Mar 25, 2019 at 8:33 AM Harry Halpin <[e-mail]> wrote:

> Glad to see federation being discussed on Thursday as well - here's some
> thoughts:
>
> There are basically four issues that need to be solved, and the general
> philosophy should be one of minimalism.
>
> 1) Identity: How to identify members with different AS/DS?
>
> There have been large debates over this, ranging from "user@domain" to
> key-based identifiers to other odd new schemes. To keep it simple, this
> should be delegated to the Authentication Service to provide long-term
> identity (or per group) keys, but some minimal set of calls between the AS
> may need to standardized to retrieve a user key given an identifier.
> Attempting to standardize the identifier is probably a bad idea, just
> assume there is a string you can send the AS that returns a key. Thus, the
> "domain" is by default the "domain" of the AS you call, and all that is
> needed is a user identifier. This would work well for systems that may not
> have a clear user@domain architecture.
>
 Yes this completely out of the scope of the draft. UserID could be email,
phone number, etc depends on the application

>
> 2) Discovery: How to determine which capabilities a given MLS-compliant
> AS/DS supports?
>
> The typical IETF path is via .well-known [1] or related 'host-meta' [2]
> and the former seems to be having some usage. From a cryptographic
> perspective, this is also the 'versioning' issue - how to detect which MLS
> version is being used, for example, with what ciphersuite (as already we
> are discussing using non-25519 ciphers). However, the .well-known RFC is
> tied to the domain name system and so TLS etc, which may not fit all
> systems. Something even more minimalistic, in a 'federation handshake' to
> establish connections between AS and DS services and then cryptographically
> merge their respective sub-trees is a better way to go, although MLS could
> register a .well-known if needed.
>
Yes this one of the challenges,  how to trust the version number provided
by a different DS? Should we make it implicit from the cipher-suite
negotiation?

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

>
> 4) Transport:
>
> In general, it seems some minimal transport syntax would have to be agreed
> upon. A simple JSON syntax would match the rest of the Web, without any
> exotic additions.
>
>  All previous work that is non-minimalistic (and it seems my suggestions
> could become even more minimized) will lead to failure. For example, OAuth
> was a success insofar as it did not, unlike OpenID, specify too much. A
> large summary document I wrote over the last decade of failure of
> standardization in this space suggests this is the case, with OAuth being
> the only real victory, everything else from W3C Social Web effort to
> OpenSocial to a pleathora of 'identity' efforts all more or less failing to
> reach deployment, see:
> https://hal.inria.fr/hal-01966561/document
>
> Happy to see MLS focus on the crypto and not repeat the mistakes of
> previous standards efforts in federation - happy to help on federation
> topic, although I can't make Prague in person likely.
>
>   yours,
>     harry
>
>
> [1] https://tools.ietf.org/html/rfc5785
> [2] https://tools.ietf.org/html/rfc6415
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>