Draft: draft-ietf-mls-architecture

Commentary: I think the spirit of this change is good , but the last two sentences are confusing talking about the client trying to join and an existing member trying to prevent them from seeing anything confidential after joining . My initial reaction to this idea was always that post - hoc removing someone who should never have joined is a terrible architectural decision . Post - hoc removal either allows an undesirable member a window to see messages sent by some members , or it requires consistent policy across members . If there is consistent policy across members the members should simply treat the Commit from the undesirable client as invalid . Rather than further condone post - hoc removal ( which does n't require any normative change to the MLS protocol ) , why not just delete mentions of post - hoc removal ? 
 Compromise - Deleted the sentence that talks about the security implications of post - hoc removal , left the mention of it simply being possible . 
 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 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.  Both types of joins
are done via a Commit message, which could be blocked by the DS or
rejected by clients if the join is not authorized.  The former
approach requires that Commits be visible to the DS; the latter
approach requires that clients all share a consistent policy.  In the
unfortunate event that an unauthorized member is able to join, MLS
enables any member to remove them.