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

Commentary: This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ... 
 I would be happier if this PR were moving the draft to use draft - barnes - cfrg - hpke , which is one of the changes I had in mind for  . Do you think that 's premature ? 
 This text is wrong : 
 This could also be addressed by using draft - barnes - cfrg - hpke . 
 This has been fixed by 
 Enable , e.g. , P-256 with both AES - GCM and ChaChaPoly Re - use code points from TLS 
 We should discuss that today
Paragraph (version B):
The HPKECiphertext values are computed according to the Encrypt
function defined in HPKE.
Paragraph (version A):
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
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.
Paragraph (version B):
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
for the new member using HPKE.  The recipient key pair for the HPKE
encryption is the one included in the indicated UserInitKey,
corresponding to the indicated ciphersuite.
Draft: draft-ietf-mls-protocol

Commentary: For now , I 've only touched the sections until the " Cryptographic Objects " section , which seems to be outdated anyway . Once those are updated at some point , I 'm happy to help moving from hashing to KDF - derivation there as well . 
 Thanks  ! : )
Paragraph (version A):
The private key and public key for a node are derived from its secret
value using the Derive-Key-Pair operation.
Paragraph (version B):
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.
Draft: draft-ietf-mls-protocol

Commentary: Right now , we blank out leaf nodes when we remove their holders , but we never reduce the size of   or repopulate interior blanks with new members . This PR adds those functions : Reduce the size of the tree and the roster when you remove from the right edge Add an field to the message , to enable new members to be to blank slots in the tree , not just at the right edge . In addition to performing " garbage collection " , this change should make it easier to do a state resync -- just remove the desync'ed endpoint and add them back in the same spot . 
 Do you think this is ready to merge ? say it 's OK as long as we can convince ourselves that truncation preserves the tree invariant . Proof sketch : The tree invariant is a universal statement over nodes in the tree and members in the group : ! Since subtrees are just subsets of the set of nodes in the tree , if the tree invariant holds for a given tree , then it also holds for any subtree of that tree . So since truncation just moves from a tree to a subtree , the invariant continues to hold . 
 Currently , the tree only ever grows : When you add someone , you have to add them at the right edge , even if there are blank leaves When you remove someone , the tree never shrinks We should enable reclaiming of blank leaves and automatically reduce the size of the tree to the minimum necessary size . 
 After discussion at 2019 - 01 interim : Agreement that this seems OK as long as we can verify that the tree invariant holds when you truncate the tree .
Paragraph (version B):
The "index" field indicates where in the tree the new member should
be added.  The new member can be added at an existing, blank leaf
node, or at the right edge of the tree.  In any case, the "index"
value MUST satisfy "0 <= index <= n", where "n" is the size of the
group.  The case "index = n" indicates an add at the right edge of
the tree).  If "index < n" and the leaf node at position "index" is
not blank, then the recipient MUST reject the Add as malformed.
Draft: draft-ietf-mls-protocol

Commentary: 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 .
Paragraph (version A):
HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use.
Paragraph (version B):
HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use.
Sign uses the signature algorithm indicated by the signer's
credential in the roster.
Draft: draft-ietf-mls-protocol

Commentary: 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
Paragraph (version A):
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
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.
Credentials MAY also include information that allows a relying party
to verify the identity / signing key binding.
Paragraph (version B):
Credentials MAY also include information that allows a relying party
to verify the identity / signing key binding.
Draft: draft-ietf-mls-protocol

Commentary: Add note that new clients should send an update to preserve efficiency of the protocol .
Paragraph (version B):
On receipt of an Add message, new participants SHOULD send an update
immediately to their key.  This will help to limit the tree structure
degrading into subtrees, and thus maintain the protocol's efficiency.
Draft: draft-ietf-mls-protocol

Commentary: There is no reason for the members of a conversation to keep the whole history of group operations , but they should agree on it .
Paragraph (version B):
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.
Draft: draft-ietf-mls-protocol

Commentary: At the MLS interim , the major feedback regarding authentication was that it would be good practice to provide explicit key confirmation . This PR adds an explicit confirmation field to Handshake messages , containing a MAC over the proposed ( updated ) state of the group , together with the latest handshake message . 
 Reflecting on offline conversation here : This PR derives a new key , then calculates the MAC over both the HS message and the group state ; that others verify . PR 72 derives a new key , then sends that to the others to verify they all got the same key . We assume that , as the key was derived from a tree with this group state , it must be correct . These appear to test basically the same property , but I probably prefer this PR unless we can formally verify that they have the same properties ( or at least the relevant ones ) ; in which case 72 is a little more efficient . 
 So one question would be under what circumstances would this verify something that wo n't be verified by failing AEAD on any associated messages that decrypt ? Or is it more just that we 've now decoupled updates and message sending , so without a failing AEAD we need this to confirm too ? 
 Thanks , Absolutely agree that this needs more discussion . I 'll send a ping on the list shortly . 
 To answer your question , yes , the idea here is to fail before you get to the AEAD stage . In the spec before this PR merged , group members that arrived at different states would have different keys , but they would never find out that was the case until there was an AEAD failure . With this PR ( or ) , a peer know that if processing of a Handshake message succeeds , then it has the same GroupState as the sender . 
 Agreed that we need further discussion with academics , and modelling of the properties , but this seems good to provisionally merge .
