Draft: draft-ietf-mls-protocol

Commentary: Here 's to hoping I did this merge properly .
Paragraph (version A):
All of these registries should be under a heading of "Message Layer
Security", and administered under a Specification Required policy
RFC8126.
Paragraph (version A):
This specification defines the following cipher suites for use with
MLS 1.0.
Paragraph (version B):
This document requests the creation of the following new IANA
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).
Paragraph (version B):
This specification defines the following ciphersuites for use with
MLS 1.0.
Paragraph (version A):
between two security levels (roughly 128 bit and 256bit).  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 A):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519" which is using
Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES-
128-GCM with Ed25519 for symmetric encryption and signatures.
Paragraph (version B):
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):
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.
Paragraph (version B):
New ciphersuite values are assigned by IANA as described in iana-
considerations.
Paragraph (version B):
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.
Paragraph (version B):
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").
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
IANA MUST only accept registry updates from the MLS DEs and SHOULD
direct all requests for registration to the MLS DEs' mailing list.
Paragraph (version B):
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.