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

Commentary: pointed out this disconnect in , but the fix needs to be the other way around . 
 Here 's the Weekly Digest for : - - Last week 2 issues were created . Of these , 2 issues have been closed and 0 issues are still open . : heart : , by : heart : , by - - Last week , 4 pull requests were created , updated or merged . Last week , 4 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 9 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustinsilhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
The length of the "node_secrets" vector MUST be zero for the first
node in the path.  For the remaining elements in the vector, the
number of ciphertexts in the "node_secrets" 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):
The length of the "encrypted_path_secret" vector MUST be zero for the
first node in the path.  For the remaining elements in the vector,
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.
Draft: draft-ietf-mls-protocol

Commentary: Race condition between and 
 Here 's the Weekly Digest for : - - Last week 2 issues were created . Of these , 2 issues have been closed and 0 issues are still open . : heart : , by : heart : , by - - Last week , 4 pull requests were created , updated or merged . Last week , 4 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 9 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustinsilhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
This structure incorporates everything in an MLSPlaintext up to the
confirmation field in the transcript that is included in that
confirmation field (via the GroupState).  The confirmation and
signature fields are then included in the transcript for the next
operation.  The intermediate hash enables implementations to in
corporate a plaintext into the transcript without having to store the
whole MLSPlaintextOpAuthData structure.
Paragraph (version B):
This structure incorporates everything in an MLSPlaintext up to the
confirmation field in the transcript that is included in that
confirmation field (via the GroupContext).  The confirmation and
signature fields are then included in the transcript for the next
operation.  The intermediate hash enables implementations to in
corporate a plaintext into the transcript without having to store the
whole MLSPlaintextOpAuthData structure.
Draft: draft-ietf-mls-protocol

Commentary: The underscore character does not have to be escaped in code environments . This applies to the inline ( backticks ) as well as block ( tildes ) variants . 
 Here 's the Weekly Digest for : - - Last week 2 issues were created . Of these , 2 issues have been closed and 0 issues are still open . : heart : , by : heart : , by - - Last week , 4 pull requests were created , updated or merged . Last week , 4 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 9 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustinsilhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also . 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
The length of the "node\_secrets" vector MUST be zero for the first
node in the path.  For the remaining elements in the vector, the
number of ciphertexts in the "node\_secrets" 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):
The length of the "node_secrets" vector MUST be zero for the first
node in the path.  For the remaining elements in the vector, the
number of ciphertexts in the "node_secrets" 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.
Draft: draft-ietf-mls-protocol

Commentary: Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
An agent that uses this protocol to establish shared cryptographic
state with other clients.  A client is defined by the
cryptographic keys it holds.  An application or user may use one
client per device (keeping keys local to each device) or sync keys
among a user's devices so that each user appears as a single
client.
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.  An application or user may use one
client per device (keeping keys local to each device) or sync keys
among a user's devices so that each user appears as a single
client.  In the scenario where multiple devices share the
cryptographic material the client is referred to as a "virtual"
client.
Paragraph (version A):
The group identifier and epoch allow a device to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The "sender" identifier is used to derive
the member's Application secret chain from the initial group
Application secret.  The application generation field is used to
determine which Application secret should be used from the chain to
compute the correct AEAD keys before performing decryption.
Paragraph (version B):
The group identifier and epoch allow a recipient to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The "sender" identifier is used to derive
the member's Application secret chain from the initial group
Application secret.  The application generation field is used to
determine which Application secret should be used from the chain to
compute the correct AEAD keys before performing decryption.
Draft: draft-ietf-mls-protocol

Commentary: " The update secret resulting from this change is the path secret for the root node of the ratchet tree . " is suspicious because in the derivation , the index for both the and is the same as the level of the node . It should be the " above the root " and not " for the root " ( which is the one used to derive the of the root ) ... 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
The update secret resulting from this change is an all-zero octet
string of length Hash.length.
Paragraph (version B):
The "update_secret" resulting from this change is an all-zero octet
string of length Hash.length.
Paragraph (version A):
The update secret resulting from this change is the path secret for
the root node of the ratchet tree.
Paragraph (version A):
The update secret resulting from this change is the path secret
computed for the root node of the ratchet tree in the first step.
Draft: draft-ietf-mls-protocol