Paragraph (version A):
Use the "operation" message to produce an updated GroupState
object incorporating the proposed changes.
Paragraph (version B):
Use the "operation" message to produce an updated, provisional
GroupState object incorporating the proposed changes.
Paragraph (version A):
If the signature verifies successfully, consider the updated
GroupState object as the current state of the group.
Paragraph (version B):
Use the "confirmation_key" for the new group state to compute the
finished MAC for this message, as described below, and verify that
it is the same as the "finished_mac" field.
Paragraph (version B):
If the the above checks are successful, consider the updated
GroupState object as the current state of the group.
Paragraph (version B):
HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use.
Draft: draft-ietf-mls-protocol

Commentary: Including the " new " 2119 paragraph .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Draft: draft-ietf-mls-protocol

Commentary: Hi  ! Would you mind please revert the last of the 3 changes . Even though the sentence is not amazing and your change correct , I find it better to keep explicit the fact that the root should not be included , instead of having to infer it from the fact it has no siblings :) Thanks ! 
 You do n't have to infer it -- direct paths are defined to never include the root node in the sentence just before .
Paragraph (version A):
To enforce forward secrecy and post-compromise security of messages,
each participant periodically updates its leaf secret which
represents its contribution to the group secret.  Any member of the
group can send an Update at any time by generating fresh leaf secret
and keys and send an Update message that describes how to update the
group secret with that new information.  Once all participants have
processed this message, the group's secrets will be unknown to an
attacker that had compromised the sender's prior leaf secret.
Paragraph (version B):
To enforce forward secrecy and post-compromise security of messages,
each participant periodically updates its leaf secret which
represents its contribution to the group secret.  Any member of the
group can send an Update at any time by generating a fresh leaf
secret and sending an Update message that describes how to update the
group secret with that new information.  Once all participants have
processed this message, the group's secrets will be unknown to an
attacker that had compromised the sender's prior leaf secret.
Paragraph (version A):
A _subtree_ of a tree is the tree given by the descendants of any
node, the _head_ of the subtree The _size_ of a tree or subtree is
the number of leaf nodes it contains.  For a given parent node, its
_left subtree_ is the subtree with its left child as head
(respectively _right subtree_).
Paragraph (version B):
A _subtree_ of a tree is the tree given by the descendants of any
node, the _head_ of the subtree.  The _size_ of a tree or subtree is
the number of leaf nodes it contains.  For a given parent node, its
_left subtree_ is the subtree with its left child as head
(respectively _right subtree_).
Paragraph (version A):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node with the direct path of its parent.
The _copath_ of a node is the list of siblings of nodes in its direct
path, excluding the root, which has no sibling.  The _frontier_ of a
tree is the list of heads of the maximal full subtrees of the tree,
ordered from left to right.
Paragraph (version B):
The _direct path_ of a root is the empty list, and of any other node
is the concatenation of that node with the direct path of its parent.
The _copath_ of a node is the list of siblings of nodes in its direct
path.  The _frontier_ of a tree is the list of heads of the maximal
full subtrees of the tree, ordered from left to right.
Draft: draft-ietf-mls-protocol

Commentary: This matches the behavior in TLS , and saves space ( due to not having to send the nonce ) . 
 Merging based on r+ from out of band
Paragraph (version B):
Note that in TreeKEM, the length of the "node\_secrets" vector MUST
be exactly one less than the length of the "nodes" vector, since the
secret value for the leaf node is not encrypted.  For "i > 0",
"node_secrets[i-1]" has the encrypted node secret corresponding to
the public key in "nodes[i]".
Draft: draft-ietf-mls-protocol

Commentary: Thanks !
Paragraph (version A):
We use the TLS presentation language I-D.ietf-tls-tls13 to describe
the structure of protocol messages.
Paragraph (version B):
We use the TLS presentation language RFC8446 to describe the
structure of protocol messages.
Draft: draft-ietf-mls-protocol

