Draft: draft-ietf-mls-protocol

Commentary: proposes to remove redundancy between version fields and ciphersuites by removing the version fields . This PR removes the version from the ciphersuite instead . 
 suggests adding some advisory text in the extensibility section to the effect that future versions of the protocol should consider whether they want to keep all defined ciphersuites . 
 here is some text we put in RFC 8447 ( IANA registries for TLS ) that was also included in the IANA registry to warn about cipher suites getting weaker over time . This could be modified to mention culling at different version . WARNING : : Cryptographic algorithms and parameters will be broken or weakened over time . Blindly implementing cipher suites listed here is not advised . Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security . 
 Affiliation -Meta Platforms Address - 
 In , the field of is removed . I 'm guessing the reason was that is was redundant with the ciphersuite , since the MLS version is at the time included in the ciphersuite . However , in , MLS versions were removed from ciphersuites , making the protocol version not redundant anymore with the ciphersuite . We should probably put the MLS version back there ? 
 I just discovered that this is then fixed by adding the MLS version to in , closing .
Paragraph (version B):
The base MLS protocol can be extended in a few ways.  New
ciphersuites can be added to enable the use of new cryptographic
algorithms.  New types of proposals can be used to perform new
actions within an epoch.  Extension fields can be used to add
additional information to the protocol.  In this section, we discuss
some constraints on these extensibility mechanisms that are necessary
to ensure broad interoperability.
Paragraph (version B):
As discussed in ciphersuites, MLS allows the participants in a group
to negotiate the cryptographic algorithms used within the group.
This extensibility is important for maintaining the security of the
protocol over time RFC7696.  It also creates a risk of
interoperability failure due to clients not supporting a common
ciphersuite.
Paragraph (version B):
The ciphersuite registry defined in mls-ciphersuites attempts to
strike a balance on this point.  On the one hand, the base policy for
the registry is Specification Required, a fairly low bar designed to
avoid the need for standards work in cases where different ciphers
are needed for niche applications.  There is a higher bar (Standards
Action) for ciphers to set the Recommended field in the registry.
This higher bar is there in part to ensure that the interoperability
implications of new ciphersuites are considered.
Paragraph (version B):
MLS ciphersuites are defined independent of MLS versions, so that in
principle the same ciphersuite can be used across versions.
Standards work defining new versions of MLS should consider whether
it is desirable for the new version to be compatible with existing
ciphersuites, or whether the new version should rule out some
ciphersuites.  For example, a new version could follow the example of
HTTP/2, which restricted the set of allowed TLS ciphers (see
Section 9.2.2 of RFC7540.
Paragraph (version B):
Commit messages do not have an extension field because the set of
protocols is extensible.  As discussed in commit, Proposals with a
non-default proposal type MUST NOT be included in a commit unless the
proposal type is supported by all the members of the group that will
process the Commit.
Paragraph (version A):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses
Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over
SHA2-256, and Ed25519 for signatures.
Paragraph (version B):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519
for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and
Ed25519 for signatures.