jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-mls-protocol

Commentary: draft-08 is the latest HPKE draft , which should be stable . It is also what 's being used for interop testing right now . 
 Discussed Interim : Merge .
Paragraph (version A):
MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key
encryption.  The "DeriveKeyPair" function associated to the KEM for
the ciphersuite maps octet strings to HPKE key pairs.
Paragraph (version B):
MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key
encryption.  The "DeriveKeyPair" function associated to the KEM for
the ciphersuite maps octet strings to HPKE key pairs.
Draft: draft-ietf-mls-protocol

Commentary: I noticed a bunch of typos in the " IANA Considerations " section : the " ciphersuites " and " credentials " were probably copy - pasted from the " extension " one , and some parts were not changed correctly . This PR fixes these typos . 
 Discussed Interim : editorial will be taken up by editors . 
 Thanks !
Paragraph (version B):
Recommended: Whether support for this ciphersuite is recommended
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.
Paragraph (version A):
This registry lists identifiers for types of credentials that can be
used for authentication in 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):
This registry lists identifiers for types of credentials that can be
used for authentication in the MLS protocol.  The credential type
field is two bytes wide, so valid credential type values are in the
range 0x0000 to 0xffff.
Paragraph (version B):
Recommended: Whether support for this credential is recommended 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.
Draft: draft-ietf-mls-protocol

Commentary: Discussed at Interim . Merge . 
 Good point about allowing PSKs in a partial Commit !
Paragraph (version A):
An "add-only" Commit that references only Add proposals, in which
the path is optional.  Such a commit provides PCS with regard to
the committer only if the path field is present.
Paragraph (version B):
A "partial" Commit that references Add, PreSharedKey, or ReInit
proposals but where the path is empty.  Such a commit doesn't
provide PCS with regard to the committer.
Draft: draft-ietf-mls-protocol

Commentary: Interim : To be reviewed by editors . 
 Ready to merge modulo one nit .
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
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 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 containing a set of public keys and encrypted path
secrets for intermediate nodes in the direct path of its 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 path secret value for a given node is encrypted for the subtree
corresponding to the parent's non-updated child, that is, the child
on the copath of the leaf node.  There is one encrypted path secret
for each public key in the resolution of the non-updated child.
Paragraph (version B):
The path secret value for a given node is encrypted for the subtree
corresponding to the parent's non-updated child, that is, the child
on the copath of the sender's leaf node.  There is one encryption of
the path secret to each public key in the resolution of the non-
updated child.
Draft: draft-ietf-mls-protocol

Commentary: ( see issue for details ) . 
 Currently section " 4 . Protocol Overview " states : I think this is a legacy from before the propose / commit scheme and got carried over . New members no longer need the Commit . The subsequent diagram also needs to be adapted .
Paragraph (version A):
Upon receiving the Welcome message and the corresponding Commit, the
new member will be able to read and send new messages to the group.
Messages received before the client has joined the group are ignored.
Paragraph (version A):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download a KeyPackage for a new client and
broadcast an Add message that the current group can use to update
their state, and a Welcome message that the new client can use to
initialize its state.
Paragraph (version B):
Upon receiving the Welcome message, the new member will be able to
read and send new messages to the group.  Messages received before
the client has joined the group are ignored.
Paragraph (version B):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download a KeyPackage for a new client and
broadcast an Add message that the current group can use to update
their state, and a Welcome message that the new client can use to
initialize its state and join the group.
Draft: draft-ietf-mls-protocol

Commentary: I think this word was left from previous changes to the name of this particular key .. cc./ 
 Thanks Sofía !
Paragraph (version A):
The second form of authentication is that group members can verify a
message originated from a particular member of the group.  This is
guaranteed by a digital signature on each message from the sender's
identity key.
Paragraph (version B):
The second form of authentication is that group members can verify a
message originated from a particular member of the group.  This is
guaranteed by a digital signature on each message from the sender's
signature key.
Draft: draft-ietf-mls-protocol

Commentary: use and instead of and , for consistency with the rest of the spec the key and nonce are now derived from the rather than randomly chosen
Paragraph (version A):
In order to allow the same Welcome message to be sent to all new
members, information describing the group is encrypted with a
symmetric key and nonce randomly chosen by the sender.  This key and
nonce are then encrypted to each new member using HPKE.  In the same
encrypted package, the committer transmits the path secret for the
lowest node contained in the direct paths of both the committer and
the new member.  This allows the new member to compute private keys
for nodes in its direct path that are being reset by the
corresponding Commit.
Paragraph (version B):
In order to allow the same Welcome message to be sent to all new
members, information describing the group is encrypted with a
symmetric key and nonce derived from the "joiner_secret" for the new
epoch.  The "joiner_secret" is then encrypted to each new member
using HPKE.  In the same encrypted package, the committer transmits
the path secret for the lowest node contained in the direct paths of
both the committer and the new member.  This allows the new member to
compute private keys for nodes in its direct path that are being
reset by the corresponding Commit.
Draft: draft-ietf-mls-protocol

