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

Commentary: I 'm not sure if this is actually necessary , but there usually seem to be issues in  trees when the leaves are not explicitly distinct from the parents . 
 I would find it nicer to describe things with a like in other parts of the protocol : It is equivalent to your modification . Stating things that way ensures there is no ambiguity : TreeHashInput is parseable , which is I think the property you want to ensure with this PR . 
 Use enum instead and then ready for merge . 
 Interim 2022 - 05 - 26 : Nicer with an to update to , then merge 
 When computing the tree hash , should there be an indicator bit for whether the value being hashed represents a leaf or parent  ? 
 This does n't seem like a terrible idea . You could either add a field to LeafNodeHashInput and ParentNodeHashInput , or define an enum and do the same , or make a . For example :
Paragraph (version A):
To allow group members to verify that they agree on the public
cryptographic state of the group, this section defines a scheme for
generating a hash value (called the "tree hash") that represents the
contents of the group's ratchet tree and the members' leaf nodes.
The tree hash of a tree is the tree hash of its root node, which we
define recursively, starting with the leaves.
Paragraph (version A):
The tree hash of a leaf node is the hash of leaf's
"LeafNodeHashInput" object which might include a "LeafNode" object
depending on whether or not it is blank.
Paragraph (version A):
Now the tree hash of any non-leaf node is recursively defined to be
the hash of its "ParentNodeHashInput".  This includes an optional
"ParentNode" object depending on whether the node is blank or not.
Paragraph (version A):
The "left_hash" and "right_hash" fields hold the tree hashes of the
node's left and right children, respectively.
Paragraph (version B):
To allow group members to verify that they agree on the public
cryptographic state of the group, this section defines a scheme for
generating a hash value (called the "tree hash") that represents the
contents of the group's ratchet tree and the members' leaf nodes.
Paragraph (version B):
The tree hash of an individual node is the hash of the node's
"TreeHashInput" object, which may contain either a
"LeafNodeHashInput" or a "ParentNodeHashInput" depending on the type
of node.  "LeafNodeHashInput" objects contain the "leaf_index" and
the "LeafNode" (if any).  "ParentNodeHashInput" objects contain the
"ParentNode" (if any) and the tree hash of the node's left and right
children.
Paragraph (version B):
The tree hash of an entire tree corresponds to the tree hash of the
root node, which is computed recursively by starting at the leaf
nodes and building up.
Draft: draft-ietf-mls-protocol

Commentary:  to revise based on Rohan suggestion . 
 Interim 2022 - 05 - 26 : Concerns around making the group_id totally random Malicious group creator can choose it malicious Federated systems get worse randomness Using AEAD.Nk depends on ciphersuite , could be awkward will revise to say : Here are the requirements that group ID must satisfy If you do n’t have an alternative plan , do it randomly 
 Group ids are signed to bind certain information to specific groups . But I can imagine a case where a user mis - uses the group i d to be something like a " room title " which lets an adversary control the group i d and introduces potential problems . If we can prove that it 's fine for a group i d to be reused , then should we get rid of group ids ? If not ( as I expect ) , then group ids need to be guaranteed to be unique [ globally per signing key ] and we need to specify that . 
 Discussed at 19 May interim . to generate PR documenting fresh random value approach . 
 Virtual interim 2022 - 05 - 19 : Agreement that some sort of uniqueness requirement is worthwhile Main question is what scope of uniqueness should be Globally ? Within scope of DS ? Fresh random value ? Simple , but precludes application usage of the field Also could help avoid metadata leakage  / DS should probably still check for collisions to write up a PR on the fresh random value idea 
 Group IDs must be generated randomly by creator Clients and DS must check that group ids are unique as far as they know
