Draft: draft-ietf-mls-protocol

Commentary: The first commit is editorial . I removed all the DH terminology I could find and replaced it with KEM terminology . The second commit is related to It would massively reduce complexity of implementations if people were able to rely on HPKE to do all private key parsing , key validation , public key computation , etc . Currently , all the information in the deleted CFRG and NIST sections is either redundant ( performed by HPKE ) or outdated and performed correctly by HPKE ( e.g. , old P-256 DH secret representation ) . Instead of having all this duplicated , it would be easier to keep it in one place . An issue with the new definition of : Repeatedly calling can be computationally expensive . Each call requires computing the group hash ( which , okay , it could be cached ) and serializing a struct . It would be nice to do something that 's cheaper but still ties context into the secret key generation . 
 Update : This now uses HPKE 's function to do all the heavy lifting
Paragraph (version A):
The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE
I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.
The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps
octet strings with length Hash.length to HPKE key pairs.
Paragraph (version A):
Ciphersuites are represented with the CipherSuite type.  HPKE public
keys are opaque values in a format defined by the underlying Diffie-
Hellman protocol (see the Ciphersuites section of the HPKE
specification for more information).
Paragraph (version B):
The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke
instance for the purpose of public-key encryption.  Each ciphersuite
has a "Derive-Key-Pair" function that maps octet strings of length
"Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs.
This function is defined to be HPKE's "DeriveKeyPair" function.
Paragraph (version B):
Ciphersuites are represented with the CipherSuite type.  HPKE public
keys are opaque values in a format defined by the underlying protocol
(see the Cryptographic Dependencies section of the HPKE specification
for more information).
Paragraph (version A):
Depending on the Diffie-Hellman group of the ciphersuite, different
rules apply to private key derivation and public key verification.
For all ciphersuites defined in this document, the Derive-Key-Pair
function begins by deriving a "key pair secret" of appropriate
length, then converting it to a private key in the required group.
The ciphersuite specifies the required length and the conversion.
Paragraph (version A):
For X25519, the key pair secret is 32 octets long.  No conversion is
required, since any 32-octet string is a valid X25519 private key.
The corresponding public key is X25519(SHA-256(X), 9).
Paragraph (version A):
For X448, the key pair secret is 56 octets long.  No conversion is
required, since any 56-octet string is a valid X448 private key.  The
corresponding public key is X448(SHA-256(X), 5).
Paragraph (version A):
For P-256, the key pair secret is 32 octets long.  For P-521, the key
pair secret is 66 octets long.  In either case, the private key
derived from a key pair secret is computed by interpreting the key
pair secret as a big-endian integer.
Paragraph (version A):
ECDH calculations for these curves (including parameter and key
generation as well as the shared secret calculation) are performed
according to IEEE1363 using the ECKAS-DH1 scheme with the identity
map as key derivation function (KDF), so that the shared secret is
the x-coordinate of the ECDH shared secret elliptic curve point
represented as an octet string.  Note that this octet string (Z in
IEEE 1363 terminology) as output by FE2OSP, the Field Element to
Octet String Conversion Primitive, has constant length for any given
field; leading zeros found in this octet string MUST NOT be
truncated.
Paragraph (version A):
Clients MUST validate remote public values by ensuring that the point
is a valid point on the elliptic curve.  The appropriate validation
procedures are defined in Section 4.3.7 of X962 and alternatively in
Section 5.6.2.3 of keyagreement.  This process consists of three
steps: (1) verify that the value is not the point at infinity (O),
(2) verify that for Y = (x, y) both integers are in the correct
interval, (3) ensure that (x, y) is a correct solution to the
elliptic curve equation.  For these curves, implementers do not need
to verify membership in the correct subgroup.