Re: [MLS] Federation and MLS

[Emad Omara <[e-mail]>]

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

>
>
> ------------------------------
>
> *De: *"Emad Omara" <[e-mail]>
> *À: *"Harry Halpin" <[e-mail]>
> *Cc: *"mls" <[e-mail]>
> *Envoyé: *Lundi 25 Mars 2019 17:36:06
> *Objet: *Re: [MLS] Federation and MLS
>
> 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.
>
>
> In terms of the MLS, it seems either doing it at establishment of the
> group or in a 'federation handshake' for federating an initially
> not-federated group is needed, where this 'federation handshake' that
> establishes the versioning and keeps track of which DS manages which
> 'sub-tree' would be the way to go, with the DS being kept abstract. Also, a
> more complete concurrency story would be needed, as concurrency issues
> could become much worse in federation of course.
>
> Yea concurrency is going to be tricky as we can't relay on the assist
approach!

> Outside of crypto, agreed , although in practice if we want 'open-ended'
> federation the application-specific details would need a minimal spec. Not
> sure if people actually want this, I'd see how the WG in Prague feels.
>
>
> 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?
>
> That would be ideal and the most elegant.
>
> What else besides ciphersuite would be needed for a version?  If there is
> *no* options in terms of crypto, then nothing other than ciphersuite would
> work - but are we imagining (as the concurrency discussion over elliptic
> curves brings up?) that there may be different ciphersuites?
>
Well, I was thinking of if in MLS V2 (or 1.1) we replaced TreeKem with a
different structure, in this case ciphersuites and version are orthogonal
(as in TLS version and ciphersuites),

>
> If there are various 'options' that touch the crypto, such as different
> signature schemes (i.e. deniability), then it seems that would be
> important, as well as a generic 'metadata' bucket. However, again, this
> opens one to ciphersuite negotiation attacks if not done right in the
> federation handshake or establishment.
>
> Overall, specifying *less* is always the go if possible!
>
>
>>
>> 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
>>
>
>