Paragraph (version B):
Group IDs SHOULD be constructed in such a way that there's an
overwhelmingly low probability of honest group creators generating
the same group ID, even without assistance from the Delivery Service.
For example, by making the group ID a freshly generated random value
of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that
group IDs are globally unique by rejecting the creation of new groups
with a previously used ID.
Paragraph (version B):
New members MUST verify that "group_id" is unique among the groups
they're currently participating in.
Paragraph (version B):
Verify that the "group_id" is unique among the groups that the
client is currently participating in.
Draft: draft-ietf-mls-protocol

Commentary: In the " Restrictions " section , we say " During each epoch senders MUST NOT encrypt more data than permitted by the security bounds of the AEAD scheme used " , without specifying the limits . We should cite something here , probably ( cc for visibility ) .
Paragraph (version A):
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used.
Paragraph (version B):
During each epoch senders MUST NOT encrypt more data than permitted
by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead-
limits.
Draft: draft-ietf-mls-protocol

Commentary: There are several references to GroupContext in the first few sections . The details are fine where they are , but it would be good to introduce the notion that GroupContext summarizes the state of the group .
Paragraph (version B):
An object that summarizes the state of the group.  The group
context is signed to bind a message to a particular group, and
also provided to new members to help them join a group.
Draft: draft-ietf-mls-protocol

Commentary: The External Senders Extension allows clients to agree on the entities that are allowed to send external proposals , as well as the signature public keys required to verify them . It contains a list of credentials that is meant to achieve this goal . However , due to a recent change , Credentials do n't necessarily contain signature public keys anymore . suggested to have it contain a signature public key , as well as a corresponding Credential , which allows members to verify the binding between signature public key and the owning entity 's identity , which I think would be a good solution . 
 Thanks I like that this captures both the signature and authentication aspects . wdyt?Looks good to me ! idea might be a good additional improvement .
Paragraph (version A):
The "external_senders" extension is a group context extension that
contains credentials of senders that are permitted to send external
proposals to the group.
Paragraph (version B):
The "external_senders" extension is a group context extension that
contains the credentials and signature keys of senders that are
permitted to send external proposals to the group.
Draft: draft-ietf-mls-protocol

Commentary: In first paragraph , the " Ratchet Tree Evolution " Section states that whenever a member initiates an epoch change , they refresh the key pair in their leaves , etc . This is not the case for partial commits , where the epoch is advanced without a key update and without achieving PCS .
Paragraph (version A):
In order to provide forward secrecy and post-compromise security,
whenever a member initiates an epoch change (i.e., commits; see
commit), they refresh the key pairs of their leaf and of all nodes on
their leaf's direct path (all nodes for which they know the secret
key).
Paragraph (version B):
Whenever a member initiates an epoch change (i.e., commits; see
commit), they may need to refresh the key pairs of their leaf and of
the nodes on their leaf's direct path in order to maintain forward
secrecy and post-compromise security.
Paragraph (version A):
ReInit proposals can also be sent to the group by a "external"
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
Paragraph (version B):
ReInit proposals can also be sent to the group by an "external"
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
Draft: draft-ietf-mls-protocol

Commentary: Also requires that padding be all - zero . Before , the sender was allowed to put arbitrary octets in there . 
 Looks good to me . I think this covers your issue on the mailing list 
 Discussed at 19 May interim . Decision to merge . 
 As discussed , we should refactor so that the padding is not length - delimited , something like :
Paragraph (version B):
The "padding" field is set by the sender, by first encoding the
content (via the "select") and the "auth" field, then appending the
chosen number of zero bytes.  A receiver identifies the padding field
in a plaintext decoded from "MLSCiphertext.ciphertext" by first
decoding the content and the "auth" field; then the "padding" field
comprises any remaining octets of plaintext.  The "padding" field
MUST be filled with all zero bytes.  A receiver MUST verify that
there are no non-zero bytes in the "padding" field, and if this check
fails, the enclosing MLSCiphertext MUST be rejected as malformed.
Paragraph (version A):
The content and length of the "padding" field in
"MLSCiphertextContent" can be chosen at the time of message
encryption by the sender.  It is recommended that padding data is
comprised of zero-valued bytes and follows an established
deterministic padding scheme.
Paragraph (version B):
The length of the "padding" field in "MLSCiphertextContent" can be
chosen at the time of message encryption by the sender.  Senders may
use padding to reduce the ability of attackers outside the group to
infer the size of the encrypted content.
Draft: draft-ietf-mls-protocol

