Draft: draft-ietf-mls-protocol

Commentary: Changes to key schedule and corresponding directions on use of PSKs for group recovery , re - initialization , sub - group branching , and external PSK injection . 
 I had some long - form comments on this PR , so I sent them to the mailing list .
Paragraph (version B):
An agent that uses this protocol to establish shared cryptographic
state with other clients.  A client is defined by the
cryptographic keys it holds.
Paragraph (version B):
When a client A wants to establish a group with B and C, it first
initializes a group state containing only itself and downloads
KeyPackages for B and C.  For each member, A generates an Add and
Commit message adding that member, and broadcasts them to the group.
It also generates a Welcome message and sends this directly to the
new member (there's no need to send it to the group).  Only after A
has received its Commit message back from the server does it update
its state to reflect the new member's addition.
Paragraph (version B):
Update messages should be sent at regular intervals of time as long
as the group is active, and members that don't update should
eventually be removed from the group.  It's left to the application
to determine an appropriate amount of time between Updates.
Paragraph (version B):
Each outdated node key pair that was replaced by the update.
Paragraph (version A):
Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X).  (Recall that any 32-octet string is a
valid Curve25519 private key.)  The corresponding public key is
X25519(SHA-256(X), 9).
Paragraph (version A):
Given an octet string X, the private key produced by the Derive-Key-
Pair operation is SHA-256(X), interpreted as a big-endian integer.
The corresponding public key is the result of multiplying the
standard P-256 base point by this integer.
Paragraph (version A):
P-256 ECDH calculations (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.
Paragraph (version B):
The "lifetime" extension represents the times between which clients
will consider a KeyPackage valid.  This time is represented as an
absolute time, measured in seconds since the Unix epoch
(1970-01-01T00:00:00Z).  A client MUST NOT use the data in a
KeyPackage for any processing before the "not_before" date, or after
the "not_after" date.
Paragraph (version B):
Applications MUST define a maximum total lifetime that is acceptable
for a KeyPackage, and reject any KeyPackage where the total lifetime
is longer than this duration.
Paragraph (version B):
Within MLS, a KeyPackage is identified by its hash (see, e.g.,
welcoming-new-members).  The "key_id" extension allows applications
to add an explicit, application-defined identifier to a KeyPackage.
Paragraph (version B):
The "parent_hash" extension serves to bind a KeyPackage to all the
nodes above it in the group's ratchet tree.  This enforces the tree
invariant, meaning that malicious members can't lie about the state
of the ratchet tree when they send Welcome messages to new members.
Paragraph (version B):
To allow group members to verify that they agree on the public
cryptographic state of the group, this section defines a scheme for
generating a hash value that represents the contents of the group's
ratchet tree and the members' KeyPackages.
Paragraph (version B):
Elements of the ratchet tree are called "Node" objects and the leaves
contain an optional "KeyPackage", while the parents contain an
optional "ParentNode".
Paragraph (version B):
Thus the "confirmed_transcript_hash" field in a GroupContext object
represents a transcript over the whole history of MLSPlaintext Commit
messages, up to the confirmation field in the current MLSPlaintext
message.  The confirmation and signature fields are then included in
the transcript for the next epoch.  The interim transcript hash is
passed to new members in the GroupInfo struct, and enables existing
members to incorporate a Commit message into the transcript without
having to store the whole MLSPlaintextCommitAuthData structure.
Paragraph (version B):
Groups which already have an out-of-band mechanism to generate shared
group secrets can inject those into the MLS key schedule to seed the
MLS group secrets computations by this external entropy.
Paragraph (version B):
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 B):
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 reboot the group
with the desired parameters.
Paragraph (version B):
Recovery: If the group state of one or more members of the group
deviates from the rest, they can be re-added to the group
securely.
Paragraph (version B):
The injection of one or more PSKs into the key schedule is signaled
in two ways: 1) as an extension to a Commit message that initiates a
new epoch and 2) in the "GroupSecrets" object of a Welcome message
sent to new members added in that epoch.
Paragraph (version B):
For handshake and application messages, a sequence of keys is derived
via a "sender ratchet".  Each sender has their own sender ratchet,
and each step along the ratchet is called a "generation".
Paragraph (version B):
A sender ratchet starts from a per-sender base secret.  For
application keys, the base secret is derived as described in astree.
For handshake keys, base secrets are derived directly from the
"handshake_secret".
Paragraph (version B):
The base secret for each sender is used to initiate a symmetric hash
ratchet which generates a sequence of keys and nonces.  The sender
uses the j-th key/nonce pair in the sequence to encrypt (using the
AEAD) the j-th message they send during that epoch.  In particular,
each key/nonce pair MUST NOT be used to encrypt more than one
message.
Paragraph (version B):
Here, AEAD.nonce_length and AEAD.key_length denote the lengths in
bytes of the nonce and key for the AEAD scheme defined by the
ciphersuite.  "Ratchet" should be understood to mean "handshake" or
"application" depending on the context.
Paragraph (version B):
The context used for the derivation of the "exported_value" MAY be
empty while each application SHOULD provide a unique label as an
input of the ExpandWithLabel for each use case.  This is to prevent
two exported outputs from being generated with the same values and
used for different functionalities.
Paragraph (version B):
The main MLS key schedule provides a "recovery_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 "recovery_secret" may be stored.
Paragraph (version B):
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 B):
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 resulting from poor
exporter key management external to the protocol.
Paragraph (version B):
The main MLS key schedule provides a per-epoch
"authentication_secret" which MAY be used for authenticating the
current group state.  As with recovery keys, these are distinguished
from exporter keys in that they have specific use affecting the MLS
protocol.
Paragraph (version B):
Authentication keys MAY be used to authenticate current or past group
members out-of-band.
Paragraph (version B):
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 B):
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 B):
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):
In both cases, the "psk_nonce" included in the "PreSharedKey" object
must be a randomly sampled nonce to avoid key re-use.
Paragraph (version B):
If the group is created as the follow-up of a commit including a
"pre_shared_key" extension with "psktype" "re-initialization", 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 B):
Using a "recovery_secret" allows the newly created group to "inherit"
the security level of the original group.
Paragraph (version B):
If a client wants to create a subgroup of an existing group, they MAY
choose to include a "PSKId" 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):
The group thus evolves from one cryptographic state to another each
time a Commit message is sent and processed.  These states are
referred to as "epochs" and are uniquely identified among states of
the group by eight-octet epoch values.  When a new group is
initialized, its initial state epoch is 0x0000000000000000.  Each
time a state transition occurs, the epoch number is incremented by
one.
Paragraph (version B):
A Re-Initialize proposal requests that the group be re-initialized,
for example to change the ciphersuite of the group.
Paragraph (version B):
The "re-init_group_id" is the id of the new group.  The fields
"mls_version", "ciphersuite" and "extensions" specify the desired
parameters of the new group.
Paragraph (version B):
A PSK proposal requests that an external PSK be injected into the
group.
Paragraph (version B):
The "psktype" field of "pskid" has to be "external" and the "psk_id"
field should correspond to the ID with which members can identify the
external PSK.
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group who has been inactive for
a long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by a "preconfigured" or "new_member" SenderType
in MLSPlaintext.
Paragraph (version A):
chooses one to include and considers the rest invalid.
Paragraph (version B):
chooses one to include and considers the rest invalid.  Similarly, if
there are multiple proposals to re-initialize the group, the client
MUST choose at most one and include it in the commit.
Paragraph (version B):
An "empty" Commit that references no proposals, which updates the
committer's contribution to the group and provides PCS with regard
to the committer.
Paragraph (version B):
A "full" Commit that references proposals of any type, which
provides FS with regard to any removed members and PCS for the
committer and any updated members.
Paragraph (version B):
Construct an initial Commit object with "updates", "removes" and
"adds", fields populated from Proposals received during the
current epoch, and empty "client_init_key" and "path" fields.
Paragraph (version B):
Decide whether to populate the "path" field: If the "path" field
is required based on the proposals that are in the commit (see
above), then it MUST be populated.  Otherwise, the sender MAY omit
the "path" field at its discretion.
Paragraph (version B):
Compute an EncryptedGroupSecrets object that encapsulates the
"init_secret" for the current epoch and the path secret (if
present).
Paragraph (version B):
Construct a Welcome message from the encrypted GroupInfo object,
the encrypted key packages and, optionally, a PSK.
Paragraph (version B):
The "ProtocolVersion" of the new group is greater or equal to
that of the original group.
Paragraph (version B):
A "pre_shared_key" extension is included in the Welcome message
with "psktype = re-initialization", "psk_group_id = group_id",
"psk_epoch = epoch" and "psk_nonce", where "group_id" and
"epoch" are the fields from the previously constructed
GroupContext object and "re-init_nonce" is the field from the
"Re-Init" proposal included in the commit.
Paragraph (version B):
If any of the conditions is not met, the Client SHOULD not process
the Welcome message.
Paragraph (version B):
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):
The client processing a Welcome message will need to have a copy of
the group's ratchet tree.  The tree can be provided in the Welcome
message, in an extension of type "ratchet_tree".  If it is sent
otherwise (e.g., provided by a caching service on the Delivery
Service), then the client MUST download the tree before processing
the Welcome.
Paragraph (version B):
Decrypt the "encrypted_key_package" using HPKE with the algorithms
indicated by the ciphersuite and the HPKE private key
corresponding to the ClientInitKey.  If a PSKId is part of the
KeyPackage and the client is not in possession of the
corresponding PSK, return an error.
Paragraph (version B):
From the "joiner_secret" in the decrypted GroupSecrets object and
the PSKs specified in the "GroupSecrets", derive the
"member_secret" and using that the "welcome_secret",
"welcome_key", and "welcome_nonce".  Use the key and nonce to
decrypt the "encrypted_group_info" field.
Paragraph (version B):
For each non-empty parent node, verify that exactly one of the
node's children are non-empty and have the hash of this node
set as their "parent_hash" value (if the child is another
parent) or has a "parent_hash" extension in the KeyPackage
containing the same value (if the child is a leaf).
Paragraph (version A):
Identify the lowest common ancestor of the leaves at "index"
and at "GroupInfo.signer_index".  Set the private key for this
node to the private key derived from the "path_secret" in the
KeyPackage object.
Paragraph (version B):
If the "path_secret" value is set in the GroupSecrets object:
Identify the lowest common ancestor of the leaves at "index"
and at "GroupInfo.signer_index".  Set the private key for this
node to the private key derived from the "path_secret".
Paragraph (version A):
Use the "epoch_secret" from the KeyPackage object to generate the
epoch secret and other derived secrets for the current epoch.
Paragraph (version B):
Use the "joiner_secret" from the GroupSecrets object to generate
the epoch secret and other derived secrets for the current epoch.
Paragraph (version B):
The presence of a "ratchet_tree" extension in a GroupInfo message
does not result in any changes to the GroupContext extensions for the
group.  The ratchet tree provided is simply stored by the client and
used for MLS operations.
Paragraph (version B):
If this extension is not provided in a Welcome message, then the
client will need to fetch the ratchet tree over some other channel
before it can generate or process Commit messages.  Applications
should ensure that this out-of-band channel is provided with security
protections equivalent to the protections that are afforded to
Proposal and Commit messages.  For example, an application that
encrypts Proposal and Commit messages might distribute ratchet trees
encrypted using a key exchanged over the MLS channel.
Paragraph (version B):
A client that posts a KeyPackage MUST support all parameters
advertised in it.  Otherwise, another client might fail to
interoperate by selecting one of those parameters.
Paragraph (version B):
The secret of any other node in the tree is derived from its parent's
secret using a call to DeriveAppSecret.
Paragraph (version B):
The secret in the leaf of the AS tree is used to initiate a symmetric
hash ratchet, from which a sequence of single-use keys and nonces are
derived, as described in encryption-keys.
Paragraph (version A):
The security goals of MLS are described in [I-D.ietf-mls-
architecture].  We describe here how the protocol achieves its goals
at a high level, though a complete security analysis is outside of
the scope of this document.
Paragraph (version B):
The security goals of MLS are described in I-D.ietf-mls-architecture.
We describe here how the protocol achieves its goals at a high level,
though a complete security analysis is outside of the scope of this
document.
Paragraph (version B):
All of these registries should be under a heading of "Messaging 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):
A ciphersuite is a combination of a protocol version and the set of
cryptographic algorithms that should be used.
Paragraph (version B):
It is advisable to keep the number of ciphersuites low to increase
the chances clients can interoperate in a federated environment,
therefore the ciphersuites only inlcude modern, yet well-established
algorithms.  Depending on their requirements, clients can choose
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):
This registry lists identifiers for extensions to the MLS protocol.
The extension type field is two bytes wide, so valid extension type
values are in the range 0x0000 to 0xffff.
Paragraph (version B):
Specification Required RFC8126 registry requests are registered after
a three-week review period on the MLS DEs' mailing list: mls-reg-
review@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.