Draft: draft-ietf-mls-protocol

Commentary: Here 's the Weekly Digest for : - - Last week 3 issues were created . Of these , 0 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : speaker : , by It received 1 comments . - - Last week , 7 pull requests were created , updated or merged . Last week , 2 pull requests were opened . : greenheart : , by : greenheart : , by Last week , 4 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there were 3 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there were 2 stagazers . : star : : star : You all are the stars ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also . 
 Looks good ! Thanks for cleaning up some of the bits we missed in the original PSK PR !
Paragraph (version A):
After generating fresh key material and applying it to ratchet
forward their local tree state as described in the prior section, the
generator must broadcast this update to other members of the group in
a Commit message, who apply it to keep their local views of the tree
in sync with the sender's.  More specifically, when a member commits
a change to the tree (e.g., to add or remove a member), it transmits
a UpdatePath message containing a set of public and encrypted private
values for intermediate nodes in the direct path of a leaf.  The
other members of the group use these values to update their view of
the tree, aligning their copy of the tree to the sender's.
Paragraph (version B):
After generating fresh key material and applying it to ratchet
forward their local tree state as described in the prior section, the
generator must broadcast this update to other members of the group in
a Commit message, who apply it to keep their local views of the tree
in sync with the sender's.  More specifically, when a member commits
a change to the tree (e.g., to add or remove a member), it transmits
an UpdatePath message containing a set of public and encrypted
private values for intermediate nodes in the direct path of a leaf.
The other members of the group use these values to update their view
of the tree, aligning their copy of the tree to the sender's.
Paragraph (version A):
The injecting of an external PSK can improve security in the cases
where having a full run of updates across members is too expensive or
in the case where the external group key establishment mechanism
provides stronger security against classical or quantum adversaries.
Paragraph (version A):
Re-Initialization: If, during the lifetime of the group, a change
in the fixed group parameters becomes necessary, e.g. if the
ciphersuite used by the group is deprecated or if the protocol
version should be upgraded, a PSK can be used to carry entropy
from the old group forward into a new group with the desired
parameters.
Paragraph (version B):
Injecting an external PSK can improve security in the case where
having a full run of updates across members is too expensive, or if
the external group key establishment mechanism provides stronger
security against classical or quantum adversaries.
Paragraph (version B):
Re-Initialization: If during the lifetime of a group, the group
members decide to switch to a more secure ciphersuite or newer
protocol version, a PSK can be used to carry entropy from the old
group forward into a new group with the desired parameters.
Paragraph (version A):
The injection of one or more PSKs into the key schedule is signaled
in two ways: 1) as a "psk" proposal and 2) in the "GroupSecrets"
object of a Welcome message sent to new members added in that epoch.
Paragraph (version B):
The injection of one or more PSKs into the key schedule is signaled
in two ways: 1) as a "PreSharedKey" proposal, and 2) in the
"GroupSecrets" object of a Welcome message sent to new members added
in that epoch.
Paragraph (version B):
The "index" field in "PSKLabel" corresponds to the index of the PSK
in the "psk" array, while the "count" field contains the total number
of PSKs.
Paragraph (version A):
The main MLS key schedule provides a "recovery_secret" which can
provide extra security in some cross-group operations.
Paragraph (version A):
The application SHOULD specify an upper limit on the number of past
epochs for which the "recovery_secret" may be stored.
Paragraph (version A):
There are three ways in which a "recovery_secret" can be used: to re-
initialize the group with different parameters, to re-add lost group
members or to create a sub-group of an existing group, as detailed in
pre-shared-keys.
Paragraph (version A):
Recovery keys are distinguished from exporter keys in that they have
specific use inside the MLS protocol, whereas the use of exporter
secrets may be decided by an external application.  They are thus
derived separately to avoid key material reuse.
Paragraph (version B):
The main MLS key schedule provides a "resumption_secret" which can
provide extra security in some cross-group operations.
Paragraph (version B):
The application SHOULD specify an upper limit on the number of past
epochs for which the "resumption_secret" may be stored.
Paragraph (version B):
There are two ways in which a "resumption_secret" can be used: to re-
initialize the group with different parameters, or to create a sub-
group of an existing group as detailed in pre-shared-keys.
Paragraph (version B):
Resumption keys are distinguished from exporter keys in that they
have specific use inside the MLS protocol, whereas the use of
exporter secrets may be decided by an external application.  They are
thus derived separately to avoid key material reuse.
Paragraph (version A):
The main MLS key schedule provides a per-epoch
"authentication_secret".  If one of the parties is being actively
impersonated by an attacker, their "authentication_secret" will
differ from that of the other group members.  Thus, members of a
group MAY use their "authentication_secrets" within an out-of-band
authentication protocol to detect attacks or ensure that they share
the same view of the group.
Paragraph (version B):
The main MLS key schedule provides a per-epoch
"authentication_secret".  If one of the parties is being actively
impersonated by an attacker, their "authentication_secret" will
differ from that of the other group members.  Thus, members of a
group MAY use their "authentication_secrets" within an out-of-band
authentication protocol to ensure that they share the same view of
the group.
Paragraph (version A):
Group creation may be tied to an already existing group structure,
consisting of re-initialization of an existing group, or branching of
a sub-group.
Paragraph (version A):
Re-initialization of an existing group may be used, for example, to
re-start the group based on the current group state but under a
different ciphersuite.
Paragraph (version A):
Branching may be used to bootstrap a new group consisting of a subset
of current group members, based on the current group state.
Paragraph (version B):
A new group may be tied to an already existing group for the purpose
of re-initializing the existing group, or to branch into a sub-group.
Re-initializing an existing group may be used, for example, to
restart the group with a different ciphersuite or protocol version.
Branching may be used to bootstrap a new group consisting of a subset
of current group members, based on the current group state.
Paragraph (version A):
If the group is created as the follow-up of a commit including a
"pre_shared_key" extension with "psktype" "reinit", the creator MUST
include the same "pre_shared_key" object in the Welcome message of
the new group.  If the application has specified a lifetime for
recovery secrets, the "psk_epoch" MUST specify an epoch within that
period.  The "psk_group_id" MUST correspond to the id of the group to
be re-initialized.
Paragraph (version A):
Using a "recovery_secret" allows the newly created group to "inherit"
the security level of the original group.
Paragraph (version A):
If a client wants to create a subgroup of an existing group, they MAY
choose to include a "PreSharedKeyID" in the "GroupSecrets" object of
the Welcome message choosing the "psktype" "branch", the "group_id"
of the group from which a subgroup is to be branched, as well as an
epoch within the number of epochs for which a "recovery_secret" is
kept.
Paragraph (version B):
If a client wants to create a subgroup of an existing group, they MAY
choose to include a "PreSharedKeyID" in the "GroupSecrets" object of
the Welcome message choosing the "psktype" "branch", the "group_id"
of the group from which a subgroup is to be branched, as well as an
epoch within the number of epochs for which a "resumption_secret" is
kept.
Paragraph (version A):
A PreSharedKey proposal can be used to request that a PreSharedKey be
injected into the key schedule in the process of advancing the epoch.
Paragraph (version A):
When processing a Commit message including one or more PreSharedKey
proposals, a group member MUST derive the "psk_secret" for the
inclusion in the Key Schedule as described in pre-shared-keys, where
the order of the PSKs corresponds to the order of the PreSharedKey
proposals in the commit.
Paragraph (version B):
A PreSharedKey proposal can be used to request that a pre-shared key
be injected into the key schedule in the process of advancing the
epoch.
Paragraph (version B):
The "psktype" of the pre-shared key MUST be "external" and the
"psk_nonce" MUST be a randomly sampled nonce of length "KDF.Nh".
When processing a Commit message that includes one or more
PreSharedKey proposals, group members derive "psk_secret" as
described in pre-shared-keys, where the order of the PSKs corresponds
to the order of the "PreSharedKey" proposals in the Commit.
Paragraph (version A):
A member of the group applies a ReInit message by waiting for the
committer to send the Welcome message and by checking that the
"group_id" and the parameters of the new group corresponds to the
ones specified in the proposal.  The Welcome message MUST specify a
"PreSharedKey" with "psktype = reinit" and with "psk_group_id" and
"psk_epoch" equal to the "group_id" and "epoch" of the existing group
after the Commit containing the "reinit" Proposal was processed.
Paragraph (version B):
A member of the group applies a ReInit proposal by waiting for the
committer to send the Welcome message and by checking that the
"group_id" and the parameters of the new group corresponds to the
ones specified in the proposal.  The Welcome message MUST specify
exactly one pre-shared key with "psktype = reinit", and with
"psk_group_id" and "psk_epoch" equal to the "group_id" and "epoch" of
the existing group after the Commit containing the "reinit" Proposal
was processed.  The Welcome message may specify the inclusion of
other pre-shared keys with a "psktype" different from "reinit".
Paragraph (version B):
If a ReInit proposal is included in a Commit, it MUST be the only
proposal referenced by the Commit.  If other non-ReInit proposals
have been sent during the epoch, the committer SHOULD prefer them
over the ReInit proposal, allowing the ReInit to be resent and
applied in a subsequent epoch.  The "version" field in the ReInit
proposal MUST be no less than the version for the current group.
Paragraph (version A):
If there are multiple ReInit proposals, the committer MUST choose
exactly one to include in the Commit message.  The "version" field in
the ReInit proposal MUST be no less than the version for the current
group.  A client processing a Commit that covers multiple ReInit
proposals or a ReInit proposal with a lower version MUST reject it as
malformed.  The committer SHOULD choose a ReInit proposal with a
unique "group_id" and parameters that are supported by all clients in
the group.
Paragraph (version A):
A ReInit proposal is applied by marking the group as "closed".
Further proposals and commits for this group MUST be rejected.
The group's only further purpose is to provide a PSK used by
the successor group.
Paragraph (version A):
If one or more PreSharedKey proposals are part of the commit,
derive the "psk_secret" as specified in pre-shared-keys, where the
order of PSKs in the derivation corresponds to the order of
PreSharedKey proposals in the "proposals" vector.  Otherwise, set
"psk_secret" to 0.
Paragraph (version B):
If one or more PreSharedKey proposals are part of the commit,
derive the "psk_secret" as specified in pre-shared-keys, where the
order of PSKs in the derivation corresponds to the order of
PreSharedKey proposals in the "proposals" vector.  Otherwise, set
"psk_secret" to a zero-length octet string.
Paragraph (version A):
Construct a Welcome message from the encrypted GroupInfo object,
the encrypted key packages and any PSK for which a proposal was
included in the commit.  The order of the "psks" MUST be the same
as the order of PreSharedKey proposals in the "proposals" vector.
Paragraph (version A):
If a ReInit proposal was part of the Commit, the committer MUST
create a new group with the Group ID and the parameters specified
in the ReInit proposal and with the same members as the original
group after processing the current commit.  The Welcome message
MUST include a "PreSharedKeyID" with "psktype" "reinit" and with
"psk_group_id" and "psk_epoch" corresponding to the current group
and the epoch after the commit was processed.
Paragraph (version B):
Construct a Welcome message from the encrypted GroupInfo object,
the encrypted key packages, and any PSKs for which a proposal was
included in the Commit.  The order of the "psks" MUST be the same
as the order of PreSharedKey proposals in the "proposals" vector.
Paragraph (version B):
If a ReInit proposal was part of the Commit, the committer MUST
create a new group with the parameters specified in the ReInit
proposal, and with the same members as the original group.  The
Welcome message MUST include a "PreSharedKeyID" with "psktype"
"reinit" and with "psk_group_id" and "psk_epoch" corresponding to
the current group and the epoch after the commit was processed.
Paragraph (version A):
Verify that at most one ReInit proposal is present and that the
"mls_version" field indicates an equal or higher version that that
of the current group.
Paragraph (version A):
The "version", "cipher_suite" and "extensions" fields of the
new group corresponds to the ones in the "ReInit" proposal and
the "version" is greater or equal to that of the original
group.
Paragraph (version A):
The "psks" field in the Welcome message includes a
"PreSharedKeyID" with "psktype" = "reinit" "psk_epoch" =
"epoch" and "psk_group_id" = "group_id", where "epoch" and
"group_id" are the fields of the original group after
processing the commit.
Paragraph (version A):
If any of the conditions are not met, the Client SHOULD not
process the Welcome message.
Paragraph (version B):
The "version", "cipher_suite" and "extensions" fields of the
new group corresponds to the ones in the "ReInit" proposal, and
that the "version" is greater than or equal to that of the
original group.
Paragraph (version B):
The "psks" field in the Welcome message includes a
"PreSharedKeyID" with "psktype" = "reinit", and "psk_epoch" and
"psk_group_id" equal to the epoch and group ID of the original
group after processing the Commit.
Paragraph (version A):
If the sender of the Welcome message wants the receiving member to
include a PSK into the derivation of the "epoch_secret", they can add
a field indicating which PSK to use.  A PSK MUST be included if the
Welcome message is sent in the context of a group re-initialization
and it SHOULD be included if the Welcome message is sent to create a
sub-group of an existing group.
Paragraph (version B):
If the sender of the Welcome message wants the receiving member to
include a PSK in the derivation of the "epoch_secret", they can
populate the "psks" field indicating which PSK to use.