Commentary: Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by - - Last week , 9 pull requests were created , updated or merged . Last week , 3 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 5 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 8 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
Note that, in step 4, there must be at least one non-null element in
the tree, since any valid GroupContext must have the current member
in the tree and self-removal is prohibited.  The same reasoning
justifies the existence of a non-blank leaf in the ratchet tree in
step 5.
Draft: draft-ietf-mls-protocol

Commentary: This clears up the wording around how to prune the ratchet tree on a  operation . Previously , it could be interpreted as " remove nodes from the tree until the rightmost node is not null " , but this is not what is intended by the authors , and it also has the ability to produce invalid trees ( i.e. , trees with an even number of elements ) . The second change is to do the truncation after doing the Blank propogation up the direct path of the removed leaf . Note that the order of these steps does n't matter in that they produce the same resulting tree . However , if we blank after pruning , an implementor would have to take care to not to try to blank out previously - removed nodes . Prune - then - blank is a little easier to reason about . The third change is a semantic fix . It is clear from the last paragraph in this section that the root node should be blanked , but the text only said to blank the direct path of the leaf , which does not include the root node . I just that part in . 
 Here 's the Weekly Digest for : - - Last week 4 issues were created . Of these , 1 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : speaker : , by It received 4 comments . - - Last week , 9 pull requests were created , updated or merged . Last week , 8 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there were 4 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version A):
A Remove message is sent by a group member to remove one or more
members from the group.
Paragraph (version B):
A Remove message is sent by a group member to remove one or more
other members from the group.  A member MUST NOT use a Remove message
to remove themselves from the group.  If a member of a group receives
a Remove message where the removed index is equal to the signer
index, the recipient MUST reject the message as malformed.
Paragraph (version B):
Note that, in step 4, there must be at least one non-null element in
the roster, since any valid GroupState must have the current member
in the roster and self-removal is prohibited.  The same reasoning
justifies the existence of a non-blank leaf in the ratchet tree in
step 5.
Draft: draft-ietf-mls-protocol

Commentary: This addresses the authentication issue in -03 noted on the mailing list .
Paragraph (version B):
The "welcome_info_hash" field contains a hash of the WelcomeInfo
object sent in a Welcome message to the new member.
Draft: draft-ietf-mls-protocol

Commentary: I 'm approving these changes given the current state of the document , but I filed because the KDF stuff is broken . Please make HPKE a normative reference ( since it 's required to implement ) . Since it 's an Internet - Draft , you do n't need to add it to the references section , you can just reference it directly as and the Markdown processor will add the reference . ( Change the to for an informative reference . )
Paragraph (version A):
A short-lived Diffie-Hellman key pair used to introduce a new
member to a group.  Initialization keys are published for
individual participants (UserInitKey).
Paragraph (version A):
A short-lived Diffie-Hellman key pair that represents a group
member's contribution to the group secret, so called because the
participants leaf keys are the leaves in the group's ratchet tree.
Paragraph (version B):
A short-lived HPKE key pair used to introduce a new member to a
group.  Initialization keys are published for individual
participants (UserInitKey).
Paragraph (version B):
A short-lived HPKE key pair that represents a group member's
contribution to the group secret, so called because the
participants leaf keys are the leaves in the group's ratchet tree.
Paragraph (version A):
The "tree" field contains the public keys corresponding to the
nodes of the ratchet tree for this group.  The length of this
vector MUST be "2*size + 1", where "size" is the length of the
roster, since this is the number of nodes in a tree with "size"
leaves, according to the structure described in ratchet-trees.
Paragraph (version B):
The "tree" field contains the public keys corresponding to the
nodes of the ratchet tree for this group.  The length of this
vector MUST be "2*size - 1", where "size" is the length of the
roster, since this is the number of nodes in a tree with "size"
leaves, according to the structure described in ratchet-trees.
Paragraph (version A):
The HPKECiphertext values are computed according to the Encrypt
function defined in HPKE.
Paragraph (version B):
The HPKECiphertext values are computed according to the Encrypt
function defined in I-D.barnes-cfrg-hpke.
Paragraph (version A):
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 DH group defined by the corresponding entry in the cipher_suites
array.
Paragraph (version B):
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 asymmetric encryption scheme defined in the cipher_suites array
and used in the HPKE construction for TreeKEM.
Draft: draft-ietf-mls-protocol

