Draft: draft-ietf-mls-protocol

Commentary: Update change log for draft-07 No conflicting PRs so I did break many lines that were too long . Fix a few minor editorial issues after merging the tree - based application key schedule .
Paragraph (version A):
For application messages, a chain of keys is derived for each sender
in a similar fashion.  This allows forward secrecy at the level of
application messages within and out of an epoch.  A step in this
chain (the second subscript) is called a "generation".
Paragraph (version A):
As before the value [sender] represents the index of the member that
will use this key to send, encoded as a uint32.
Paragraph (version A):
Senders MUST only use a given secret once and monotonically
increment the generation of their secret.  This is important to
provide Forward Secrecy at the level of Application messages.  An
attacker getting hold of a member specific Application Secret at
generation [N+1] will not be able to derive the member's
Application Secret [N] nor the associated AEAD key and nonce.
Paragraph (version A):
Receivers MUST delete an Application Secret once it has been used
to derive the corresponding AEAD key and nonce as well as the next
Application Secret.  Receivers MAY keep the AEAD key and nonce
around for some reasonable period.
Paragraph (version A):
Receivers MUST delete AEAD keys and nonces once they have been
used to successfully decrypt a message.
Paragraph (version B):
For application messages, a chain of keys is derived for each sender
in a similar fashion.  This allows forward secrecy at the level of
application messages within and out of an epoch.  A step in this
chain (the second subscript) is called a "generation".  The details
of application key derivation are described in the astree section
below.
Paragraph (version A):
Each client maintains their own local copy of (parts of) the
Application Key Schedule for each epoch during which they are a group
member.  They derive new keys, nonces and secrets as needed while
deleting old ones as soon as they have been used.
Paragraph (version A):
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite.  Note that "Authenticated" in this context
does not mean messages are known to be sent by a specific client but
only from a legitimate member of the group.  To authenticate a
message from a particular member, signatures are required.  Handshake
messages MUST use asymmetric signatures to strongly authenticate the
sender of a message.
Paragraph (version A):
The Application schedule begins with the Application secrets which
are arranged in an "Application Secret Tree" or AS Tree for short; a
left balanced binary tree with the same set of nodes and edges as the
epoch's ratchet tree.  Each leaf in the AS Tree is associated with
the same group member as the corresponding leaf in the ratchet tree.
Nodes are also assigned an index according to their position in the
array representation of the tree (described in tree-math).  If N is a
node index in the AS Tree then left(N) and right(N) denote the
children of N (if they exist).
Paragraph (version B):
Each client maintains their own local copy of the Application Key
Schedule for each epoch during which they are a group member.  They
derive new keys, nonces and secrets as needed while deleting old ones
as soon as they have been used.
Paragraph (version B):
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite using the common framing mechanism.  Note
that "Authenticated" in this context does not mean messages are known
to be sent by a specific client but only from a legitimate member of
the group.  To authenticate a message from a particular member,
signatures are required.  Handshake messages MUST use asymmetric
signatures to strongly authenticate the sender of a message.
Paragraph (version B):
The application key schedule begins with the application secrets
which are arranged in an "Application Secret Tree" or AS Tree for
short; a left balanced binary tree with the same set of nodes and
edges as the epoch's ratchet tree.  Each leaf in the AS Tree is
associated with the same group member as the corresponding leaf in
the ratchet tree.  Nodes are also assigned an index according to
their position in the array representation of the tree (described in
tree-math).  If N is a node index in the AS Tree then left(N) and
right(N) denote the children of N (if they exist).
Paragraph (version A):
Note that fixing concrete values for GroupState_[n] and
application_secret completely defines all secrets in the AS Tree.
Paragraph (version B):
Note that fixing concrete values for GroupContext_[n] and
application_secret completely defines all secrets in the AS Tree.
Paragraph (version A):
It is important to delete all security sensitive values as soon as
they, or another value derived from them, is used for encryption or
decryption.
Paragraph (version B):
It is important to delete all security sensitive values S as soon as
they, or another value derived from them, is used for encryption or
decryption.
Paragraph (version A):
if a key, nonce or secret derived from S has been consumed.  (This
goes both for values derived via Derive-Secret and HKDF-Expand-
Label).
Paragraph (version B):
if a key, nonce or secret derived from S has been consumed.
Paragraph (version A):
During each epoch senders MUST NOT encrypt more messages than
permitted by the security bounds of the AEAD scheme used.
Paragraph (version B):
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used.