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

Commentary: This is a minimal section for MIME type registration of message / mls . It assumes that PR include wire_format in all MLS messages ( making a format parameter unnecessary ) , and that all messages have the MLS version number encoded ( making a version parameter unnecessary ) . These parameters can be if needed . 
 When MLS messages are transmitted over a protocol which supports Content - Type / MIME Type negotiation , signal that the message is an MLS message . Because MLS messages are really a bag of formats today we should have a MIME type parameter which specifies the specific format included . message / mls;format={applicationgroupcontext } 
 This seems like a fine idea to me . Could go as a section in the protocol spec , or as a separate ( small ) spec . 
 Discussion on virtual interim : Section or separate doc ? How do we handle versioning ? Internal to the protocol ( field in MLSMessage ? ) Field in the MIME type Different MIME type per version 
 I would prefer a short section in the protocol document . I think Internal to the protocol is cleanest . Likewise the format parameter becomes unnecessary if we add Welcome , PublicGroupState , and KeyPackage to wire_format ( see issue ) 
 send a PR ? 
 Asking for friend : would we want to define ( or use ) a structured syntax suffix ala ? 
 If you mean for multiple formats , no , we have only one encoding . If someone wants to re - encode the protocol as XML or whatever , a MIME type will be the least of their troubles . 
 Fixed in
Paragraph (version B):
This document registers the "message/mls" MIME media type in order to
allow other protocols (ex: HTTP RFC7540) to convey MLS messages.
Draft: draft-ietf-mls-protocol

Commentary: The definition of blank node needs to move ahead into # # Ratchet Tree Terminology as it is used in the section immediately following ( # # Views of a Ratchet Tree ) .
Paragraph (version B):
Finally, a node in the tree may also be _blank_, indicating that no
value is present at that node (i.e. no keying material).  This is
often the case when a leaf was recently removed from the tree.
Draft: draft-ietf-mls-protocol

Commentary: As discussed in ,  should n't be repeated in the same commit 
 Should multiple PSK proposals within a commit be able to reference the same ? I feel like this should be covered in the same way we state multiple removals for the same should result in the committer choosing one . Was n't sure if this was an oversight or on purpose . I can submit a PR to clarify if this is something that should be addressed 
 I agree , duplicates are an error . Committer MUST NOT include duplicates ; receiver MUST reject Commit with duplicates . - Please send a PR !
Paragraph (version A):
If there are multiple proposals that apply to the same leaf, the
committer chooses one and includes only that one in the Commit,
considering the rest invalid.  The committer MUST NOT include any
Update proposals generated by the committer, since they would be
duplicative with the "path" field in the Commit.  The committer MUST
prefer any Remove received, or the most recent Update for the leaf if
there are no Removes.  If there are multiple Add proposals containing
KeyPackages that the committer considers to represent the same client
or a client already in the group (for example, identical KeyPackages
or KeyPackages sharing the same Credential), the committer again
chooses one to include and considers the rest invalid.  The committer
MUST consider invalid any Add or Update proposal if the Credential in
the contained KeyPackage shares the same signature key with a
Credential in any leaf of the group, or if the KeyPackage shares the
same "hpke_init_key" with another KeyPackage in the group.
Paragraph (version B):
If there are multiple proposals that apply to the same leaf, or
multiple PreSharedKey proposals that reference the same
PreSharedKeyID, the committer MUST choose one and include only that
one in the Commit, considering the rest invalid.  The committer MUST
NOT include any Update proposals generated by the committer, since
they would be duplicative with the "path" field in the Commit.  The
committer MUST prefer any Remove received, or the most recent Update
for the leaf if there are no Removes.  If there are multiple Add
proposals containing KeyPackages that the committer considers to
represent the same client or a client already in the group (for
example, identical KeyPackages or KeyPackages sharing the same
Credential), the committer again chooses one to include and considers
the rest invalid.  The committer MUST consider invalid any Add or
Update proposal if the Credential in the contained KeyPackage shares
the same signature key with a Credential in any leaf of the group, or
if the KeyPackage shares the same "hpke_init_key" with another
KeyPackage in the group.
Paragraph (version A):
Verify that all PSKs specified in any PreSharedKey proposals in
the "proposals" vector are available.
Paragraph (version B):
Verify that all PreSharedKey proposals in the "proposals" vector
have unique PreSharedKeyIDs and are available.
Draft: draft-ietf-mls-protocol

Commentary: This is the last of the reorg PRs . Does what it says in the title . < img width="482 " alt="image " src="https://user- "
Paragraph (version B):
The transcript hashes computed in MLS represent a running hash over
all Proposal and Commit messages that have ever been sent in a group.
Commit messages are included directly.  Proposal messages are
indirectly included via the Commit that applied them.  Both types of
message are included by hashing the MLSPlaintext in which they were
sent.
Draft: draft-ietf-mls-protocol

