Draft: draft-ietf-mls-protocol

Commentary: In , noted that the concatenation approach used to combine multiple PSKs is not well validated . At the 2021 - 10 - 04 interim , we discussed moving from this approach to a " cascaded HKDF " approach , with the idea of doing the same thing here as the main key schedule . This PR implements that suggestion . One nice implication of the algorithm here is that when there are no PSKs , it produces the zero vector as a degenerate case . So you could implement it pretty cleanly : 
 The spec currently does n't distinguish much between an external and a member commit w.r.t . how proposals by reference are handled . In theory , the server could keep track of proposals and send the external committer all proposals that were sent up until the time they want to commit externally . However , there are a few difficulties in committing proposals by reference in an external commit . Membership tags : The external committer does n't have the ability to verify membership tags on proposals . This is probably not a show - stopper , as proposals still need to be signed by a group member , but if nothing else , this should be noted in the spec . Leaf positioning : The spec was changed such that the committer is into the tree without an Add proposal being present . If there are other Add ( and Remove ) proposals present , it is unclear in what order they should be processed . Should the committer be when the path is processed ? Or should it still be processed as if it were an Add ? There are probably other things that can go wrong when committing referenced proposals externally , but those are the first that come to mind . The simplest solution would be to simply ignore proposals by reference , although this would break the current principle that a commit must always include all valid proposals that were sent during the epoch . The consequence would be that Parties that sent proposals will have to re - send them if the epoch is ended by an external commit . It should be noted , that a Preconfigured sender will have no way to detect if their proposal was committed or not . 
 I 'm not sure your worries here are very real : Membership tags : I do n't think the membership tag issue matters , because the existing members will reject the proposal ( and thus the commit ) if the membership tag is invalid ; at worst the joiner gets themselves wedged into a group by themselves . And as you say , they 're signed , and they keys can be tied back to the tree hash in the GroupInfo . Leaf positioning : We need to clear this up regardless of proposals - by - reference . It seems like basically having a synthetic Add at the beginning or end of the proposal list would work fine . Preconfigured proposer : This is a problem only when Commits are encrypted , so it 's not a problem in the external commit case ( since an external Commit can not be encrypted ) . Nonetheless , the point that an external joiner ca n't fully verify a Proposal seems to argue pretty strongly for forbidding proposals by reference . I do n't think this even violates the semantic of " include all valid proposals received in the epoch " , since ( 1 ) that requirement is receiver oriented ( it 's not enough for the proposals to have been sent ) and ( 2 ) the external joiner ca n't tell if the proposals or valid . Overall , I would lean slightly toward removing proposals by reference . And if we do that , it might even make sense to just define an ExternalCommit message that packages together the few things that are still allowed . 
 I 'm not sure I understand how the receiver - orientation of the " all valid proposals must be included " rule matters to its application to this case . If we remove the requirement for external commits to include proposals by reference and do n't soften that rule to exclude external commits , receivers will consider all external commits invalid in the presence of valid pending proposals by reference . In any case , I 'm also in favor of keeping it simple and restrict the External Commit to a few , well defined components that do not include any proposals by reference . 
 Discussion on working call : " No proposals by reference " kind of follows from " all valid proposals " , since the joiner ca n't necessarily determine that proposals are valid Maybe allow attempts ? Might not get feedback to retry , though . Whole point of external commit is to allow async . Agreement to prohibit proposals by reference in external Commit 
 I believe there 's a small mismatch between the text and the Key Schedule figure . The text says that if there are no PSK proposals , the should be a zero - length string , while the Key Schedule figure seems to indicate that it 's a string of zeros of length . 
 Fixed in 
 One brief comment , otherwise looks good !
Paragraph (version A):
The "index" field in "PSKLabel" corresponds to the index of the PSK
in the "psk" array, while the "count" field contains the total number
of PSKs.
Paragraph (version B):
In particular, if there are no PreSharedKey proposals in a given
Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all-
zero vector.
Paragraph (version A):
If one or more PreSharedKey proposals are part of the commit,
derive the "psk_secret" as specified in pre-shared-keys, where the
order of PSKs in the derivation corresponds to the order of
PreSharedKey proposals in the "proposals" vector.  Otherwise, set
"psk_secret" to a zero-length octet string.
Paragraph (version A):
If the "proposals" vector contains any PreSharedKey proposals,
derive the "psk_secret" as specified in pre-shared-keys, where the
order of PSKs in the derivation corresponds to the order of
PreSharedKey proposals in the "proposals" vector.  Otherwise, set
"psk_secret" to 0.