Change:
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 <del> 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. </del> <ins> 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. </ins> The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519

Discussion:
Comment by NAME 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 NAME 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 NAME 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 NAME Had it in my notes among the others.
Comment by NAME Isn'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 NAME 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 NAME 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 G. Recall that members are at the leaves of the tree.
Ah right :)
Comment by NAME 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 NAME What server? The Delivery Service ?
Comment by NAME Should this be "prospective member" or "invitee" ? They haven'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 hasn't initialized their local state. We use "new member" consistently to mean the subject of an Add proposal, and I don'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