Draft: draft-ietf-mls-protocol

Commentary: Comment by Citation needed ? I think most phones have AES(_GCM ) in hardware too ? Also compared to HPKE operations and the times for epoch / group reinit , does this performance really matter ? ( eg waking up from sleep to increment the epoch would make the symmetric encryption cost pretty irrelevant . I would remove this sentence . 
 I 'll remove the " mobile processors " bit and phrase it a little more evenhandedly ( " can choose ChaCha or GCM " ) , but I think it 's fair to say that there might be environments where ChaCha / Poly is more performant than AES - GCM . 
 Thanks . I do think you might be right that " there are " , but I also do not think " mobile " is that :) 
 Comment by This sentence with a hidden MUST is stuck between a sentence with MAY and a sentence with SHOULD . Perhaps make the MUST explicit ? 
 This is already well covered in the discussion , but I can add a cross - reference . 
 I meant just rephase the sentence so it contains " MUST delete when the epoch ends " 
 Comment by That is quite some information that must be publicly available to allow external Add requests . This leaks information , eg same epoch means the group membership did not change , etc etc . I hope this will appear in the Security Considerations later :) 
 I suppose between this and , we should add a subsection to the Security Considerations on metadata privacy . 
 I 'm not sure actually resolves this ? 
 Oops , that 's correct Had it in my notes among the others . 
 Comment by Is n't there technically also limits to how much one AEAD key and one nonce can be used to encrypt a ( very very ) large message ? I guess this could not happen , but is there some formal message size limit in MLS ? ( looking at the vectors at the start , limits could be higher than 2 ^ 64 ? ) 
 Comment by Another weird MAY here . Again , I would just lowercase it as this is just a pointer to a human decision , not a 2119 based protocol enforcement . 
 Comment by Figure 10 claims to have seven members , but I count 8 , namely Y , T , X , A , B , E , F and G ( not counting W , the root ) 
 Actually , it only has five ! A , B , E , F , and   that members are at the leaves of the tree . 
 Ah right :) 
 Comment by This MAY is super weird . Is it allowed to implement in such a way that they to NOT produce correct protocol messages ? :-) Remove the entire sentence or lowercase the MAY ? 
 Comment by What server ? The Delivery Service ? 
 Comment by Should this be " prospective member " or " invitee " ? They have n't joined yet , have they ? 
 From the perspective of the group , they are joined . Once the Commit adding the new member is processed and the new epoch starts , that member is able to access the group 's secrets . The only thing " provisional " about the membership is that the new member has n't initialized their local state . We use " new member " consistently to mean the subject of an Add proposal , and I do n't think this is a big enough distinction to merit more terminology . 
 Another way to look at it is that keying information from the new member is already incorporated into the group , therefore they are a member and not a provisional member . 
 Ah yes . Perhaps a single line explaining this at the quoted location could be useful , but is not required
Paragraph (version A):
create-flow shows how these prepublished KeyPackages are used to
create a group.  When a client A wants to establish a group with B
and C, it first initializes a group state containing only itself and
downloads KeyPackages for B and C.  For each member, A generates an
Add and Commit message adding that member, and broadcasts them to the
group.  It also generates a Welcome message and sends this directly
to the new member (there's no need to send it to the group).  Only
after A has received its Commit message back from the server does it
update its state to reflect the new member's addition.
Paragraph (version A):
Upon receiving the Welcome message, the new member will be able to
read and send new messages to the group.  However, messages sent
before they were added to the group will not be accessible.
Paragraph (version B):
create-flow shows how these prepublished KeyPackages are used to
create a group.  When a client A wants to establish a group with B
and C, it first initializes a group state containing only itself and
downloads KeyPackages for B and C.  For each member, A generates an
Add and Commit message adding that member, and broadcasts them to the
group.  It also generates a Welcome message and sends this directly
to the new member (there's no need to send it to the group).  Only
after A has received its Commit message back from the Delivery
Service does it update its state to reflect the new member's
addition.
Paragraph (version B):
Once A has updated its state, the new member has processed the
Welcome, and any other group members have processed the Commit, they
will all have consistent representations of the group state,
including a group secret that is known only to the members the group.
The new member will be able to read and send new messages to the
group, but messages sent before they were added to the group will not
be accessible.
Paragraph (version B):
It is up to the application to decide what "authenticated_data" to
provide and how much padding to add to a given message (if any).  The
overall size of the AAD and ciphertext MUST fit within the limits
established for the group's AEAD algorithm in [!I-D.irtf-cfrg-aead-
limits].
Paragraph (version A):
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.
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 secrets are deleted according to
the deletion schedule defined in deletion-schedule.  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.
Paragraph (version A):
It is advisable to keep the number of ciphersuites low to increase
the chances clients can interoperate in a federated environment,
therefore the ciphersuites only include modern, yet well-established
algorithms.  Depending on their requirements, clients can choose
between two security levels (roughly 128-bit and 256-bit).  Within
the security levels clients can choose between faster X25519/X448
curves and FIPS 140-2 compliant curves for Diffie-Hellman key
negotiations.  Additionally clients that run predominantly on mobile
processors can choose ChaCha20Poly1305 over AES-GCM for performance
reasons.  Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is
not paired with FIPS 140-2 compliant curves.  The security level of
symmetric encryption algorithms and hash functions is paired with the
security level of the curves.
Paragraph (version B):
It is advisable to keep the number of ciphersuites low to increase
the chances clients can interoperate in a federated environment,
therefore the ciphersuites only include modern, yet well-established
algorithms.  Depending on their requirements, clients can choose
between two security levels (roughly 128-bit and 256-bit).  Within
the security levels clients can choose between faster X25519/X448
curves and FIPS 140-2 compliant curves for Diffie-Hellman key
negotiations.  Clients may also choose ChaCha20Poly1305 or AES-GCM,
e.g., for performance reasons.  Since ChaCha20Poly1305 is not listed
by FIPS 140-2 it is not paired with FIPS 140-2 compliant curves.  The
security level of symmetric encryption algorithms and hash functions
is paired with the security level of the curves.