Commentary: cc 
 is the build expected to fail ? 
 No , but the problem seem unrelated to your change , so we are all good . 
 Looks like it was a transient failure . Re - running resulted in success . 
 points out that the HPKE version is not pinned . This is probably needed for interop . Version -07 should come sometime this week , so that seems like a perfectly fine version to use . I can send a PR when that version is cut . 
 Fixed by
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 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.
Paragraph (version A):
The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke
for the purpose of public-key encryption.  The "DeriveKeyPair"
function associated to the KEM for the ciphersuite maps octet strings
to HPKE key pairs.
Paragraph (version B):
MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key
encryption.  The "DeriveKeyPair" function associated to the KEM for
the ciphersuite maps octet strings to HPKE key pairs.
Draft: draft-ietf-mls-protocol

Commentary: This is a small suggestion to move the definition of the to the end of the first Extract - Expand ( KDF ) cycle of the [ key schedule ] . This makes more sense from a cryptographic perspective as we would not be using anything from the middle of a KDF cycle . A related suggestion is to remove the from the document . I removed it from the key schedule , removed all the mentions to forget it as soon as possible and updated the description of deriving the and from the [ welcoming new members ] section . [ key schedule ] : [ welcoming new members ] : 
 Thanks for the quick fix , !
Paragraph (version A):
the "commit_secret", "joiner_secret", "member_secret",
"epoch_secret", "encryption_secret" of that epoch n as well as the
"init_secret" of the previous epoch n-1,
Paragraph (version B):
the "commit_secret", "joiner_secret", "epoch_secret",
"encryption_secret" of that epoch n as well as the "init_secret"
of the previous epoch n-1,
Paragraph (version A):
Then if a client uses key K1 and nonce N1 during epoch n then it must
consume (at least) values G, F, D, AR0, AR1, K1, N1 as well as the
key schedule secrets used to derive G (the "encryption_secret"),
namely "init_secret" of epoch n-1 and "commit_secret",
"joiner_secret", "member_secret", "epoch_secret" of epoch n.  The
client MAY retain (not consume) the values K0 and N0 to allow for
out-of-order delivery, and SHOULD retain AR2 for processing future
messages.
Paragraph (version B):
Then if a client uses key K1 and nonce N1 during epoch n then it must
consume (at least) values G, F, D, AR0, AR1, K1, N1 as well as the
key schedule secrets used to derive G (the "encryption_secret"),
namely "init_secret" of epoch n-1 and "commit_secret",
"joiner_secret", "epoch_secret" of epoch n.  The client MAY retain
(not consume) the values K0 and N0 to allow for out-of-order
delivery, and SHOULD retain AR2 for processing future messages.
Paragraph (version A):
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):
From the "joiner_secret" in the decrypted GroupSecrets object and
the PSKs specified in the "GroupSecrets", derive the
"welcome_secret" and using that the "welcome_key" and
"welcome_nonce".  Use the key and nonce to decrypt the
"encrypted_group_info" field.
Draft: draft-ietf-mls-protocol

Commentary: Thanks !
Paragraph (version A):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519" which uses
Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over
SHA2-256, AES for metadata masking, and Ed25519 for signatures.
Paragraph (version B):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses
Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over
SHA2-256, and Ed25519 for signatures.
Draft: draft-ietf-mls-protocol

Commentary: It looks like in Commit was moved to in UpdatePath , but some docs did n't get updated .
Paragraph (version A):
Construct an initial Commit object with the "proposals" field
populated from Proposals received during the current epoch, and
empty "key_package" and "path" fields.
Paragraph (version B):
Construct an initial Commit object with the "proposals" field
populated from Proposals received during the current epoch, and an
empty "path" field.
Paragraph (version A):
If populating the "path" field: Create a UpdatePath using the new
tree.  Any new member (from an add proposal) MUST be exluded from
the resolution during the computation of the UpdatePath.  The
GroupContext for this operation uses the "group_id", "epoch",
"tree_hash", and "confirmed_transcript_hash" values in the initial
GroupContext object.
Paragraph (version B):
If populating the "path" field: Create an UpdatePath using the new
tree.  Any new member (from an add proposal) MUST be exluded from
the resolution during the computation of the UpdatePath.  The
GroupContext for this operation uses the "group_id", "epoch",
"tree_hash", and "confirmed_transcript_hash" values in the initial
GroupContext object.  The "leaf_key_package" for this UpdatePath
must have a "parent_hash" extension.
Paragraph (version A):
Generate a new KeyPackage for the Committer's own leaf, with a
"parent_hash" extension.  Store it in the ratchet tree and assign
it to the "key_package" field in the Commit object.
Paragraph (version A):
Apply the UpdatePath to the tree, as described in
synchronizing-views-of-the-tree, and store "key_package" at the
Committer's leaf.
Paragraph (version B):
Apply the UpdatePath to the tree, as described in
synchronizing-views-of-the-tree, and store "leaf_key_package"
at the Committer's leaf.
Draft: draft-ietf-mls-protocol