Commentary: Note that is currently under , so that should probably move or the top level section should be renamed . I ran out of imagination for today .
Paragraph (version A):
A _key schedule_ that represents the shared secret state of the
group and its evolution from one epoch to the next.
Paragraph (version A):
A _ratchet tree_ that represents the membership of the group,
providing group members a way to authenticate each other and
efficiently encrypt messages to subsets of the group.  Each epoch
has a distinct ratchet tree.
Paragraph (version B):
A _ratchet tree_ that represents the membership of the group,
providing group members a way to authenticate each other and
efficiently encrypt messages to subsets of the group.  Each epoch
has a distinct ratchet tree.  It seeds the _key schedule_.
Paragraph (version B):
A _key schedule_ that describes the chain of key derivations used
to progress from epoch to epoch (mainly using the _init_secret_
and _epoch_secret_); and to derive a variety of other secrets (see
epoch-derived-secrets) used during the current epoch.  One of
these (the _encryption_secret_) is the root of _secret_tree_.
Draft: draft-ietf-mls-protocol

Commentary: In the Protocol Overview , Figure 1 shows a ratchet tree , commitsecret , epochsecret , encryptionsecret , and a secret tree , while the text discusses the epochsecret and encryption_secret . Then the next section , Cryptographic State and  states that " There are two types of cryptographic state at the core of MLS : " a key schedule , and a ratchet tree . The Secret Tree is n't mentioned there . Then we have a Key Schedule section which then includes a Secret Tree sub - section . Readers are left wondering what the relationship is between the the Key Schedule and   .
Paragraph (version A):
Each member of the group maintains a view of these two facets of the
group's state.  MLS messages are used to initialize these views and
keep them in sync as the group transitions between epochs.
Paragraph (version B):
A _secret tree_ derived from the key schedule that represents
shared secrets used by the members of the group to provide
confidentiality and forward secrecy for MLS messages.  Each epoch
has a distinct secret tree.
Paragraph (version B):
Each member of the group maintains a view of these facets of the
group's state.  MLS messages are used to initialize these views and
keep them in sync as the group transitions between epochs.
Paragraph (version A):
An _encryption secret_ that is used to initialize a _secret tree_,
which provides keys for encrypting handshake and application
messages and providing forward secrecy for these messages within
an epoch.
Paragraph (version B):
An _encryption secret_ that is used to initialize the secret tree
for the epoch.
Draft: draft-ietf-mls-protocol

Commentary: Make the definition of descendant match the common - sense definition ( you are not your own descendant ) , adjust the text which uses the definition . Note : this allows for a much clearer definition of the tree invariant as well .
Paragraph (version A):
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our trees have
precisely two children, a _left_ child and a _right_ child.  A node
is the _root_ of a tree if it has no parents, and _intermediate_ if
it has both children and parents.  The _descendants_ of a node are
that node, its children, and the descendants of its children, and we
say a tree _contains_ a node if that node is a descendant of the root
of the tree.  Nodes are _siblings_ if they share the same parent.
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):
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our trees have
precisely two children, a _left_ child and a _right_ child.  A node
is the _root_ of a tree if it has no parents, and _intermediate_ if
it has both children and parents.  The _descendants_ of a node are
that node's children, and the descendants of its children, and we say
a tree _contains_ a node if that node is a descendant of the root of
the tree, or if the node itself is the root of the tree.  Nodes are
_siblings_ if they share the same parent.
Paragraph (version B):
A _subtree_ of a tree is the tree given by any node (the _head_ of
the subtree) and its descendants.  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_).
Draft: draft-ietf-mls-protocol

Commentary: The definition of an MLS group in the 2nd paragraph of the Protocol Overview is really good . Let 's use it as the definition in the Terminology section as well .
Paragraph (version A):
A linear sequence of epochs in which each epoch depends on its
predecessor.
Paragraph (version B):
A group represents a logical collection of clents that share a
common secret value at any given time.  Its state is represented
as a linear sequence of epochs in which each epoch depends on its
predecessor.
Draft: draft-ietf-mls-protocol

Commentary: Adds the overview text proposed in . 
 Thanks ! 
 Thanks for putting together the overview . The figures are great :-) Looks good to me with one proposition .
