Draft: draft-ietf-mls-architecture

Commentary: Thanks both , I 'll have a look today . 
 Looks good ! Thanks  ! 
 The architecture document mentions PSKs in several places , but does not discuss the security of them . Nor does it discuss the security of External Proposals and External Commits . Notably , the third paragraph of 5.1 Membership Changes says " … the set of devices controlled by the user can only be altered by an authorized member of the group . " The set of devices could be altered via an External Commit by a non - member . At the end of 5.2 Parallel Groups there is a vague mention of " using the PSK mechanism to link healing properties among parallel groups . " , but no discussion of the security . Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed . External Proposals and External Commits should be discussed in section 5.4 Access Control . 
 I fixed the specific problems you note in
Membership of an MLS group is the managed at the level of individual
clients.  In most cases, a client corresponds to a specific device
used by a user.  If a user has multiple devices, the user will be
represented in a group by multiple clients.  If an application wishes
to implement operations at the level of users, it is up to the
application to track which clients belong to a given user and ensure
that they are added / removed consistently.
Membership of an MLS group is managed at the level of individual
clients.  In most cases, a client corresponds to a specific device
used by a user.  If a user has multiple devices, the user will be
represented in a group by multiple clients.  If an application wishes
to implement operations at the level of users, it is up to the
application to track which clients belong to a given user and ensure
that they are added / removed consistently.
Applications may use the PSK mechanism to link healing properties
among parallel groups.  For example, suppose a common member M of two
groups A and B has performed a key update in group A but not in group
B.  The key update provides PCS with regard to M in group A.  If a
PSK exported from group A and injected into group B, then some of
these PCS properties carry over to group B, since the PSK and secrets
derived from it are only known to the new, updated version of M, not
to the old, possibly compromised version of M.
Applications may use the PSK mechanism to link healing properties
among parallel groups.  For example, suppose a common member M of two
groups A and B has performed a key update in group A but not in group
B.  The key update provides PCS with regard to M in group A.  If a
PSK is exported from group A and injected into group B, then some of
these PCS properties carry over to group B, since the PSK and secrets
derived from it are only known to the new, updated version of M, not
to the old, possibly compromised version of M.
There are a few practical challenges to this approach.  For example,
the application will need to ensure that the new members have the
required PSK, including any new members that have joined the group
since the epoch in which the PSK was issued.
There are a few practical challenges to this approach.  For example,
the application will need to ensure that all members have the
required PSK, including any new members that have joined the group
since the epoch in which the PSK was issued.