Commentary: In preparation for feature - freeze / post - first - WGLC living , this PR removes a few issues that have been discussed and pretty much resolved . It leaves a few OPEN ISSUES that could benefit from analysis during the feature freeze .
Paragraph (version B):
It is possible for a malicious member of a group to "fragment" the
group by crafting an invalid UpdatePath.  Recall that an UpdatePath
encrypts a sequence of path secrets to different subtrees of the
group's ratchet trees.  These path secrets should be derived in a
sequence as described in ratchet-tree-evolution, but the UpdatePath
syntax allows the sender to encrypt arbitrary, unrelated secrets.
The syntax also does not guarantee that the encrypted path secret
encrypted for a given node corresponds to the public key provided for
that node.
Paragraph (version B):
Both of these types of corruption will cause processing of a Commit
to fail for some members of the group.  If the public key for a node
does not match the path secret, then the members that decrypt that
path secret will reject the commit based on this mismatch.  If the
path secret sequence is incorrect at some point, then members that
can decrypt nodes before that point will compute a different public
key for the mismatched node than the one in the UpdatePath, which
also causes the Commit to fail.  Applications SHOULD provide
mechanisms for failed commits to be reported, so that group members
who were not able to recognize the error themselves can reject the
commit and roll back to a previous state if necessary.
Paragraph (version B):
Even with such an error reporting mechanism in place, however, it is
still possible for members to get locked out of the group by a
malformed commit.  Since malformed Commits can only be recognized by
certain members of the group, in an asynchronous application, it may
be the case that all members that could detect a fault in a Commit
are offline.  In such a case, the Commit will be accepted by the
group, and the resulting state possibly used as the basis for further
Commits.  When the affected members come back online, they will
reject the first commit, and thus be unable to catch up with the
group.
Paragraph (version B):
Applications can address this risk by requiring certain members of
the group to acknowledge successful processing of a Commit before the
group regards the Commit as accepted.  The minimum set of
acknowledgements necessary to verify that a Commit is well-formed
comprises an acknowledgement from one member per node in the
UpdatePath, that is, one member from each subtree rooted in the
copath node corresponding to the node in the UpdatePath.
Draft: draft-ietf-mls-protocol

Commentary: The unsigned PublicGroupState created by leads to an attack on the new joiner . The sender of a GroupPublicState can associate any HPKE it wants with the group , and thus learn the without being a member of the group . ( The UpdatePath and the resulting partly defend against this attack , though they are subverted if the attacker has compromised any single key used in the Update Path . ) To guard against this attack , this PR adds a signature over the HPKE public key in the PublicGroupState . 
 In light of the feedback on the mailing list from re : deniability , I have upgraded this PR to sign the whole PublicGroupState . 
 Outstanding issue : One detail that is not fully covered by is the strategy new joiners should apply to determine who the latest committer is and make sure that both the and the last Commit are signed by the same member . 
 The last node to send an UpdatePath is the last one to set the root . So you can follow parent_hash to find which leaf it is . But like I said on the IETF meeting call , I do n't think we should actually require that PublicGroupState be signed by the last updater . There are possible operational / sync issues if the PublicGroupState is n't fate - shared with the Commit , but that 's a practical issue , not a security issue . And in any case , it 's not a breaking change , so we can fix it post - draft-11 if we decide we need to . 
 Please fix the link on the repo page to display diffs between the current editor 's draft and the WG draft . Now , it should PRs comparing back to the -00 version . 
 Any change you could have a look at this when you have some time ? : ) 
 Yeah , I 'm gon na fix the  and I can take a look at this as well . I tried to get it done before the interim but , well , excuses excuses 
 Ahah ... ;) No problem ! ! Thanks ! 
 -- last call on this , or i 'm just going to close it 
 Sorry . As you will have guessed , this fell through the cracks . I 'll try this week to fix it out and close it out if I do n't get to it this weekend :/
