Draft: draft-ietf-mls-protocol

Commentary: A couple of shortcomings to note on this PR : The joiner ca n't compute their private keys because they 're not told where they are in the tree or how big the tree is . The former should be to and the latter to . This approach assumes that the joiner gets the tree OOB before processing the Welcome , otherwise they ca n't verify the signature on the Welcome . ( Since Welcome presumes they get the credential for the signer from the tree . ) We could avoid the latter problem by including a credential for the signer and a " membership proof " comprising the hashes needed to tie that leaf to the tree hash in the Welcome . That could allow participants to remain " passive " ( without a full tree , just their private keys ) for longer , especially if such a proof could be provided on Commit as well . This might be a good candidate for an extension , though . 
 Discussion at the 2020 - 07 - 14 interim indicated that we should go ahead with this strategy , and just note the requirement that you have to get the tree before you process the Welcome . 
 I remember we discussed this in the past , but I do n't think we ever spec'ed this out fully : Right now the whole tree is part of ( which in turn is part of ) . This can grow quite big in large groups ( ~17 MB with 100k members with the MTI ) . The practical limitations are : The TLS representation of the tree is hard to parse efficiently ( no skipping and no a priori information of how many nodes are in the tree ) Out - of - band transmission ( like server assist ) is not possible Large messages like that are hard to handle on mobile devices , when they have to be downloaded in the background We should introduce an indirection , like a commit hash of the tree .
Paragraph (version A):
In the description of the tree as a list of nodes, the "key_package"
field for a node MUST be populated if and only if that node is a leaf
in the tree.
Paragraph (version B):
The client processing a Welcome message will need to have a copy of
the group's ratchet tree.  The tree can be provided in the Welcome
message, in an extension of type "ratchet_tree".  If it is sent
otherwise (e.g., provided by a caching service on the Delivery
Service), then the client MUST download the tree before processing
the Welcome.
Paragraph (version B):
Verify that the tree hash of the ratchet tree matches the
"tree_hash" field in the GroupInfo.
Paragraph (version B):
By default, a GroupInfo message only provides the joiner with a
commitment to the group's ratchet tree.  In order to process or
generate handshake messages, the joiner will need to get a copy of
the ratchet tree from some other source.  (For example, the DS might
provide a cached copy.)  The inclusion of the tree hash in the
GroupInfo message means that the source of the ratchet tree need not
be trusted to maintain the integrity of tree.
Paragraph (version B):
The presence of a "ratchet_tree" extension in a GroupInfo message
does not result in any changes to the GroupContext extensions for the
group.  The ratchet tree provided is simply stored by the client and
used for MLS operations.
Paragraph (version B):
If this extension is not provided in a Welcome message, then the
client will need to fetch the ratchet tree over some other channel
before it can generate or process Commit messages.  Applications
should ensure that this out-of-band channel is provided with security
protections equivalent to the protections that are afforded to
Proposal and Commit messages.  For example, an application that
encrypts Proposal and Commit messages might distribute ratchet trees
encrypted using a key exchanged over the MLS channel.
Paragraph (version A):
A client joining a group MUST populate the GroupContext extensions
with exactly the contents of the extensions field in the Welcome
message.  If any extension is unrecognized (i.e., not contained in
the corresponding KeyPackage), then the client MUST reject the
Welcome message and not join the group.
Paragraph (version B):
If any extension in a GroupInfo message is unrecognized (i.e., not
contained in the corresponding KeyPackage), then the client MUST
reject the Welcome message and not join the group.
Paragraph (version B):
The extensions populated into a GroupContext object are drawn from
those in the GroupInfo object, according to the definitions of
those extensions.