jiebi/CodeConvo huggingface dataset:
Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the <del> protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). </del> <ins> protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and AJM20 (draft 12). </ins> Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for <del> example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] </del> <ins> example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21 </ins> analyze the ratcheting tree as the sub-protocol of MLS that <del> facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS. </del> <ins> facilitates key agreement, while BCK21 analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 8. <del> ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACDT19: https://eprint.iacr.org/2019/1189 ACDT21: https://eprint.iacr.org/2021/1083 ACJM20: https://eprint.iacr.org/2020/752 AHKM21: https://eprint.iacr.org/2021/1456 AJM20: https://eprint.iacr.org/2020/1327 BBN19: https://hal.laas.fr/INRIA/hal-02425229 BBR18: https://hal.inria.fr/hal-02425247 BCK21: https://eprint.iacr.org/2021/137 CHK21: https://www.usenix.org/system/files/sec21-cremers.pdf 9. </del> This document makes no requests of IANA.
KT log under a user's identity.  The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to <del> monitor and control which keys are associated to their identity. </del> <ins> monitor and control which keys are associated with their identity. </ins> By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its
is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised. <del> MLS partially defend against this problem by active member including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </del> <ins> MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </ins> <del> *RECOMMENDATION:* Mandate a key updates from clients that are not </del> <ins> *RECOMMENDATION:* Mandate key updates from clients that are not </ins> otherwise sending messages and evict clients which are idle for too long.
the secrets themselves are protected by HPKE encryption. Note that under that compromise scenario, authentication is not <del> affected in neither of these cases.  As every member of the group can </del> <ins> affected in either of these cases.  As every member of the group can </ins> compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common
secrecy. If the adversary is active, the adversary can follow the protocol and <del> perform updates on behalf of the compromised party with no ability to an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </del> <ins> perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </ins> messages exchanged in the epochs after the compromised party has been removed.
and changed with each message received by a client. However, the signature private keys are mostly used by clients to <del> send a message.  They also are providing the strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanism should be a priority. </del> <ins> send a message.  They also provide strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanisms should be a priority. </ins> <del> Overall there is no way to detect or prevent these compromise, as </del> <ins> Overall there is no way to detect or prevent these compromises, as </ins> discussed in the previous sections, performing separation of the application secret states can help recovery after compromise, this is the case for signature keys but similar concern exists for the
The attacker can publish or distribute credentials Infrastructures that provide cryptographic material or credentials in <del> place of the MLS client (which is under the control of the user) have often the ability to use the associated secrets to perform operations on behalf of the user, which is unacceptable in many situations. Other mechanisms can be used to prevent this issue, such as the service blessing cryptographic material used by an MLS client. </del> <ins> place of the MLS client (which is under the control of the user) often have the ability to use the associated secrets to perform operations on behalf of the user, which is unacceptable in many situations.  Other mechanisms can be used to prevent this issue, such as the service blessing cryptographic material used by an MLS client. </ins> *RECOMMENDATION:* Make clients submit signature public keys to the AS, this is usually better than the AS generating public key pairs
inside the group.  When members perform changes directly, this is clearly the case.  External joins are authorized indirectly, in the sense that a member publishing a GroupInfo object authorizes anyone <del> to join who has access to the GroupInfo object.  External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail. </del> <ins> to join who has access to the GroupInfo object.  Both types of joins are done via a Commit message, which could be blocked by the DS or rejected by clients if the join is not authorized.  The former approach requires that Commits be visible to the DS; the latter approach requires that clients all share a consistent policy.  In the unfortunate event that an unauthorized member is able to join, MLS enables any member to remove them. </ins> Application setup may also determine other criteria for membership validity.  For example, per-device signature keys can be signed by an
5.5. <del> Within an MLS group, every member is authenticated to other member, by means of credentials issued and verified by the Authentication </del> <ins> Within an MLS group, every member is authenticated to other member by means of credentials issued and verified by the Authentication </ins> Service.  MLS does not prescribe what actions, if any, an application should take in the event that a group member presents an invalid credential.  For example, an application may require such a member to
In some authentication systems, it is possible for a previously-valid credential to become invalid over time.  For example, in a system based on X.509 certificates, credentials can expire or be revoked. <del> Fortunately, the MLS update mechansisms allow a client to replace an old credential with a new one.  This is best done before the old credential becomes invalid. </del> <ins> The MLS update mechanisms allow a client to replace an old credential with a new one.  This is best done before the old credential becomes invalid. </ins> *RECOMMENDATION:* Proactively rotate credentials, especially if a credential is about to become invalid.
2. <ins> 2.1. </ins> MLS provides a way for _clients_ to form _groups_ within which they can communicate securely.  For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other.  A group may be as small as two clients (e.g., for simple person to person messaging) or as large as tens of thousands. <del> A client that is part of a group is a _member_ of that group. </del> <ins> A client that is part of a group is a _member_ of that group.  As groups change membership and group or member properties, they advance from one _epoch_ to another and the cryptographic state of the group evolves. The group is represented using a _ratchet tree_, which represents the members as the leaves of a tree.  It is used to efficiently encrypt to subsets of the members.  Each member has a _LeafNode_ object in the tree holding the client's identity, credentials, and capabilities. Various messages are used in the evolution from epoch to epoch.  A _Proposal_ message proposes a change to be made in the next epoch, such as adding or removing a member.  A _Commit_ message initiates a new epoch by instructing members of the group to implement a collection of proposals.  Proposals and Commits are collectively called _Handshake messages_.  A _KeyPackage_ provides keys that can be used to add the client to a group, including its LeafNode, and _Signature Key_.  A _Welcome_ message provides a new member to the group with the information to initialize their state for the epoch in which they were added. Of course most (but not all) applications use MLS to send encrypted group messages.  An _application message_ is an MLS message with an arbitrary application payload. Finally, a _PublicMessage_ contains an integrity-protected MLS Handshake message, while a _PrivateMessage_ contains a confidential, integrity-protected Handshake or Application message. For a more detailed explanation of these terms, please consult the MLS protocol specification. 2.2. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and
ciphertext in the list is the encryption to the corresponding node in the resolution. <del> The ECIESCiphertext values encoding the encrypted secret values are computed as follows: Generate an ephemeral DH key pair (x, x*G) in the DH group specified by the ciphersuite in use Compute the shared secret Z with the node's other child Derive a key and nonce as described below Encrypt the node's secret value using the AEAD algorithm specified by the ciphersuite in use, with the following inputs: Key: The key derived from Z Nonce: The nonce derived from Z Additional Authenticated Data: The empty octet string Plaintext: The secret value, without any further formatting Encode the ECIESCiphertext with the following values: ephemeral_key: The ephemeral public key x*G ciphertext: The AEAD output </del> <ins> The HPKECiphertext values are computed according to the Encrypt function defined in HPKE. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted
The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the current state using the Add message.  This information is encrypted <del> for the new member using ECIES.  The recipient key pair for the ECIES </del> <ins> for the new member using HPKE.  The recipient key pair for the HPKE </ins> encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite.
simply copy all fields except the "leaf_secret" from its GroupState object. <del> [[ OPEN ISSUE: The Welcome message needs to be sent encrypted for the new member.  This should be done using the public key in the UserInitKey, either with ECIES or X3DH. ]] </del> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the Add succeeds, and is not in conflict with another, simultaneous Add.
An asymmetric public key <del> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </del> <ins> The contents of the parent are based on the latest-updated child. Nodes in a tree are always updated along the "direct path" from a leaf to the root.  The generator of the update chooses a random secret value "path_secret[0]", and generates a sequence of "path secrets", one for each node from the leaf to the root.  That is, path_secret[0] is used for the leaf, path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding node, from which the node's key pair is derived. </ins> <del> The contents of a parent node are computed from one of its children as follows: </del> <ins> For example, suppose there is a group with four participants: </ins> <del> The contents of the parent are based on the latest-updated child. For example, if participants with leaf secrets A, B, C, and D join a group in that order, then the resulting tree will have the following structure: </del> <ins> If the first participant subsequently generates an update based on a secret X, then the sender would generate the following sequence of path secrets and node secrets: </ins> <del> If the first participant subsequently changes its leaf secret to be X, then the tree will have the following structure. </del> <ins> After the update, the tree will have the following structure, where "ns[i]" represents the node_secret values generated as described above: </ins> 5.3.
Removing a member. <del> Before the initialization of a group, clients publish UserInitKey </del> <ins> Before the initialization of a group, clients publish ClientInitKey </ins> objects to a directory provided to the Messaging Service. When a client A wants to establish a group with B and C, it first <del> downloads UserInitKeys for B and C.  It then initializes a group state containing only itself and uses the UserInitKeys to compute </del> <ins> downloads ClientInitKeys for B and C.  It then initializes a group state containing only itself and uses the ClientInitKeys to compute </ins> Welcome and Add messages to add B and C, in a sequence chosen by A. The Welcome messages are sent directly to the new members (there is no need to send them to the group).  The Add messages are broadcasted
update its state to reflect their addition. Subsequent additions of group members proceed in the same way.  Any <del> member of the group can download an UserInitKey for a new client and broadcast an Add message that the current group can use to update </del> <ins> member of the group can download an ClientInitKey for a new client and broadcast an Add message that the current group can use to update </ins> their state and the new client can use to initialize its state. To enforce forward secrecy and post-compromise security of messages,
In order to facilitate asynchronous addition of clients to a group, it is possible to pre-publish initialization keys that provide some <del> public information about a user.  UserInitKey messages provide </del> <ins> public information about a user.  ClientInitKey messages provide </ins> information about a client that any existing member can use to add this client to the group asynchronously. <del> A UserInitKey object specifies what ciphersuites a client supports, </del> <ins> A ClientInitKey object specifies what ciphersuites a client supports, </ins> as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number <del> of times, potentially once. (see init-key-reuse).  UserInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given UserInitKey object among the set of UserInitKeys created by this client. </del> <ins> of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. </ins> The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for
and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A <del> UserInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.
needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated UserInitKey, </del> <ins> encryption is the one included in the indicated ClientInitKey, </ins> corresponding to the indicated ciphersuite. In the description of the tree as a list of nodes, the "credential"
If the "index" value is equal to the size of the group, increment the size of the group, and extend the tree accordingly <del> Verify the signature on the included UserInitKey; if the signature verification fails, abort </del> <ins> Verify the signature on the included ClientInitKey; if the signature verification fails, abort </ins> Generate a WelcomeInfo object describing the state prior to the add, and verify that its hash is the same as the value of the
direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the UserInitKey in the Add </del> <ins> containing the public key from the ClientInitKey in the Add </ins> corresponding to the ciphersuite in use, as well as the credential <del> under which the UserInitKey was signed </del> <ins> under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.
For application messages, a chain of keys is derived for each sender in a similar fashion.  This allows forward secrecy at the level of application messages within and out of an epoch.  A step in this <del> chain (the second subscript) is called a "generation". As before the value [sender] represents the index of the member that will use this key to send, encoded as a uint32. [[ OPEN ISSUE: The HKDF context field is left empty for now.  A proper security study is needed to make sure that we do not need more information in the context to achieve the security goals.]] [[ OPEN ISSUE: At the moment there is no contributivity of Application secrets chained from the initial one to the next generation of Epoch secret.  While this seems safe because cryptographic operations using the application secrets can't affect the group init_secret, it remains to be proven correct. ]] The following rules apply to the usage of the secrets, keys, and nonces derived above: Senders MUST only use a given secret once and monotonically increment the generation of their secret.  This is important to provide Forward Secrecy at the level of Application messages.  An attacker getting hold of a member specific Application Secret at generation [N+1] will not be able to derive the member's Application Secret [N] nor the associated AEAD key and nonce. Receivers MUST delete an Application Secret once it has been used to derive the corresponding AEAD key and nonce as well as the next Application Secret.  Receivers MAY keep the AEAD key and nonce around for some reasonable period. Receivers MUST delete AEAD keys and nonces once they have been used to successfully decrypt a message. </del> <ins> chain (the second subscript) is called a "generation".  The details of application key derivation are described in the astree section below. </ins> 7.
tree of Application Secrets as well as one symmetric ratchet per group member. <del> Each client maintains their own local copy of (parts of) the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. </del> <ins> Each client maintains their own local copy of the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. </ins> Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated <del> with the MLS ciphersuite.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </del> <ins> with the MLS ciphersuite using the common framing mechanism.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </ins> 11.1. <del> The Application schedule begins with the Application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree. Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </del> <ins> The application key schedule begins with the application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree.  Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </ins> Each node in the tree is assigned a secret.  The root's secret is simply the application_secret of that epoch.  (See key-schedule for
The secret of any other node in the tree is derived from its parent's secret using a call to Derive-App-Secret. <del> If N is a node index in the ASTree then the secrets of the children </del> <ins> If N is a node index in the AS Tree then the secrets of the children </ins> of N are defined to be: <del> Note that fixing concrete values for GroupState_[n] and </del> <ins> Note that fixing concrete values for GroupContext_[n] and </ins> application_secret completely defines all secrets in the AS Tree. 11.2.