jiebi/CodeConvo huggingface dataset:
Change:
At first I was going to make an extension for both KeyPackages and LeafNodes. But I was thinking and couldn't come up with a reason for KeyPackages to need this extension, so did just LeafNode.
Interim 2022-05-26: Agreement to merge is getting used a lot, so maybe or ? NAME to change to
What's the use case for this?
Mentioned at the last interim, but the use-case for this feature is either: giving applications an easier way to lookup the private key corresponding to their LeafNode giving applications a place to put client UUIDs

Discussion:
those devices' clients could all present the user's application-layer identifiers. <del> If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode objects. </del> <ins> If needed, applications may add application-specific identifiers to the "extensions" field of a LeafNode object with the "application_id" extension. However, applications SHOULD NOT rely on the data in an "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique. </ins> 7.

Verify that the value of "leaf_node.encryption_key" is different from the value of the "init_key" field. <del> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows applications to add an explicit, application-defined identifier to a KeyPackage. </del> 12. A group is always created with a single member, the "creator".  The
Change:
In , it was pointed out that we previously had a clause: But this was amplified in to say that we also can't send Add proposals for users that are already in the group. I think we should talk about if this is the actual desired behavior or not.
I agree with Brendan. Specifically I want to make sure an MLS client can replace itself. My other concern is that because we have no guidance yet on identity, we need to make sure that multiple instances/clients of the same user are allowed.
Interim 2022-05-26: We want to: Avoid having multiple appearances of the same device Allow a device to resync itself Text at issue here is "An Add proposal is invalid if ... The Credential in the KeyPackage represents a client already in the group according to the application" It sounds like changing to "... The KeyPackage represents a client already in the group according to the application" would address the immediate concern NAME to write a PR

Discussion:
An Add proposal requests that a client with a specified KeyPackage be added to the group. <del> An Add proposal is invalid if any of the following is true: The KeyPackage is invalid according to keypackage-validation. The Credential in the KeyPackage represents a client already in the group according to the application. </del> <ins> An Add proposal is invalid if the KeyPackage is invalid according to keypackage-validation. </ins> An Add is applied after being included in a Commit message.  The position of the Add in the list of proposals determines the leaf node

It contains multiple Add proposals that contain KeyPackages that represent the same client according to the application (for <del> example, identical KeyPackages or KeyPackages sharing the same Credential). </del> <ins> example, identical signature keys). It contains an Add proposal with a KeyPackage that represents a client already in the group according to the application, unless there is a Remove proposal in the list removing the matching client from the group. </ins> It contains multiple PreSharedKey proposals that reference the same PreSharedKeyID.
Change:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.

Discussion:
(see external-senders-extension).  The "content_type" of the message MUST be "proposal". <del> "new_member": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". </del> <ins> "new_member_commit": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". "new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The "content_type" of the message MUST be "proposal"and the "proposal_type" of the Proposal MUST be "add". </ins> Recipients of an MLSMessage MUST verify the signature with the key depending on the "sender_type" of the sender as described above.

13.1.8. Add and Remove proposals can be constructed and sent to the group by <del> a party that is outside the group, indicated by an "external" SenderType.  This is useful in cases where, for example, an automated 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 </del> <ins> a party that is outside the group in two cases.  One case, indicated by an "external" SenderType is useful in cases where, for example, an automated 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 </ins> member to a group representing a real-world team. ReInit proposals can also be sent to the group by an "external"

to the clients within a group and can only be used if the "external_senders" extension is present in the group's GroupContext. <ins> The other case, indicated by a "new_member_proposal" SenderType is useful when existing members of the group can independently authorize the addition of an MLS client proposing it be added to the group. External proposals which are not authorized are considered invalid. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an MLSCiphertext object.

the external init secret as described in external-initialization. The sender type for the MLSPlaintext encapsulating the External <del> Commit MUST be "new_member" </del> <ins> Commit MUST be "new_member_commit" </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's
Change:
The current resolution example tree can't be created by the protocol. If C were not blank, then D would not populate Z in its filtered direct path. (Note that this implies that there are never unmerged leaves at the first level of the tree.) This PR expands the example tree so that it can have unmerged leaves while still having a blank top node. This makes the example a little more complicated (you have to follow the recursion down two levels), but it doesn't seem too bad.
cc NAME
Good catch! It's kind of subtle in this case.
NAME - I think I have this patched up, would appreciate a quick re-review.
I walked through the example tree on a whiteboard with different colored markers and it looks correct to me.

Discussion:
In this tree, we can see all of the above rules in play: <del> The resolution of node Z is the list [Z, C] </del> <ins> The resolution of node X is the list [X, B] </ins> <del> The resolution of leaf 1 is the empty list [] </del> <ins> The resolution of leaf 2 or leaf 6 is the empty list [] </ins> <del> The resolution of top node is the list [A, Z, C] </del> <ins> The resolution of top node is the list [X, B, Y, H] </ins> 5.1.2.
Change:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better

