Code change:
14. This document requests the creation of the following new IANA <del> registries: MLS Ciphersuites All of these registries should be under a heading of "Message Layer Security", and administered under a Specification Required policy RFC8126. </del> <ins> registries: MLS Ciphersuites (mls-ciphersuites).  All of these registries should be under a heading of "Message Layer Security", and assignments are made via the Specification Required policy RFC8126. See de for additional information about the MLS Designated Experts (DEs). </ins> 14.1. <del> The "MLS Ciphersuites" registry lists identifiers for suites of cryptographic algorithms defined for use with MLS.  These are two- byte values, so the maximum possible value is 0xFFFF = 65535.  Values in the range 0xF000 - 0xFFFF are reserved for vendor-internal usage. Template: Value: The two-byte identifier for the ciphersuite Name: The name of the ciphersuite Reference: Where this algorithm is defined The initial contents for this registry are as follows: [[ Note to RFC Editor: Please replace "XXXX" above with the number assigned to this RFC. ]] </del> <ins> A ciphersuite is a combination of a protocol version and the set of cryptographic algorithms that should be used. Ciphersuite names follow the naming convention: Where VALUE is represented as two 8bit octets: This specification defines the following ciphersuites for use with MLS 1.0. The KEM/DEM constructions used for HPKE are defined by HPKE.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. 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 inlcude 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. The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS10_128_HPKE25519_AES128GCM_SHA256_Ed25519" which uses Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES- 128-GCM with Ed25519 for symmetric encryption and signatures. Values with the first byte 255 (decimal) are reserved for Private Use. New ciphersuite values are assigned by IANA as described in iana- considerations. 14.2. [[ OPEN ISSUE: pick DE mailing address.  Maybe mls-des@ or mls-de- pool. ]] Specification Required RFC8126 registry requests are registered after a three-week review period on the MLS DEs' mailing list: TBD@ietf.org [1], on the advice of one or more of the MLS DEs.  However, to allow for the allocation of values prior to publication, the MLS DEs may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the MLS DEs mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in MLS Bar registry"). Within the review period, the MLS DEs will either approve or deny the registration request, communicating this decision to the MLS DEs mailing list and IANA.  Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention for resolution using the iesg@ietf.org [2] mailing list. Criteria that SHOULD be applied by the MLS DEs includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.  For example, the MLS DEs will apply the ciphersuite-related advisory found in ciphersuites. IANA MUST only accept registry updates from the MLS DEs and SHOULD direct all requests for registration to the MLS DEs' mailing list. It is suggested that multiple MLS DEs be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.  In cases where a registration decision could be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. 15.  References 15.1.  URIs [1] mailto:TBD@ietf.org [2] mailto:iesg@ietf.org </ins>

Related discussion:
text: :smiley: You can also .
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise. I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate values or truncation of SHA-512.