Paragraph (version B):
A group comprises a single linear sequence of epochs and groups are
generally independent of one-another.  However, it can sometimes be
useful to link epochs cryptographically, either within a group or
across groups.  MLS derives a resumption pre-shared key (PSK) from
each epoch to allow entropy extracted from one epoch to be injected
into a future epoch.  This link guarantees that members entering the
new epoch agree on a key if and only if were members of the group
during the epoch from which the resumption key was extracted.
Paragraph (version B):
MLS supports two ways to tie a new group to an existing group.  Re-
initialization closes one group and creates a new group comprising
the same members with different parameters.  Branching starts a new
group with a subset of the original group's participants (with no
effect on the original group).  In both cases, the new group is
linked to the old group via a resumption PSK.
Paragraph (version B):
Applications may also choose to use resumption PSKs to link epochs in
other ways.  For example, the following figure shows a case where a
resumption PSK from epoch "n" is injected into epoch "n+k".  This
demonstrates that the members of the group at epoch "n+k" were also
members at epoch "n", irrespective of any changes to these members'
keys due to Updates or Commits.
Draft: draft-ietf-mls-protocol

Commentary: Fixes a minor bug in
Paragraph (version A):
The "group_id" and "extensions" fields are constant.
Paragraph (version B):
The "group_id" field is constant.
Paragraph (version B):
The "confirmed_transcript_hash" field is updated with the data for
an MLSPlaintext message encoding a Commit message as described
below.
Paragraph (version B):
The "extensions" field changes when a GroupContextExtensions
proposal is committed.
Draft: draft-ietf-mls-protocol

Commentary: The padding section was out of date based on prior changes . 
 In section 14.1 Message Encryption and Decryption there is a paragraph describing the reasons why you would want to use padding , and part of that mentions the following 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 lengthofpadding can be chosen at the time of the message encryption by the sender . This seems out of date given that padding is a separate field that does n't need to be explicitly stripped off at decrypt time and there is no other mention of in the document . 
 That seems right . We used to have a more clever , more economical padding scheme mirroring what TLS does . But that got rationalized a while ago . These are probably dangling references . Want to send a PR ? 
 Sounds good , pushed PR
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.  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.
Paragraph (version B):
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.
Draft: draft-ietf-mls-protocol

Commentary: A GroupInfo ( or a PublicGroupState ) should only ever contain one RatchetTreeExtension . Either that or it should be specified what happens if there is more than one . 
 Seems like we should be able to make a general proclamation that extension IDs MUST be unique in a given vector of extensions , whether that 's GroupContext , KeyPackage , GroupInfo , GroupContextExtensions , etc . 
 Sounds good to me . I 'll draft a PR . 
 SGTM , one minor rephrasing for more clarity .
Paragraph (version B):
Any field containing a list of extensions MUST NOT have more than
one extension of any given type.
Draft: draft-ietf-mls-protocol

Commentary: As noted , the current truncation algorithm breaks parent hashes . This PR implements the " careful truncation " algorithm he proposes . 
 I think this should be good to go ? 
 Merging this for now to un - break the spec . I will work with Marta to see if we can make a follow - up that removes redundant nodes , so that we can get back to more aggressive truncation .
Paragraph (version A):
Truncate the tree by removing leaves from the right side of the
tree until the rightmost leaf node is not blank.
Draft: draft-ietf-mls-protocol

Commentary: Any Update proposal for the sender is redundant if the Commit includes a . 
 This is true , but they 're also harmless , since the information in the will overwrite all of their effects . Note that : A requirement to this effect would only be binding on a committer . The receiver of a Commit MUST process all of the referenced proposals , as prescribed in the Commit . A is required if a Commit covers Updates or Removes ; if a Commit covers a self - Update , then it must have a . So there 's no reasn to condition on " if a is included " . This seems fine for some advisory text , but not an absolute prohibition . 
 The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules , e.g. that the commit contains all valid proposals , etc . , even if that is not explicit in the list of things the receiver of a commit should do . So any requirement on the committer would also affect the receiver . So if we mandate that a committer ca n't include self - updates if the path is populated , then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit . I 'm not sure I understand your second point . My reasoning would be that if a committer wants to do an update , they would just include a path rather than an update proposal , which is redundant anyway . 
 Sorry I missed that there was still conversation going on here before merging . On the latter point : All I 'm saying is that there is no case where there is both ( a ) a self - update and ( b ) no . So you 're always in the bad scenario :) In our Wire chat , you made a good point that repeated proposals for the same leaf are invalid , and self - Updates are effectively repeats of the . Reopening , will file a fresh PR to adjust the text .
Paragraph (version B):
The sender of a Commit SHOULD NOT include any Update proposals that
the sender themselves generated.  If sender generated one or more
Update proposals during an epoch, then it SHOULD instead update its
leaf and direct path by sending "path" field in the Commit.
Draft: draft-ietf-mls-protocol

