Re: [MLS] Federation and MLS

[Harry Halpin <[e-mail]>]

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

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 < [ mailto:[e-mail] |
> [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? 

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 |
>> 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 | https://tools.ietf.org/html/rfc5785
>> ]
>> [2] [ https://tools.ietf.org/html/rfc6415 | https://tools.ietf.org/html/rfc6415
>> ]
>> _______________________________________________
>> MLS mailing list
>> [ mailto:[e-mail] | [e-mail] ]
>> [ https://www.ietf.org/mailman/listinfo/mls |
>> https://www.ietf.org/mailman/listinfo/mls ]