Commentary: The following statement is no longer up - to - date , given addition of P-384 : " For ciphersuites using ECDSA with the NIST curves P-256 or  , the public key is ... " To avoid tracking too many changes in the future for the document , I suggest the simple edit : " For ciphersuites using ECDSA with the NIST curves , the public key is ... "
Paragraph (version A):
A BasicCredential is a raw, unauthenticated assertion of an identity/
key binding.  The format of the key in the "public_key" field is
defined by the relevant ciphersuite: the group ciphersuite for a
credential in a leaf node of a ratchet tree or the KeyPackage
ciphersuite for a credential in a KeyPackage object.  For
ciphersuites using Ed25519 or Ed448 signature schemes, the public key
is in the format specified in RFC8032.  For ciphersuites using ECDSA
with the NIST curves P-256 or P-521, the public key is the output of
the uncompressed Elliptic-Curve-Point-to-Octet-String conversion
according to SECG.
Paragraph (version B):
A BasicCredential is a raw, unauthenticated assertion of an identity/
key binding.  The format of the key in the "public_key" field is
defined by the relevant ciphersuite: the group ciphersuite for a
credential in a leaf node of a ratchet tree or the KeyPackage
ciphersuite for a credential in a KeyPackage object.  For
ciphersuites using Ed25519 or Ed448 signature schemes, the public key
is in the format specified in RFC8032.  For ciphersuites using ECDSA
with the NIST curves (P-256, P-384, or P-521), the public key is the
output of the uncompressed Elliptic-Curve-Point-to-Octet-String
conversion according to SECG.
Draft: draft-ietf-mls-protocol

Commentary: the " MLS Proposal Types " section defines a table with columns Value Name Recommended Path Required Reference But the template directly above the table only mentions four of the five columns . It does not mention or describe what " Path Required " means . It should probably at least make clear that the field should be either or , and reference section " Commit " where the path requirement is discussed .
Paragraph (version B):
Path Required: Whether a Commit covering a proposal of this type
is required to have its "path" field populated (see commit).
Draft: draft-ietf-mls-protocol

Commentary: This change ensures that the " init " key pair associated to the key package is one - time - use , at least to the degree that KeyPackages are one - time - use . The init key pair is used to encrypt / decrypt the Welcome message , then never again . The main drawback is requiring the KeyPackage sender to generate an additional key pair , which requires more computation and more entropy .
Paragraph (version B):
Verify that the value of "leaf_node.public_key" is different from
the value of the "init_key" field.
Draft: draft-ietf-mls-protocol

Commentary: This PR adds two clarifications suggested by some antecedents in UpdatePath processing how the example trees can come about in practice
Paragraph (version A):
Identify a node in the filtered direct path for which the local
member is in the subtree of the non-updated child.
Paragraph (version A):
Identify a node in the resolution of the copath node for which
this node has a private key.
Paragraph (version B):
Identify a node in the filtered direct path for which the
recipient is in the subtree of the non-updated child.
Paragraph (version B):
Identify a node in the resolution of the copath node for which
the recipient has a private key.
Draft: draft-ietf-mls-protocol

