Draft: draft-ietf-mls-protocol

Commentary: This PR is updates  's changes with a few adjustments :  master ; Fix missing definition to derive key / nonce used for encryption of Handshake messages ; Delete the " removeconfirmation " function for simplicity . It has a very low cost anyway ;  to having the GID and the epoch in the clear , otherwise there is a need for a magic channel to communicate it to the recipient . We can eventually do it but this should be discussed seriously in Berlin ; Revert the masking of the content type , ( keeps masking for sender and generation ) otherwise it seem to force plaintext OR the Delivery Service to have access to the senderdata_secret . It seem impossible to only order Handshake messages otherwise . 
 Last call on this one . If I do n't hear from you by the morning ET , I 'm going to merge this . 
 Note that this PR will be pretty immediately updated by , which reverts the " masking " parts to use AEAD , in order to make analysis simpler for this revision .
Paragraph (version B):
We generally assume that each participant maintains a complete and
up-to-date view of the public state of the group's ratchet tree,
including the public keys for all nodes and the credentials
associated with the leaf nodes.
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".
Paragraph (version B):
As before the value [sender] represents the index of the member that
will use this key to send, encoded as a uint32.
Paragraph (version B):
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 B):
The two main structures involved are MLSPlaintext and MLSCiphertext.
MLSCiphertext represents a signed and encrypted message, with
protections for both the content of the message and related metadata.
MLSPlaintext represents a message that is only signed, and not
encrypted.  Applications SHOULD use MLSCiphertext to encode both
application and handshake messages, but MAY transmit handshake
messages encoded as MLSPlaintext objects in cases where it is
necessary for the delivery service to examine such messages.
Paragraph (version B):
The group identifier, epoch and content_type fields are copied from
the MLSPlaintext object directly.  The content encryption process
populates the ciphertext field of the MLSCiphertext object.  The
metadata encryption step populates the masked_sender_data field.
Paragraph (version B):
Decryption follows the same step in reverse: Unmasking the metadata,
then decrypting the content, then verifying the content signature.
Paragraph (version B):
The signature field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf in
the tree indicated by the sender field.  The signature covers the
MLSPlaintext object, with the signature field truncated.
Paragraph (version B):
The key and nonce used for this encryption depend on the content type
of the message.  The sender chooses a handshake key for a handshake
message or an ununsed generation from its (per-sender) application
key chain for the current epoch, according to the type of message
being encrypted.
Paragraph (version B):
The ciphertext field of the MLSCiphertext object is produced by
supplying these inputs to the AEAD function specified by the
ciphersuite in use.
Paragraph (version B):
When parsing a SenderData struct as part of message decryption, the
recipient MUST verify that the sender field represents an occupied
leaf in the ratchet tree.  In particular, the sender index value MUST
be less than the number of leaves in the tree.
Paragraph (version B):
Note that the serialization of this struct is always eight octets
long.  The mask is generated by combining the sender_data_secret for
the current epoch with the first Hash.length octets of the
ciphertext.  If the ciphertext is shorter than Hash.length octets,
then the whole ciphertext is used.  The first eight octets of the
derived mask are XORed with the serialized sender data, and the
result is the value of the masked_sender_data field in the
MLSCiphertext object.
Paragraph (version B):
This approach is similar to the one used for protection of header
information in QUIC (see Section 5.4 of I-D.ietf-quic-tls).  Note
that the sender data values are authenticated by the AEAD and the
signature, while the masked_sender_data is not and only benefit from
passive security because it depends on the ciphertext.
Paragraph (version A):
An MLS handshake message encapsulates a specific "key exchange"
message that accomplishes a change to the group state.  It also
includes a signature by the sender of the message over the GroupState
object representing the state of the group after the change has been
made.
Paragraph (version A):
Verify that the "prior_epoch" field of the Handshake message is
equal the "epoch" field of the current GroupState object.
Paragraph (version B):
Verify that the "epoch" field of enclosing MLSPlaintext message is
equal the "epoch" field of the current GroupState object.
Paragraph (version B):
Verify that the signature on the MLSPlaintext message verifies
using the public key from the credential stored at the leaf in the
tree indicated by the "sender" field.
Paragraph (version B):
Use the "confirmation_key" for the new epoch to compute the
confirmation MAC for this message, as described below, and verify
that it is the same as the "confirmation" field in the
GroupOperation object.
Paragraph (version A):
The Application context provided together with the previous
Application secret is used to bind the Application messages with the
next key and add some freshness.
Paragraph (version A):
Senders MUST only use the Application 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):
The length of the key being generated.
Paragraph (version A):
Note, that because the identity of the participant using the keys to
send data is included in the initial Application Secret, all
successive updates to the Application secret will implicitly inherit
this ownership.
Paragraph (version A):
All the traffic keying material is recomputed whenever the underlying
Application Secret changes.
Paragraph (version A):
The group identifier and epoch allow a device to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The sender identifier is used to derive the
member's Application secret chain from the initial group Application
secret.  The application generation field is used to determine which
Application secret should be used from the chain to compute the
correct AEAD keys before performing decryption.
Paragraph (version A):
The signature used in the ApplicationMessageContent is computed over
the SignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent group members from impersonating
other clients.  It is also necessary in order to prevent cross-group
attacks.
Paragraph (version B):
The group identifier and epoch allow a device to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The "sender" identifier is used to derive
the member's Application secret chain from the initial group
Application secret.  The application generation field is used to
determine which Application secret should be used from the chain to
compute the correct AEAD keys before performing decryption.