Draft: draft-ietf-mls-protocol

Commentary: Complete the renaming of InitKeys -KeyPackages ; and GroupInfo -PublicGroupState 
 Comment by     . RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help . 
 CC for citations 
 They are also in this architecture document PR : 
 Oh good , I 'll just add a citation over to mls - architecture .
Paragraph (version A):
A signed object describing a client's identity and capabilities,
and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg-
hpke) public key that can be used to encrypt to that client.
Paragraph (version A):
A key package that is prepublished by a client, which other
clients can use to introduce the client to a new group.
Paragraph (version B):
A signed object describing a client's identity and capabilities,
and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg-
hpke) public key that can be used to encrypt to that client, and
which other clients can use to introduce the client to a new
group.
Paragraph (version A):
Before the initialization of a group, clients publish InitKeys (as
KeyPackage objects) to a directory provided by the Service Provider.
Paragraph (version B):
Before the initialization of a group, clients publish KeyPackages to
a directory provided by the Service Provider.
Paragraph (version A):
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for signatures in MLSPlaintext and the tree
signatures.  It MUST be the same as the signature algorithm specified
in the credential field of the KeyPackage objects in the leaves of
the tree (including the InitKeys used to add new members).
Paragraph (version B):
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for signatures in MLSPlaintext and the tree
signatures.  It MUST be the same as the signature algorithm specified
in the credential field of the KeyPackage objects in the leaves of
the tree (including those used to add new members).
Paragraph (version A):
When used as InitKeys, KeyPackages are intended to be used only once
and SHOULD NOT be reused except in case of last resort.  (See
initkey-reuse).  Clients MAY generate and publish multiple InitKeys
to support multiple ciphersuites.
Paragraph (version B):
KeyPackages are intended to be used only once and SHOULD NOT be
reused except in case of last resort.  (See keypackage-reuse).
Clients MAY generate and publish multiple KeyPackages to support
multiple ciphersuites.
Paragraph (version A):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the GroupInfo and an
external Commit to initialize their copy of the key schedule for the
new epoch.
Paragraph (version A):
In both cases, the "info" input to HPKE is set to the GroupInfo for
the previous epoch, encoded using the TLS serialization.
Paragraph (version B):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the PublicGroupState and
an external Commit to initialize their copy of the key schedule for
the new epoch.
Paragraph (version B):
In both cases, the "info" input to HPKE is set to the
PublicGroupState for the previous epoch, encoded using the TLS
serialization.
Paragraph (version A):
Post-compromise security is also provided for new groups by members
regularly generating new InitKeys and uploading them to the Delivery
Service, such that compromised key material won't be used when the
member is added to a new group.
Paragraph (version A):
InitKeys are intended to be used only once.  That is, once an InitKey
has been used to introduce the corresponding client to a group, it
SHOULD be deleted from the InitKey publication system.  Reuse of
InitKeys can lead to replay attacks.
Paragraph (version A):
An application MAY allow for reuse of a "last resort" InitKey in
order to prevent denial of service attacks.  Since an InitKey is
needed to add a client to a new group, an attacker could prevent a
client being added to new groups by exhausting all available
InitKeys.
Paragraph (version B):
Post-compromise security is also provided for new groups by members
regularly generating new KeyPackages and uploading them to the
Delivery Service, such that compromised key material won't be used
when the member is added to a new group.
Paragraph (version B):
KeyPackages are intended to be used only once.  That is, once a
KeyPackage has been used to introduce the corresponding client to a
group, it SHOULD be deleted from the KeyPackage publication system.
Reuse of KeyPackages can lead to replay attacks.
Paragraph (version B):
An application MAY allow for reuse of a "last resort" KeyPackage in
order to prevent denial of service attacks.  Since a KeyPackage is
needed to add a client to a new group, an attacker could prevent a
client being added to new groups by exhausting all available
KeyPackages.