Commentary: I suggest that we consider including a ciphersuite that enables AES256 GCM with SHA384 and that for signatures ECDSA with P-384 ( and SHA-384 ) is also permitted . The NSA restricts commercial applications to certain algorithms for applications that are used in or in coordination with the U.S. federal government and , from a general availability perspective , adding this could expand protocol use potential . 
 I presume you 're thinking of here ? I realize that the table specifies P-384 and SHA-384 ; is it your understanding that it forbids using bigger curves / hashes ? 
 Both  B and alignment to the . The other options currently in the spec , size accounted for , do not align to requirements . 
 You did n't answer my question about forbidding the use of bigger curves / hashes . Would the cases you 're interested in be covered by the AES-256 / SHA-512 / P-521 suite ? 
 If this is needed for the reasons mentioned in the issue , I have no objections .
Paragraph (version A):
The hash used for the MLS transcript hash is the one referenced in
the ciphersuite name.  In the ciphersuites defined above, "SHA256"
and "SHA512" refer to the SHA-256 and SHA-512 functions defined in
SHS.
Paragraph (version B):
The hash used for the MLS transcript hash is the one referenced in
the ciphersuite name.  In the ciphersuites defined above, "SHA256",
"SHA384", and "SHA512" refer to the SHA-256, SHA-384, and SHA-512
functions defined in SHS.
Draft: draft-ietf-mls-protocol

Commentary: HPKE is in the RFC Editor queue , so there should n't be any further changes . 
 MLS draft-12 still references draft-08 of HPKE , which is now on draft-12 . We should update to the final version of HPKE before finalizing MLS .
Paragraph (version A):
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.
Paragraph (version B):
MLS uses HPKE for public-key encryption I-D.irtf-cfrg-hpke.  The
"DeriveKeyPair" function associated to the KEM for the ciphersuite
maps octet strings to HPKE key pairs.
Draft: draft-ietf-mls-protocol

Commentary: Right now , the vector is described in a couple of ways . This PR standardizes on " of length " .
Paragraph (version B):
"0" represents an all-zero byte string of length "KDF.Nh".
Paragraph (version A):
If not populating the "path" field: Set the "path" field in the
Commit to the null optional.  Define "commit_secret" as the all-
zero vector of the same length as a "path_secret" value would be.
In this case, the new ratchet tree is the same as the provisional
ratchet tree.
Paragraph (version B):
If not populating the "path" field: Set the "path" field in the
Commit to the null optional.  Define "commit_secret" as the all-
zero vector of length "KDF.Nh" (the same length as a "path_secret"
value would be).  In this case, the new ratchet tree is the same
as the provisional ratchet tree.
Paragraph (version A):
If the "path" value is not populated: Define "commit_secret" as
the all-zero vector of the same length as a "path_secret" value
would be.
Paragraph (version B):
If the "path" value is not populated: Define "commit_secret" as
the all-zero vector of length "KDF.Nh" (the same length as a
"path_secret" value would be).
Draft: draft-ietf-mls-protocol

Commentary: Most of these were stale ; see comments for more specifics . I opened as a general issue arising from the final TODO . 
 Discussed at interim , will merge after adding text in comment . create new issue for multiple PSKs and PR for cascading HKDF . 
 The " Sequencing of State Changes " and " Application Messages " sections date to very early in the document 's life , and probably need some updates to reflect current thinking . 
 Closing for now , might reopen based on WGLC review .
Paragraph (version A):
Note that, as a PSK may have a different lifetime than an update, it
does not necessarily provide the same Forward Secrecy (FS) or Post-
Compromise Security (PCS) guarantees as a Commit message.
Paragraph (version B):
Note that, as a PSK may have a different lifetime than an update, it
does not necessarily provide the same Forward Secrecy (FS) or Post-
Compromise Security (PCS) guarantees as a Commit message.  Unlike the
key pairs populated in the tree by an Update or Commit, which always
freshly generated, PSKs may be pre-distributed and stored.  This
creates the risk that a PSK may be compromised in the process of
distribution and storage.  The security that the group gets from
injecting a PSK thus depends on both the entropy of the PSK and the
risk of compromise.  These factors are outside of the scope of this
document, but should be considered by application designers relying
on PSKs.
Draft: draft-ietf-mls-protocol

Commentary: The spec does n't say anything about the signature encoding yet . This PR adds a paragraph clarifying that signature encoding is done like in TLS .
Paragraph (version B):
The signatures used throughout this document are encoded as specified
in RFC8446.  In particular, ECDSA signatures are DER-encoded and
EdDSA signatures are defined as the concatenation of "r" and "s" as
specified in RFC8032.