Commentary: The co - path is written both as ' co - path ' and ' copath ' . As a formality check , this should be unified .
Paragraph (version A):
The parent hash of P changes whenever an "UpdatePath" object is
applied to the ratchet tree along a path from a leaf U traversing
node V (and hence also P).  The new "Parent Hash of P (with Co-Path
Child S)" is obtained by hashing P's "ParentHashInput" struct.
Paragraph (version B):
The parent hash of P changes whenever an "UpdatePath" object is
applied to the ratchet tree along a path from a leaf U traversing
node V (and hence also P).  The new "Parent hash of P (with copath
child S)" is obtained by hashing P's "ParentHashInput" struct.
Paragraph (version A):
If, on the other hand, V is the leaf U and its LeafNode has
"leaf_node_source" set to "commit", then the Parent Hash of P (with
V's sibling as co-path child) is stored in the "parent_hash" field.
This is true in particular of the LeafNode object sent in the
"leaf_node" field of an UpdatePath.  The signature of such a LeafNode
thus also attests to which keys the group member introduced into the
ratchet tree and to whom the corresponding secret keys were sent.
This helps prevent malicious insiders from constructing artificial
ratchet trees with a node V whose HPKE secret key is known to the
insider yet where the insider isn't assigned a leaf in the subtree
rooted at V.  Indeed, such a ratchet tree would violate the tree
invariant.
Paragraph (version B):
If, on the other hand, V is the leaf U and its LeafNode has
"leaf_node_source" set to "commit", then the Parent Hash of P (with
V's sibling as copath child) is stored in the "parent_hash" field.
This is true in particular of the LeafNode object sent in the
"leaf_node" field of an UpdatePath.  The signature of such a LeafNode
thus also attests to which keys the group member introduced into the
ratchet tree and to whom the corresponding secret keys were sent.
This helps prevent malicious insiders from constructing artificial
ratchet trees with a node V whose HPKE secret key is known to the
insider yet where the insider isn't assigned a leaf in the subtree
rooted at V.  Indeed, such a ratchet tree would violate the tree
invariant.
Draft: draft-ietf-mls-protocol

Commentary: PublicGroupState was removed as an independent struct in . This PR fixes some dangling references to it . 
 cc 
 Comment by     . RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help . 
 CC for citations 
 They are also in this architecture document PR : 
 Oh good , I 'll just add a citation over to mls - architecture . 
 Also , update WireFormat : s / mlspublicgroupstate(4),/mlsgroup_info(4),/
Paragraph (version A):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the PublicGroupState and
an external Commit to initialize their copy of the key schedule for
the new epoch.
Paragraph (version A):
In both cases, the "info" input to HPKE is set to the
PublicGroupState for the previous epoch, encoded using the TLS
serialization.
Paragraph (version B):
In this process, the joiner sends a new "init_secret" value to the
group using the HPKE export method.  The joiner then uses that
"init_secret" with information provided in the GroupInfo and an
external Commit to initialize their copy of the key schedule for the
new epoch.
Paragraph (version B):
In both cases, the "info" input to HPKE is set to the GroupInfo for
the previous epoch, encoded using the TLS serialization.
Draft: draft-ietf-mls-protocol

Commentary: This PR introduces a notion of a proposal type being " path safe " , in the sense that it is safe for the path to be omitted . ( Better phrasing welcome ! ) The field is required default , and allowed to be omitted only if all the proposals in the Commit are path - safe . 
 Thanks for taking care of this fix ! One suggestion : Instead of having a global list of which types are path safe and which ones are n't , we could make it a property of the proposal . Maybe something like this : Regarding the name , the only thing I can think of is that we could invert the property and call it : In fact , I think I 'd be slightly in favor of the latter proposal . 
 Discussion on virtual interim : OK to keep using type  ( " path safe " -"path required " Otherwise clear to merge 
 The authoritative definition ( in Section ) of when to include a is not the same as the summary below . For example , if an implementation adds a custom proposal type , according to the summary , a path is required , whereas according to the definition above it , no path is required . Ultimately , it depends on the nature of the proposal and the desired security guarantees if a path is required . However , I think the safer option is to require a path by default and maybe leave it to the definition of the respective custom proposal to explicitly specify if a path is not required .
Paragraph (version B):
New proposal types MUST state whether they require a path.  If any
instance of a proposal type requires a path, then the proposal type
requires a path.  This attribute of a proposal type is reflected in
the "Path Required" field of the proposal type registry defined in
mls-proposal-types.
Paragraph (version B):
Update and Remove proposals are the clearest examples of proposals
that require a path.  An UpdatePath is required to evict the removed
member or the old appearance of the updated member.
Paragraph (version A):
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.
Paragraph (version B):
A "partial" Commit that references proposals that do not require a
path, and where the path is empty.  Such a commit doesn't provide
PCS with regard to the committer.
Draft: draft-ietf-mls-protocol

Commentary: The current description of external commits still leaves room for the committer to include various other proposals such as arbitrary proposals that are not Update or Remove proposals ( e.g. , Adds , RequiredCapability , PSK , etc . ) . I think we should narrow that down to a specific set of proposals ( i.e. an allow list style ) to keep the implementation and general protocol complexity low for external commits , both for creation and processing . The way I see it , the new joiner can always issue a follow - up commit for other proposals , but I might be missing important use - cases , so I 'd be grateful for feedback on this . 
 I agree with the intent here . Looking through the list of proposal types , the only other one that seems like it might be useful is PSK -- I could see it being useful to prove that you have a PSK when joining from the outside . If we can add that as an option ( probably in parallel to Remove ) , this seems good to go to me . 
 Would an External Commit adding yourself contain an Add or an Update Proposal ? 
 It used to contain an proposal , but since that 's pretty much redundant with the the commiter has to include , it got optimized away . So an external commit should be handled as if it contained an Add proposal , where the KeyPackage in the Add is instead in the . 
 Comment by Why RECOMMENDED and not MUST ?
Paragraph (version A):
If a Remove proposal is present, then the LeafNode in the
"path" field MUST meet the same criteria as the LeafNode in an
Update for the removed leaf (see update).  In particular, the
"credential" in the LeafNode MUST present a set of identifiers
that is acceptable to the application for the removed
participant.
Paragraph (version B):
There MUST be a single ExternalInit proposal.
Paragraph (version B):
There MAY be a single Remove proposal, where the LeafNode in
the "path" field MUST meet the same criteria as the LeafNode in
an Update for the removed leaf (see update).  In particular,
the "credential" in the LeafNode MUST present a set of
identifiers that is acceptable to the application for the
removed participant.
Paragraph (version B):
There MAY be one or more PreSharedKey proposals.
Paragraph (version B):
There MUST NOT be any other proposals.
Draft: draft-ietf-mls-protocol

Commentary: This PR moves the remark that there has to be validation of the attested identities upon a credential update to the KeyPackage validation subsection . It also changes the responsibility for the check to be that of the AS rather than that of the application . Note , that the boundaries are somewhat arbitrary at this point , since the application running on the local device may well implement parts of the AS . The reason for this change is to ensure any validation checks that pertain to authentication are part of the AS . 
 Please make any required changes to the architecture document as well . Since I think that 's where the AS is defined . 
 Right now it says in the Update proposal section : " Verify that the set of identities attested by the credential is acceptable to the application for the participant being updated . " Firstly , I think this is a matter of authentication and thus the AS ' job and secondly , it 's a validation step that should probably go into the section . 
 Discussion on virtual interim : Depends on what the boundary of the AS is : Checking credential is valid Also checking ( credential -credential ) transitions Moving this check to KP validation section would make it clearer to make a PR 
 Fixed by
Paragraph (version A):
Verify that the credential in the KeyPackage is valid according to
the authentication service and the client's local policy.  These
actions MUST be the same regardless of at what point in the
protocol the KeyPackage is being verified.
Paragraph (version B):
Verify that the credential in the KeyPackage is valid according to
the authentication service and the client's local policy.  These
actions MUST be the same regardless of at what point in the
protocol the KeyPackage is being verified with the following
exception: If the KeyPackage is an update to another KeyPackage,
the authentication service MUST additionally validate that the set
of identities attested by the credential in the new KeyPackage is
acceptable relative to the identities attested by the old
credential.
Paragraph (version A):
Verify that the set of identities attested by the credential is
acceptable to the application for the participant being updated.