Draft: draft-ietf-mls-protocol

Commentary: This PR addresses two outstanding issues with Welcome messages : messages were not encrypted for the new member , so that the information in them ( in particular , init secrets ) were not appropriately protected . protocol overview had not been updated to include the Welcome - based add flow . 
 This was resolved in , but recording it in this issue for posterity . A Welcome message carries the value for the group , and so it needs to be encrypted for the new joiner . The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext , and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message .
Paragraph (version A):
When a participant A wants to establish a group with B and C, it
first downloads InitKeys for B and C.  It then initializes a group
state containing only itself and uses the InitKeys to compute Add
messages to add B and C, in a sequence chosen by A.  These messages
are broadcasted to the Group, and processed in sequence by B and C.
Messages received before a participant has joined the group are
ignored.  Only after A has received its Add messages back from the
server does it update its state to reflect their addition.
Paragraph (version B):
When a participant A wants to establish a group with B and C, it
first downloads InitKeys for B and C.  It then initializes a group
state containing only itself and uses the InitKeys to compute Welcome
and Add messages to add B and C, in a sequence chosen by A.  The
Welcome messages are sent directly to the new members (there is no
need to send them to the group).  The Add messages are broadcasted to
the Group, and processed in sequence by B and C.  Messages received
before a participant has joined the group are ignored.  Only after A
has received its Add messages back from the server does it update its
state to reflect their addition.
Paragraph (version A):
A UserInitKey object specifies what ciphersuites a client supports,
as well as providing public keys that the client can use for key
derivation and signing.  The client's identity key is intended to be
stable throughout the lifetime of the group; there is no mechanism to
change it.  Init keys are intended to be used a very limited number
of times, potentially once. (see init-key-reuse).
Paragraph (version B):
A UserInitKey object specifies what ciphersuites a client supports,
as well as providing public keys that the client can use for key
derivation and signing.  The client's identity key is intended to be
stable throughout the lifetime of the group; there is no mechanism to
change it.  Init keys are intended to be used a very limited number
of times, potentially once. (see init-key-reuse).  UserInitKeys also
contain an identifier chosen by the client, which the client MUST
assure uniquely identifies a given UserInitKey object among the set
of UserInitKeys created by this client.
Paragraph (version B):
The Welcome message contains the information that the new member
needs to initialize a GroupState object that can be updated to the
current state using the Add message.  This information is encrypted
for the new member using ECIES.  The recipient key pair for the ECIES
encryption is the one included in the indicated UserInitKey,
corresponding to the indicated ciphersuite.