Discussion:
The fields in this state have the following semantics: <ins> The "cipher_suite" is the cipher suite used by the group. </ins> The "group_id" field is an application-defined identifier for the group.

steps: Verify that the ciphersuite and protocol version of the KeyPackage <del> match those in use in the group. </del> <ins> match those in the "GroupContext". </ins> Verify that the "leaf_node" of the KeyPackage is valid for a KeyPackage according to leaf-node-validation.

the external init secret as described in external-initialization. The sender type for the MLSAuthenticatedContent encapsulating the <del> External Commit MUST be "new_member_commit " </del> <ins> External Commit MUST be "new_member_commit". </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's

Verify that the "group_id" is unique among the groups that the client is currently participating in. <ins> Verify that the "cipher_suite" in the GroupInfo matches the "cipher_suite" in the KeyPackage. </ins> Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the
Change:
Constructed from the highlights of PR titles, with breaking changes indicated with as usual.
Just filing this so that I don't forget it before posting the draft.
Fixed by

Discussion:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-15 Include ciphersuite in group context (*) Add new new_proposal_member SenderType (*) Always use a full tree (*) Change KeyPackage identifier extension to be LeafNode identifier (*) Use new tree for context in path secret encryption (*) Use a hash function for hash identifiers (*) Add a marker byte to tree hash input structs (*) Recommend that group ids are generated randomly (*) Update external senders extension to have SignaturePublicKey and Credential (*) Replace LeafNodeRef with leaf index (*) Remove AppAck proposal (*) Make padding arbitrary-size and all-zero (*) Require that unmerged_leaves be ordered Derive the commit secret from the end of the UpdatePath, not the root Specify the precise points in the protocol where credential validation must be done Make PSK provisions more uniform, e.g., always generating a fresh random nonce Improve parent hash guarantees with stricter checks on tree correctness Streamline some structs, e.g., folding GroupContext into GroupInfo Provide clearer rules for validating and applying commits Clarify tree hash and parent hash, and correct examples Clean up struct names and references to outdated structs Cite AEAD limits draft </ins> draft-14 Ensure that a signature public key is always intelligible (*)
Change:
There is no reason for the members of a conversation to keep the whole history of group operations, but they should agree on it.

Discussion:
The "epoch" field increments by one for each GroupOperation that is processed <del> The "transcript" is updated by a GroupOperation message "operation" by appending "operation" to "transcript" </del> <ins> The "transcript_hash" is updated by a GroupOperation message "operation" in the following way: When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero vector of length Hash.length. </ins> 5.6.
Change:
Early review from IANA indicated that we had not completed the . This PR adds the missing fields.

Discussion:
over arbitrary lower layer protocols.  The security considerations in this document (RFC XXXX) also apply. <ins> N/A RFC XXXX MLS-based messaging applications N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A IETF MLS Working Group mls@ietf.org [3] COMMON N/A IETF MLS Working Group IESG No </ins> 18.  References 18.1.  URIs

[1] mailto:mls-reg-review@ietf.org [2] mailto:iesg@ietf.org <ins> [3] mailto:mls@ietf.org </ins>
Change:
The part about doing the lookup in the old tree was added in , it was relevant here because of the hash references. This is not a problem anymore since we came back to referencing with leaf index.

Discussion:
A member of the group applies a Remove message by taking the following steps: <del> Identify a leaf node matching "removed".  This lookup MUST be done on the tree before any non-Remove proposals have been applied (the "old" tree in the terminology of commit), since proposals such as Update can change the LeafNode stored at a leaf.  Let L be this leaf node. </del> <ins> Identify the leaf node matching "removed".  Let L be this leaf node. </ins> Replace the leaf node L with a blank node
Change:
For consistency with references to other extensions (and with the IANA registry), refer to the extension as "external_pub".

Discussion:
external public key In other words, to join a group via an External Commit, a new member <del> needs a GroupInfo with an "ExternalPub" extension present in its </del> <ins> needs a GroupInfo with an "external_pub" extension present in its </ins> "extensions" field. Thus, a member of the group can enable new clients to join by making
Change:
... by just importing the . NAME lmk if you think we should reference instead.
The consensus in saag was to expand Recommended to include "D" to RFC 8447bis. Should probablly do the same here.

Discussion:
Name: The name of the ciphersuite <ins> [[ RFC EDITOR: This section should be the same as the corresponding text in draft-ietf-tls-rfc8447bis.  Please align the two documents if they have diverged in the approval process. ]] </ins> Recommended: Whether support for this ciphersuite is recommended <del> by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> by the IETF MLS WG.  Valid values are "Y", "N", and "D", as described below.  The default value of the "Recommended" column is "N".  Setting the Recommended item to "Y" or "D", or changing a item whose current value is "Y" or "D", requires Standards Action RFC8126. Y: Indicates that the IETF has consensus that the item is RECOMMENDED.  This only means that the associated mechanism is fit for the purpose for which it was defined.  Careful reading of the documentation for the mechanism is necessary to understand the applicability of that mechanism.  The IETF could recommend mechanisms that have limited applicability, but will provide applicability statements that describe any limitations of the mechanism or necessary constraints on its use. N: Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism.  This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an items marked as "N" on the basis of it having limited applicability or usage constraints. D: Indicates that the item is discouraged and SHOULD NOT or MUST NOT be used.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. </ins> Reference: The document where this ciphersuite is defined
Change:
made me realize that BasicCredential actually doesn't exist anymore!
Well, "basic" is listed as a credential type in the IANA registry defined in . That said, your proposed text seems perfectly consistent with the registry and the rest of the document.

