Draft: draft-ietf-mls-protocol

Commentary: Interim 2022 - 05 - 26 : Intended to be mostly editorial Leaving open for now Clear to merge in between meetings if folks are comfortable 
 Interim 2022 - 06 - 02 : Still clear from last week 
 The generation numbers should be increased sequentially , gaps should be avoided to avoid unnecessary expensive operations on clients . Clients might also abort if the gap is too large to prevent attacks from malicious insiders . 
 This is stated in 10.1 : 
 I suspect that what  is worried about is that a malicious insider ( someone in possession of the ) could make an MLSCiphertext with set to that would cause the receiver to do HKDF invocations . The attacker does n't have to incur this cost because they do n't need to generate the required key -- the ciphertext can be garbage because the key generation happens before the decryption does . It seems like we could use a paragraph at the end of covering this and the fact that if you want to allow for out - of - order messages , you need to keep the intermediate keys . Since big gaps would force you to store the keys as well as doing the hashing . A figure here might also be helpful . 
 Couple of friendly amendments , otherwise lgtm . I am going to hold this as slightly more than editorial , given the number of MUSTs that are affected . But I would note for others that the MUSTs that are removed here are all redundant with requirements above . Thanks for picking this up ! Just one nit , but looks good otherwise .
Paragraph (version A):
The primary purpose of the Handshake protocol is to provide an
authenticated group key exchange to clients.  In order to protect
Application messages sent among the members of a group, the
Application secret provided by the Handshake key schedule is used to
derive nonces and encryption keys for the Message Protection Layer
according to the Application Key Schedule.  That is, each epoch is
equipped with a fresh Application Key Schedule which consist of a
tree of Application Secrets as well as one symmetric ratchet per
group member.
Paragraph (version A):
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 A):
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 A):
The group members MUST use the AEAD algorithm associated with the
negotiated MLS ciphersuite to AEAD encrypt and decrypt their
Application messages according to the Message Framing section.
Paragraph (version A):
The group identifier and epoch allow a recipient 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 identify
the member's symmetric ratchet from the initial group Application
secret.  The application generation field is used to determine how
far into the ratchet to iterate in order to reproduce the required
AEAD keys and nonce for performing decryption.
Paragraph (version A):
Application messages SHOULD be padded to provide some resistance
against traffic analysis techniques over encrypted traffic.  CLINIC
HCJ16 While MLS might deliver the same payload less frequently across
a lot of ciphertexts than traditional web servers, it might still
provide the attacker enough information to mount an attack.  If Alice
asks Bob: "When are we going to the movie ?" the answer "Wednesday"
might be leaked to an adversary by the ciphertext length.  An
attacker expecting Alice to answer Bob with a day of the week might
find out the plaintext by correlation between the question and the
length.
Paragraph (version B):
The primary purpose of handshake messages are to provide an
authenticated group key exchange to clients.  In order to protect
application messages sent among the members of a group, the
"encryption_secret" provided by the key schedule is used to derive a
sequence of nonces and keys for message encryption.  Every epoch
moves the key schedule forward which triggers the creation of a new
secret tree, as described in secret-tree, along with a new set of
symmetric ratchets of nonces and keys for each member.
Paragraph (version B):
Each client maintains their own local copy of the 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):
The group identifier and epoch allow a recipient to know which group
secrets should be used and from which "epoch_secret" to start
computing other secrets.  The sender identifier and content type is
used to identify which symmetric ratchet to use from the secret tree.
The "generation" counter determines how far into the ratchet to
iterate in order to produce the required nonce and key for encryption
or decryption.
Paragraph (version B):
Application messages MAY be padded to provide some resistance against
traffic analysis techniques over encrypted traffic CLINIC HCJ16.
While MLS might deliver the same payload less frequently across a lot
of ciphertexts than traditional web servers, it might still provide
the attacker enough information to mount an attack.  If Alice asks
Bob "When are we going to the movie?", then the answer "Wednesday"
could be leaked to an adversary solely by the ciphertext length.
Paragraph (version A):
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead-
limits.
Paragraph (version B):
During each epoch, senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead-
limits.
Paragraph (version A):
Since each Application message contains the group identifier, the
epoch and a message counter, a client can receive messages out of
order.  If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material clients
can decrypt these messages.
Paragraph (version A):
For usability, MLS clients might be required to keep the AEAD key and
nonce for a certain amount of time to retain the ability to decrypt
delayed or out of order messages, possibly still in transit while a
decryption is being done.
Paragraph (version B):
Since each application message contains the group identifier, the
epoch, and a generation counter, a client can receive messages out of
order.  When messages are received out of order, the client moves the
sender ratchet forward to match the received generation counter.  Any
unused nonce and key pairs from the ratchet are potentially stored so
that they can be used to decrypt the messages which were delayed or
reordered.
Paragraph (version B):
Applications SHOULD define a policy on how long to keep unused nonce
and key pairs for a sender, and the maximum number to keep.  This is
in addition to ensuring that these nonce and key pairs are promptly
deleted when the epoch ends.  Applications SHOULD also define a
policy limiting the maximum number of steps that clients will move
the ratchet forward in response to a new message.  Messages received
with a generation counter that's too much higher than the last
message received would then be rejected.  This avoids causing a
denial-of-service attack by requiring the recipient to perform an
excessive number of key derivations.  For example, a malicious group
member could send a message with "generation = 0xffffffff" at the
beginning of a new epoch, forcing recipients to perform billions of
key derivations.