Paragraph (version A):
The information above are not deemed public data in general, but
applications can choose to make them available to new members in
order to allow External Commits.
Paragraph (version B):
This signature authenticates the HPKE public key, so that the joiner
knows that the public key was provided by a member of the group.  The
fields that are not signed are included in the key schedule via the
GroupContext object.  If the joiner is provided an inaccurate data
for these fields, then its external Commit will have an incorrect
"confirmation_tag" and thus be rejected.
Paragraph (version B):
The information in a PublicGroupState is not deemed public in
general, but applications can choose to make it available to new
members in order to allow External Commits.
Draft: draft-ietf-mls-protocol

Commentary: As discussed on 2020 - 10 - 20 , this field is not needed now that moved the signature under the confirmation tag . 
 We have a long - standing OPEN ISSUE on creating a group with a single Init message instead of N Add messages , which would change the work of initialization from O(N log N ) to O(N ) . I would propose roughly the following : Then the processing would be : Find the welcome that 's for you Initialize a one - member tree from the Welcome Use the UserInitKeys to populate the leaves of the tree Use the DirectPath to populate the creator 's direct path ( as in Update ) 
 Fixed by 
 These keys are  one - time use keys , so " UserInitKey " seems like a strange name . 
 I 'm fine with ClientInitKey , as long as a client is not only a physical endpoint . Changes in the architecture doc should make this clear soon .
Paragraph (version B):
Use the confirmed transcript hash and confirmation tag to compute
the interim transcript hash in the new state.
Draft: draft-ietf-mls-protocol

Commentary: As briefly explained in the mailing list , commit messages currently contain encryptions for newly group members that never even receive this commit message . This PR explicitely exlcudes them during the preparation of the UpdatePath . 
 I think this is a good point that was n't really specified so far . The wording sounds a bit convoluted , maybe there is an easier way to describe it , like saying that the final resolution list should be filtered and all new leaf nodes should be removed from it .
Paragraph (version A):
The number of ciphertexts in the "encrypted_path_secret" vector MUST
be equal to the length of the resolution of the corresponding copath
node.  Each ciphertext in the list is the encryption to the
corresponding node in the resolution.
Paragraph (version B):
For each "UpdatePathNode", the resolution of the corresponding copath
node MUST be filtered by removing all new leaf nodes added as part of
this MLS Commit message.  The number of ciphertexts in the
"encrypted_path_secret" vector MUST be equal to the length of the
filtered resolution, with each ciphertext being the encryption to the
respective resolution node.
Paragraph (version A):
If populating the "path" field: Create a UpdatePath using the new
tree (which includes any new members).  The GroupContext for this
operation uses the "group_id", "epoch", "tree_hash", and
"confirmed_transcript_hash" values in the initial GroupContext
object.
Paragraph (version B):
If populating the "path" field: Create a UpdatePath using the new
tree.  Any new member (from an add proposal) MUST be exluded from
the resolution during the computation of the UpdatePath.  The
GroupContext for this operation uses the "group_id", "epoch",
"tree_hash", and "confirmed_transcript_hash" values in the initial
GroupContext object.
Draft: draft-ietf-mls-protocol

Commentary: This avoids extra signatures and message overhead in the case where the committer is originating proposals .
Paragraph (version A):
On receiving an MLSPlaintext containing a Proposal, a client MUST
verify the signature on the enclosing MLSPlaintext.  If the signature
verifies successfully, then the Proposal should be cached in such a
way that it can be retrieved using a ProposalID in a later Commit
message.
Paragraph (version B):
On receiving an MLSPlaintext containing a Proposal, a client MUST
verify the signature on the enclosing MLSPlaintext.  If the signature
verifies successfully, then the Proposal should be cached in such a
way that it can be retrieved by hash (as a ProposalOrRef object) in a
later Commit message.
Paragraph (version A):
Each proposal covered by the Commit is identified by a ProposalID
value, which contains the hash of the MLSPlaintext in which the
Proposal was sent, using the hash function from the group's
ciphersuite.
Paragraph (version B):
Each proposal covered by the Commit is included by a ProposalOrRef
value, which identifies the proposal to be applied by value or by
reference.  Proposals supplied by value are included directly in the
Commit object.  Proposals supplied by reference are specified by
including the hash of the MLSPlaintext in which the Proposal was
sent, using the hash function from the group's ciphersuite.  For
proposals supplied by value, the sender of the proposal is the same
as the sender of the Commit.  Conversely, proposals sent by people
other than the committer MUST be included by reference.