Discussion:
application to supply a "reference identifier" for the authenticated client, if any. <del> A BasicCredential is a bare assertion of an identity, without any </del> <ins> A "basic" credential is a bare assertion of an identity, without any </ins> additional information.  The format of the encoded identity is defined by the application.
Change:
Need some actual values here for interop. Signature scheme values are a subset of those in RFC 8446. NAME - Do you think we should go ahead and define the higher-security-level ciphersuites as well as signature algorithms?
Looks good to me! We can always re-introduce Ed448 with X448 later.

Discussion:
Public keys used in the protocol are opaque values in a format defined by the ciphersuite, using the following types: <ins> Cryptographic algorithms are indicated using the following types: </ins> 5.5.1. This ciphersuite uses the following primitives:
Change:
This PR addresses two outstanding issues with Welcome messages: Welcome messages were not encrypted for the new member, so that the information in them (in particular, init secrets) were not appropriately protected. The protocol overview had not been updated to include the Welcome-based add flow.
This was resolved in , but recording it in this issue for posterity. A Welcome message carries the value for the group, and so it needs to be encrypted for the new joiner. The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext, and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message.

Discussion:
When a participant A wants to establish a group with B and C, it first downloads InitKeys for B and C.  It then initializes a group <del> state containing only itself and uses the InitKeys to compute Add messages to add B and C, in a sequence chosen by A.  These messages are broadcasted to the Group, and processed in sequence by B and C. Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </del> <ins> state containing only itself and uses the InitKeys to compute 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 to the Group, and processed in sequence by B and C.  Messages received before a participant has joined the group are ignored.  Only after A has received its Add messages back from the server does it update its state to reflect their addition. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download an InitKey for a new participant and

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). </del> <ins> 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. </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

The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the <del> current state using the Add message: </del> <ins> current state using the Add message.  This information is encrypted for the new member using ECIES.  The recipient key pair for the ECIES encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite. </ins> Note that the "init_secret" in the Welcome message is the "init_secret" at the output of the key schedule diagram in key-
Change:
This PR fixes several small issues I encountered while bringing my implementation more up to date. When I changed to allow blanks in the tree, I failed to update accordingly Credentials should dictate what signature scheme they will be used with, and once that's the case, we no longer need to indicate what algorithm is in use in cases where the signer's credential is known should come with a credential, not just a public key The confirmation value is easier to parse as an opaque vector value than as an array whose size depends on the ciphersuite in use

Discussion:
A member of a group authenticates the identities of other participants by means of credentials issued by some authentication system, e.g., a PKI.  Each type of credential MUST express the <del> holder's identity as well as the public key of a signature key pair that the holder of the credential will use to sign MLS messages. </del> <ins> following data: The public key of a signature key pair The identity of the holder of the private key The signature scheme that the holder will use to sign MLS messages </ins> Credentials MAY also include information that allows a relying party to verify the identity / signing key binding.
Change:
Looking at the signature and confirmation calculations in the current draft and comparing them to TLS, things seemed a bit complicated. In TLS, we have the following: This PR implements an analogous computation for MLS, where the signature in a message covers the transcript hash in the latest group state (which includes any changes to the roster ~ Certificate), and the confirmation MAC covers the transcript hash, plus the signature (i.e., the contents of CertificateVerify).
Merging this despite CI failures because they seem to be spurious.

Discussion:
If the the above checks are successful, consider the updated GroupState object as the current state of the group. <del> The "finished_mac" value is computed over the provisional group state and the current handshake message (with the confirmation value set to zero): </del> <ins> The "signature" and "confirmation" values are computed over the transcript of group operations, using the transcript hash from the provisional GroupState object: </ins> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. <ins> Sign uses the signature algorithm indicated by the signer's credential in the roster. </ins> [[ OPEN ISSUE: The Add and Remove operations create a "double-join" situation, where a participants leaf key is also known to another
Change:
This PR fixes some minor issues with the presentation language. Moving and to their own block is required so that the can now detect them.

Discussion:
To disambiguate different signatures used in MLS, each signed value is prefixed by a label as shown below: <ins> Where SignContent is specified as: And its fields set to: </ins> Here, the functions "Signature.Sign" and "Signature.Verify" are defined by the signature algorithm.

and Commits refer to Proposals they cover.  These identifiers are computed as follows: <ins> Where RefHashInput is defined as: And its fields set to: </ins> For a KeyPackageRef, the "value" input is the encoded KeyPackage, and the ciphersuite specified in the KeyPackage determines the KDF used. For a ProposalRef, the "value" input is the MLSAuthenticatedContent