Draft: draft-ietf-mls-protocol

Commentary: As discussed in the virtual interim 2022 - 12 - 16 , it is possible that extensions might be tempted to re - use HPKE public keys created for MLS . Even within MLS , we have two different public - key encryption cases , Welcome and Commit ( though these currently use different keys ) . Currently , for Commit encryption , the HPKE parameter is set to the group context . The content of is actually undefined for Welcome encryption ( ! ) This PR makes the following changes : Define general and functions that populte the HPKE parameter with an encoded label and context Apply these to Commit and Welcome encryption : Commit : label="UpdatePathNode " , context= Welcome : label="Welcome " , context= Add an IANA registry of public - key encryption labels ( as for signing ) There is also a bit of reorganization of the Ciphersuites section to split it into three subsections . 
 Note that any previous analysis of MLS had to take this particular reuse into account . This ca n't be the case for any arbitrary extensions reusing the key . So if MLS uses an extension that reuses the key , none of the existing analysis applies , which is a much bigger issue . This said , this reuse did decrease security -- it weakened FS in that a joiner had to hold on to their HPKE leaf key , which also allowed to decrypt the init secret from the welcome message , long after joining . 
 I think this captures what we discussed during the interim . FWIW , I 'm wondering if we did n't have a domain separation issue in the past when we only had one HPKE public key in KeyPackages and used it for both the Welcome subsequently for UpdatePath as well . Either way , I think this is a good defense - in - depth mechanism .
Paragraph (version A):
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):
Like HPKE public keys, signature public keys are represented as
opaque values in a format defined by the ciphersuite's signature
scheme.
Paragraph (version B):
Ciphersuites are represented with the CipherSuite type.  The
ciphersuites are defined in mls-ciphersuites.
Paragraph (version B):
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 B):
Signature public keys are likewise represented as opaque values in a
format defined by the ciphersuite's signature scheme.
Paragraph (version A):
The ciphersuites are defined in section mls-ciphersuites.
Paragraph (version B):
Here, the functions "SealBase" and "OpenBase" are defined RFC9180,
using the HPKE algorithms specified by the group's ciphersuite.  If
MLS extensions require HPKE encryption operations, they should re-use
the EncryptWithLabel construction, using a distinct label.  To avoid
collisions in these labels, an IANA registry is defined in mls-
public-key-encryption-labels.
Paragraph (version A):
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, group_context is the provisional
GroupContext object for the group, and the functions "SetupBaseS" and
"Seal" are defined according to RFC9180.
Paragraph (version A):
Decryption is performed in the corresponding way, using the private
key of the resolution node.
Paragraph (version B):
Here "node_public_key" is the public key of the node for which the
path secret is encrypted, "group_context" is the provisional
GroupContext object for the group, and the "EncryptWithLabel"
function is as defined in public-key-encryption.
Paragraph (version A):
Decrypt the "encrypted_group_secrets" value with the algorithms
indicated by the ciphersuite and the private key corresponding to
"init_key" in the referenced KeyPackage.
Paragraph (version B):
Decrypt the "encrypted_group_secrets" value with the algorithms
indicated by the ciphersuite and the private key "init_key_priv"
corresponding to "init_key" in the referenced KeyPackage.
Paragraph (version A):
The "SignWithLabel" function defined in ciphersuites avoids the risk
of confusion between signatures in different contexts.  Each context
is assigned a distinct label that is incorporated into the signature.
This registry records the labels defined in this document, and allows
additional labels to be registered in case extensions add other types
of signature using the same signature keys used elsewhere in MLS.
Paragraph (version B):
The "SignWithLabel" function defined in signing avoids the risk of
confusion between signatures in different contexts.  Each context is
assigned a distinct label that is incorporated into the signature.
This registry records the labels defined in this document, and allows
additional labels to be registered in case extensions add other types
of signature using the same signature keys used elsewhere in MLS.
Paragraph (version B):
The "EncryptWithLabel" function defined in public-key-encryption
avoids the risk of confusion between ciphertexts produced for
different purposes in different contexts.  Each context is assigned a
distinct label that is incorporated into the signature.  This
registry records the labels defined in this document, and allows
additional labels to be registered in case extensions add other types
of public-key encryption using the same HPKE keys used elsewhere in
MLS.