Subject: [MLS] Federation and MLS

From: Harry Halpin <[email-masked]>
Date: Mon, 25 Mar 2019 16:31:16 +0100 (CET)

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. 

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. 

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. 

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

---

From: Emad Omara <[email-masked]>
Date: Mon, 25 Mar 2019 09:36:06 -0700

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 <[email-masked]> wrote:

> 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

> 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:
> 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
>
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Harry Halpin <[email-masked]>
Date: Mon, 25 Mar 2019 17:53:17 +0100 (CET)

> De: "Emad Omara" <[email-masked]>
> À: "Harry Halpin" <[email-masked]>
> Cc: "mls" <[email-masked]>
> 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:[email-masked] |
> [email-masked] ] > wrote:

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

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

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

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

>> [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
>> ]
>> [ mailto:[email-masked] | [email-masked] ]
>> [ https://www.ietf.org/mailman/listinfo/mls |
>> https://www.ietf.org/mailman/listinfo/mls ]

---

From: Emad Omara <[email-masked]>
Date: Mon, 25 Mar 2019 15:06:22 -0700

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

>
>
> ------------------------------
>
> *De: *"Emad Omara" <[email-masked]>
> *À: *"Harry Halpin" <[email-masked]>
> *Cc: *"mls" <[email-masked]>
> *Envoyé: *Lundi 25 Mars 2019 17:36:06
> *Objet: *Re: [MLS] Federation and MLS
>
> 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.
>
>
> 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.
>
>> 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.
>>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Mar 2019 09:39:16 +0100

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

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Mar 2019 09:51:32 +0100

> The typical IETF path is via .well-known [1] or related 'host-meta' [2]

Lets be careful not to tie MLS capability negotiation to the webpki tho.

OpenID Connect made this mistake and some communities (eg Mobile Connect
and the R&E community) had to monkey-patch it.

	Cheers LEif

---

From: Benjamin Beurdouche <[email-masked]>
Date: Tue, 26 Mar 2019 09:58:11 +0100

Hi all,

> On Mar 26, 2019, at 9:39 AM, Leif Johansson <[email-masked]> wrote:
> 
> 
>>    3) Metadata:
>> 

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

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Mar 2019 10:19:37 +0100

Skickat från min iPhone

> 26 mars 2019 kl. 09:58 skrev Benjamin Beurdouche <[email-masked]>:
> 
> Hi all,
> 

Thx that makes it clear for me!

---

From: Harry Halpin <[email-masked]>
Date: Tue, 26 Mar 2019 13:44:30 +0100 (CET)

----- Mail original -----
> De: "Benjamin Beurdouche" <[email-masked]>
> À: "Leif Johansson" <[email-masked]>, "Harry Halpin" <[email-masked]>, "Emad Omara" <[email-masked]>
> Cc: "mls" <[email-masked]>
> Envoyé: Mardi 26 Mars 2019 09:58:11

> trustworthiness of the application to convey those informations properly to the

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.