Draft: draft-ietf-mls-architecture

Commentary: WGLC comments to Functional Requirements Section : Include text for case when external joins are authorized by members autonomously Fix formatting of one RECOMMENDATION section Reference the mls - federation document ( informational ) 
 Following on from discussion in Even once a GroupInfo has been published to a prospective new joiner , there are still a few opportunities to apply authorization policy to the join : DS can block the external Commit from reaching the group members ( requires intelligent DS ) clients in the group can all refuse to apply the external Commit ( requires consistent policy ) client can remove the member after allowing them to join ( might expose some group comms to the joiner ) 
 Comment by This seems rather risky ? What could such a member do in the short time between getting and getting kicked ? Would they see message history ? Group membership ? How many devices a user has ? When members were last online ? Why support such a group type ? Would n't it be better to not support this and have an automated " special member " being a bot that handles member addition ? 
 Until someone else sends a message , a new joiner does n't learn anything non - public . If you think about it , how would they ? They 're outside the group before they send an external join , and the external join just establishes a new shared secret with the group for future communications . More specifically : Message history - MLS 's forward secrecy guarantees mean that new joiners do n't get message history . Group membership - This is public anyway via the GroupInfo that an external joiner needs to join How many devices - To the degree this is exposed , it would be in the group membership Last online - MLS does n't have any notion of this As for an " add me bot " , it 's a useful idea , but not applicable to a bunch of cases . The bot has to be a member of the group and has to be always - online . So now you have the group 's secrets on a server somewhere , instead of just in the communicating endpoints , already an additional point of compromise . And it ca n't be the DS 's server , since the whole point is to protect against the DS . 
 This statement in the draft is just plain wrong . In our implementation , we actually do validation of External joins at the application layer . I addressed this in ( dating from WGLC ) which says the following : " External joins do not allow for more granular authorization checks to be done before the new member is to the group , so if an application wishes to both allow external joins and enforce such checks , then either all the members of the group must all have the ability to check and reject invalid External joins autonomously , or the application needs to do such checks when a member joins and remove them if those checks fail . "
With both mechanisms, changes to the membership are initiated from
inside the group.  When members perform changes directly, this is
clearly the case.  External joins are authorized indirectly, in the
sense that a member publishing a GroupInfo object authorizes anyone
to join who has access to the GroupInfo object.  External joins do
not allow for more granular authorization checks to be done before
the new member is added to the group, so if an application wishes to
both allow external joins and enforce such checks, then the
application will need to do such checks when a member joins, and
remove them if checks fail.
With both mechanisms, changes to the membership are initiated from
inside the group.  When members perform changes directly, this is
clearly the case.  External joins are authorized indirectly, in the
sense that a member publishing a GroupInfo object authorizes anyone
to join who has access to the GroupInfo object.  External joins do
not allow for more granular authorization checks to be done before
the new member is added to the group, so if an application wishes to
both allow external joins and enforce such checks, then either all
the members of the group must all have the ability to check and
reject invalid External joins autonomously, or the application needs
to do such checks when a member joins and remove them if those checks
fail.
The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms
required for federation, multiple MLS implementations can
interoperate to form federated systems if they use compatible
authentication mechanisms, ciphersuites, and infrastructure
functionalities.
The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms
required for federation, multiple MLS implementations can
interoperate to form federated systems if they use compatible
authentication mechanisms, ciphersuites, application content, and
infrastructure functionalities.  Federation is described in more
detail in I-D.ietf-mls-federation.