Commentary: Note : If you have an existing clone , you will need to delete at the root level of the clone in order for to work . ( will still work fine )
Paragraph (version A):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub.  Suggested changes should be submitted
as pull requests at https://github.com/ekr/mls-protocol.
Instructions are on that page as well.  Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the MLS mailing list.
Paragraph (version B):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub.  Suggested changes should be submitted
as pull requests at https://github.com/mlswg/mls-protocol.
Instructions are on that page as well.  Editorial changes can be
managed in GitHub, but any substantive change should be discussed on
the MLS mailing list.
Draft: draft-barnes-mls-protocol

Commentary: It first reads as if MLS allows groups to communicate with each other , which I do n't think is the intent . 
 Thanks  ;)
Paragraph (version A):
Groups of agents who want to send each other encrypted messages need
a way to derive shared symmetric encryption keys.  For two parties,
this problem has been studied thoroughly, with the Double Ratchet
emerging as a common solution doubleratchet signal.  Channels
implementing the Double Ratchet enjoy fine-grained forward secrecy as
well as post-compromise security, but are nonetheless efficient
enough for heavy use over low-bandwidth networks.
Paragraph (version B):
A group of agents who want to send each other encrypted messages
needs a way to derive shared symmetric encryption keys.  For two
parties, this problem has been studied thoroughly, with the Double
Ratchet emerging as a common solution doubleratchet signal.  Channels
implementing the Double Ratchet enjoy fine-grained forward secrecy as
well as post-compromise security, but are nonetheless efficient
enough for heavy use over low-bandwidth networks.
Draft: draft-barnes-mls-protocol

Commentary: We should probably have this cited there , as the security proof is pretty core to things .
Paragraph (version A):
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security.  The use of "asynchronous ratcheting trees"
allows the members of the group to derive and update shared keys with
costs that scale as the log of the group size.  The use of Merkle
trees to store identity information allows strong authentication of
group membership, again with logarithmic cost.
Paragraph (version B):
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security.  The use of "asynchronous ratcheting trees"
 allows the members of
the group to derive and update shared keys with costs that scale as
the log of the group size.  The use of Merkle trees to store identity
information allows strong authentication of group membership, again
with logarithmic cost.
Draft: draft-barnes-mls-protocol

Commentary: Noticed some bugs in the spec as I was working on aligning the Go implementation .
Paragraph (version A):
The derivation of the epoch key pair depends on the change being
made.  For the first epoch, when there is no previous epoch key pair,
the creator of the group generates a fresh key pair and publishes it
to the initial set of participants.
Paragraph (version B):
The derivation of the update secret depends on the change being made,
as described below.
Paragraph (version B):
For adds, the new user does not know the prior epoch init secret.
Instead, entropy from the prior epoch is added via the update secret,
and an all-zero vector with the same length as a hash output is used
in the place of the init secret.
Paragraph (version A):
The head field in the Delete message holds the public keys
corresponding to the subtree heads.  The path field holds the public
keys corresponding to the delete path, with the last element omitted
(it is unnecessary).  As a result, the heads and path arrays MUST
have the same length.
Paragraph (version A):
Note that the sender of a Delete message must enough information
about the ratchet tree so that it has all of the subtree heads
resulting from the delete operation.  This criterion is met if the
sender has a copath for each of the deleted participants.
Paragraph (version A):
The update secret for this change is the last DH output from the
delete path.
Paragraph (version B):
The update secret resulting from this change is the secret for the
root node of the ratchet tree after both updates.
Paragraph (version A):
Prekeys are intended to be used only once and then deleted.  Reuse of
prekeys is not believed to be inherently insecure dhreuse, although
it can complicate protocol analyses.
Paragraph (version B):
Initialization keys are intended to be used only once and then
deleted.  Reuse of init keys is not believed to be inherently
insecure dhreuse, although it can complicate protocol analyses.
Draft: draft-barnes-mls-protocol

Commentary: Prose for how ratchet trees work .
Paragraph (version B):
Ratchet trees are used for generating the shared group secrets.
These are constructed as a series of Diffie-Hellman keys in a binary
tree arrangement, with each user knowing their direct path, and thus
being able to compute the shared root secret.
Paragraph (version B):
Ratchet trees are constructed as left-balanced trees, defined such
that each parent node's key pair is derived from the Diffie-Hellman
shared secret of its two child nodes.  To compute the root key pair,
a participant must know the public keys of nodes in its own copath,
as well as its own leaf private key.
Paragraph (version B):
Ratchet trees constructed this way provide the property that one must
hold at least one private key from the tree to compute the root key.
With all participants holding one leaf private key; this allows any
individual to update their own key and change the shared root key,
such that only group members can compute the new key.