Commentary: There is no " leaf_secret " field in GroupState . While there might be one in the group state struct that the implementation maintains locally , I think it 's safe to recommend copying everything from the GroupState object as it 's defined earlier in the document .
Paragraph (version A):
Since the new member is expected to process the Add message for
itself, the Welcome message should reflect the state of the group
before the new user is added.  The sender of the Welcome message can
simply copy all fields except the "leaf_secret" from its GroupState
object.
Paragraph (version B):
Since the new member is expected to process the Add message for
itself, the Welcome message should reflect the state of the group
before the new user is added.  The sender of the Welcome message can
simply copy all fields from their GroupState object.
Draft: draft-ietf-mls-protocol

Commentary: Specify padding length Rename struct Application to ApplicationMessage
Paragraph (version A):
The signature used in the MLSPlaintext is computed over the
MLSSignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent Group participants from impersonating
other participants.  It is also necessary in order to prevent cross-
group attacks.
Paragraph (version B):
The signature used in the ApplicationMessageContent is computed over
the SignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent Group participants from impersonating
other participants.  It is also necessary in order to prevent cross-
group attacks.
Paragraph (version A):
Similarly to TLS 1.3, if padding is used, the MLS messages MUST be
padded with zero-valued bytes before AEAD encryption.  Upon AEAD
decryption, the length field of the plaintext is used to compute the
number of bytes to be removed from the plaintext to get the correct
data.  As the padding mechanism is used to improve protection against
traffic analysis, removal of the padding SHOULD be implemented in a
"constant-time" manner at the MLS layer and above layers to prevent
timing side-channels that would provide attackers with information on
the size of the plaintext.
Paragraph (version B):
Similarly to TLS 1.3, if padding is used, the MLS messages MUST be
padded with zero-valued bytes before AEAD encryption.  Upon AEAD
decryption, the length field of the plaintext is used to compute the
number of bytes to be removed from the plaintext to get the correct
data.  As the padding mechanism is used to improve protection against
traffic analysis, removal of the padding SHOULD be implemented in a
"constant-time" manner at the MLS layer and above layers to prevent
timing side-channels that would provide attackers with information on
the size of the plaintext.  The padding length length_of_padding can
be chosen at the time of the message encryption by the sender.
Recipients can calculate the padding size from knowing the total size
of the ApplicationPlaintext and the length of the content.
Draft: draft-ietf-mls-protocol

Commentary: Fix for 
 This might not be completely ideal , because of the group state but it currently does not change the key schedule , I am merging this because we need it for correct interop but feel free to get back to discuss a better way to do this in details . 
 There are at least two bugs in the message protection section that make it unimplementable : calls for , but the third argument to as defined is a , not an octet string . refers to a function , which is defined in TLS , but not here . ISTM the simplest way to fix these problems would to define and use it ( 1 ) as the basis for , ( 2 ) for deriving sender root secrets , and ( 3 ) for deriving keys and nonces . 
 Fixed by
Paragraph (version A):
Note that [sender] represent the uint32 value encoding the index of
the participant in the ratchet tree.
Paragraph (version B):
Note that [sender] represents the index of the member in the roster.