Draft: draft-ietf-mls-protocol

Commentary: In we changed from using full - size hash references to using truncated hashes . This is fine for cases where the reference is only acting as a reference , so unambiguous identification is the only concern . For proposal references , however , the hash - based reference is also the way that the proposal is incorporated into the transcript . In this case , we end up with a looser binding with truncated hashes , since a malicious transcript need only match a subset of the bits of the hash . This does n’t seem like a huge issue in practice , since if the hash function is broken enough to allow 128 - bit collisions , we likely have deeper problems . But it might mean that transcript integrity fails before other aspects of the protocol . To fix this , we could either restore all hash - based identifiers to full size ( basically , revert ) , or we could revert just the proposal references . The former would be more uniform ; the latter would be more parsimonious . I ’m pretty ambivalent between the two . 
 Virtual interim 2022 - 05 - 19 : Support for doing something here , given 64 - bit birthday bound on collisions given 128 bit identifiers Support for full - width everywhere 
 Right now , we use hash - based identifiers to reference KeyPackages ( e.g. , in  ) and Proposals ( ProposalOrRef ) . To avoid truncating hashes , we use full - sized hashes , which are ( a ) much larger than necessary and ( b ) vary in size depend on the ciphersuite . We should consider moving toward hash - identifiers that are of a fixed size just long enough to make collisions negligible ( say 128 bits , like a UUID ) . A rough proposal : 
 There 's a KeyPackageID ( 7.1 . Key Package IDs ) and a KeyPackage Identifiers ( 7.4 . KeyPackage Identifiers ) right now . This is pretty confusing and probably not necessary . As far as I can tell the only difference is that the  has to be unique within a group . If we add this restriction to the KeyPacakge Identifier , for example by adding the key package hash , we could get rid of the  and the confusion . 
 IMO there is a useful distinction here . The KeyPackage identifier extension is application provided , and can contain something more / differently useful than just a hash . In I renamed  to KeyPackageRef , which should help ? 
 Fair enough . The description is certainly better than the and avoids confusion .
Paragraph (version B):
For a KeyPackageRef, the "value" input is the encoded KeyPackage, and
the ciphersuite specified in the KeyPackage determines the KDF used.
For a ProposalRef, the "value" input is the MLSPlaintext carrying the
proposal, and the KDF is determined by the group's ciphersuite.
Paragraph (version A):
This value is the hash of the KeyPackage, using the hash indicated by
the "cipher_suite" field.  KeyPackage hashes are used in a Welcome
message to indicate which KeyPackage is being used to include the new
member.  Since members of a group are uniquely identified by their
leaf KeyPackages, messages within a group use the hash of this key
package to refer to group members, e.g., to specify the target of a
Remove proposal or the signer of an MLSPlaintext.
Paragraph (version A):
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the KeyPackageID indicated in the "sender"
field identifies a member of the group.
Paragraph (version B):
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the KeyPackageRef indicated in the
"sender" field identifies a member of the group.
Paragraph (version A):
A Remove proposal requests that the member with KeyPackageID
"removed" be removed from the group.
Paragraph (version B):
A Remove proposal requests that the member with KeyPackageRef
"removed" be removed from the group.
Paragraph (version A):
Each proposal covered by the Commit is included by a ProposalOrRef
value, which identifies the proposal to be applied by value or by
reference.  Proposals supplied by value are included directly in the
Commit object.  Proposals supplied by reference are specified by
including the hash of the MLSPlaintext in which the Proposal was
sent, using the hash function from the group's ciphersuite.  For
proposals supplied by value, the sender of the proposal is the same
as the sender of the Commit.  Conversely, proposals sent by people
other than the committer MUST be included by reference.
Paragraph (version B):
Each proposal covered by the Commit is included by a ProposalOrRef
value, which identifies the proposal to be applied by value or by
reference.  Proposals supplied by value are included directly in the
Commit object.  Proposals supplied by reference are specified by
including the hash of the MLSPlaintext in which the Proposal was sent
(see hash-based-identifiers).  For proposals supplied by value, the
sender of the proposal is the same as the sender of the Commit.
Conversely, proposals sent by people other than the committer MUST be
included by reference.
Paragraph (version A):
Verify the signature on the GroupInfo object.  The signature input
comprises all of the fields in the GroupInfo object except the
signature field.  The public key and algorithm are taken from the
credential in the leaf node of the member with KeyPackageID
"signer".  If there is no matching leaf node, or if signature
verification fails, return an error.
Paragraph (version B):
Verify the signature on the GroupInfo object.  The signature input
comprises all of the fields in the GroupInfo object except the
signature field.  The public key and algorithm are taken from the
credential in the leaf node of the member with KeyPackageRef
"signer".  If there is no matching leaf node, or if signature
verification fails, return an error.
Paragraph (version A):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the node index "index"
and of the node index of the member with KeyPackageID
"GroupInfo.signer".  Set the private key for this node to the
private key derived from the "path_secret".
Paragraph (version B):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the node index "index"
and of the node index of the member with KeyPackageRef
"GroupInfo.signer".  Set the private key for this node to the
private key derived from the "path_secret".