Draft: draft-ietf-mls-protocol

Commentary: This PR is an alternative to . This PR updates the group creation process so that epoch 0 is a " full - fledged " epoch , with an epoch secret ( and all the derivatives ) instead of just an init secret . One implication of that is that the interim transcript hash can now be computed in the usual way , by extending the confirmed transcript hash with a confirmation tag : This has the nice side effect of immediately mixing the epoch secret into the transcript hash , helping the group diverge ( a concern raised on the call today ) . While I was editing the group creation section , I also rationalized the requirements a bit . One reason that came up is that the group creation section currently assumes you 're always starting with multiple members . So the MUST - level requirement to fetch key packages has been downgraded to a SHOULD . Finally , I updated the specification of GroupInfo to explain the fields , in particular explaining how you get the confirmation tag in epoch 0 or later epochs . 
 Since this PR clarifies more than and the solution is equally good , I 'd suggest closing and merging this one .
Paragraph (version A):
A group is always created with a single member, the "creator".  The
other members are added when the creator effectively sends itself Add
proposals, commits them, and then sends the corresponding Welcome
message to the new participants.  These processes are described in
detail in add, commit, and joining-via-welcome-message.
Paragraph (version A):
Fetch KeyPackages for the members to be added, and select a
version and ciphersuite according to the capabilities of the
members.  To protect against downgrade attacks, the creator MUST
use the "capabilities" information in these KeyPackages to verify
that the chosen version and ciphersuite is the best option
supported by all members.
Paragraph (version B):
A group is always created with a single member, the "creator".  Other
members are then added to the group using the usual Add/Commit
mechanism.
Paragraph (version B):
The creator of a group is responsible for setting the group ID,
ciphersuite, and initial extensions for the group.  If the creator
intends to add other members at the time of creation, then it SHOULD
Fetch KeyPackages for the members to be added, and select a
ciphersuite and extensions according to the capabilities of the
members.  To protect against downgrade attacks, the creator MUST use
the "capabilities" information in these KeyPackages to verify that
the chosen version and ciphersuite is the best option supported by
all members.
Paragraph (version A):
The recipient of a Welcome message processes it as described in
joining-via-welcome-message.
Paragraph (version B):
Derive the "confirmation_key" for the epoch as described in
key-schedule.
Paragraph (version B):
Compute a "confirmation_tag" over the empty
"confirmed_transcript_hash" using the "confirmation_key" as
described in content-authentication.
Paragraph (version B):
At this point, the creator's state represents a one-member group with
a fully initialized key schedule, transcript hashes, etc.  Proposals
and Commits can be generated for this group state just like any other
state of the group, such as Add proposals and Commits to add other
members to the group.  A GroupInfo object for this group state can
also be published to facilitate external joins.
Paragraph (version B):
Members other than the creator join either by being sent a Welcome
message (as described in joining-via-welcome-message) or by sending
an external Commit (see joining-via-external-commits).