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

Commentary: This PR fixes small issues that I noticed while implementing proposal validation and fixing some external join bugs : The pseudocode for determining whether a path is required assumes that all proposals are by - reference . The PR updates the pseudocode to be more general , and also account for proposals by value . There were two references to adding a single leaf to the tree , which are updated to make clear that the tree grows by doubling , not by single leaves . There was no current requirement that an Update proposal have a distinct , so one is .
Paragraph (version A):
If the LeafNode appears in an Update proposal, verify that
"leaf_node_source" is set to "update".
Paragraph (version B):
If the LeafNode appears in an Update proposal, verify that
"leaf_node_source" is set to "update" and that "encryption_key"
represents a different public key than the "encryption_key" in
the leaf node being replaced by the Update proposal.
Paragraph (version A):
Identify the leaf L for the new member: if there are empty leaves
in the tree, L is the leftmost empty leaf.  Otherwise, the tree is
extended to the right by one leaf node and L is the new leaf.
Paragraph (version B):
Identify the leaf L for the new member: if there are empty leaves
in the tree, L is the leftmost empty leaf.  Otherwise, the tree is
extended to the right as described in adding-and-removing-leaves
and L is assigned the leftmost new blank leaf.
Paragraph (version A):
If this is an external commit, assign the sender the leftmost
blank leaf node in the new ratchet tree.  If there are no blank
leaf nodes in the new ratchet tree, add a blank leaf to the
right side of the new ratchet tree and assign it to the sender.
Paragraph (version B):
If this is an external commit, assign the sender the leftmost
blank leaf node in the new ratchet tree.  If there are no blank
leaf nodes in the new ratchet tree, expand the tree to the
right as defined in adding-and-removing-leaves and assign the
leftmost new blank leaf to the sender.
Draft: draft-ietf-mls-protocol

Commentary: As discussed in , remove the for more consistency across names .
Paragraph (version A):
"encrypted_sender_data" and "ciphertext" are encrypted using the AEAD
function specified by the ciphersuite in use, using as input the
structures SenderData and PrivateContentTBE.
Paragraph (version A):
Content to be encrypted is encoded in a PrivateContentTBE structure.
Paragraph (version B):
"encrypted_sender_data" and "ciphertext" are encrypted using the AEAD
function specified by the ciphersuite in use, using as input the
structures SenderData and PrivateMessageContent.
Paragraph (version B):
Content to be encrypted is encoded in a PrivateMessageContent
structure.
Paragraph (version A):
When decoding a PrivateContentTBE, the application MUST check that
the FramedContentAuthData is valid.
Paragraph (version B):
When decoding a PrivateMessageContent, the application MUST check
that the FramedContentAuthData is valid.
Paragraph (version A):
The length of the "padding" field in "PrivateContentTBE" can be
chosen by the sender at the time of message encryption.  Senders may
use padding to reduce the ability of attackers outside the group to
infer the size of the encrypted content.  Note, however, that the
transports used to carry MLS messages may have maximum message sizes,
so padding schemes SHOULD avoid increasing message size beyond any
such limits that exist in a given deployment scenario.
Paragraph (version B):
The length of the "padding" field in "PrivateMessageContent" can be
chosen by the sender at the time of message encryption.  Senders may
use padding to reduce the ability of attackers outside the group to
infer the size of the encrypted content.  Note, however, that the
transports used to carry MLS messages may have maximum message sizes,
so padding schemes SHOULD avoid increasing message size beyond any
such limits that exist in a given deployment scenario.
Draft: draft-ietf-mls-protocol

Commentary: Replace stray instance of MLSCiphertext with PrivateMessage
Paragraph (version A):
The MLSCiphertext framing encrypts "sender data" that identifies
which group member sent an encrypted message, as described in sender-
data-encryption.  As with the QUIC header protection scheme RFC9001,
Section 5.4, this scheme is a variant of the HN1 construction
analyzed in NAN.  A sample of the ciphertext is combined with a
"sender_data_secret" to derive a key and nonce that are used for AEAD
encryption of the sender data.
Paragraph (version B):
The PrivateMessage framing encrypts "sender data" that identifies
which group member sent an encrypted message, as described in sender-
data-encryption.  As with the QUIC header protection scheme RFC9001,
Section 5.4, this scheme is a variant of the HN1 construction
analyzed in NAN.  A sample of the ciphertext is combined with a
"sender_data_secret" to derive a key and nonce that are used for AEAD
encryption of the sender data.
Draft: draft-ietf-mls-protocol

Commentary: The current text on initializing the transcript hash is ambiguous . In particular , it never tells you how to compute the first . This PR provides clearer initialization instructions , and a figure that summarizes the transcript hash evolution [ 2 ] . < img width="596 " alt="image " src="https://user-"[1 ] To be clear , I think the intent is clear and all current implementations are consistent . The text is just bad . [ 2 ] The diagram is a little over - the - top elaborate . I would be OK removing it :) 
 I generally like the diagram , but the intersection between , and is not clear to me . What is going where ? Also should n't and also get numbers ? And what 's the different between the and suffix ? 
 OK , I rotated the diagram 90 degrees and rejiggered things to hopefully be clearer . It now should just barely fit in the .TXT format . What do folks think ? < img width="459 " alt="image " src="https://user- " 
 Beautiful !
Paragraph (version B):
The transcript hash "ConfirmedTranscriptHashInput_[epoch]" is used as
the "confirmed_transcript_hash" input to the "confirmation_tag" field
for this Commit.  Each Commit thus confirms the whole transcript of
Commits up to that point, except for the latest Commit's confirmation
tag.
Draft: draft-ietf-mls-protocol

Commentary: Also adds a  section to cover any edits between now and the next I - D.
Paragraph (version B):
Move pseudocode out of KDFLabel definition.
Paragraph (version B):
Minor fixes in presentation language.
Paragraph (version B):
Remove reference to BasicCredential.
Draft: draft-ietf-mls-protocol

Commentary: : +1 :
Paragraph (version A):
Content to be encrypted is encoded in an PrivateContentTBE structure.
Paragraph (version B):
Content to be encrypted is encoded in a PrivateContentTBE structure.
Paragraph (version A):
When decoding an PrivateContentTBE, the application MUST check that
the FramedContentAuthData is valid.
Paragraph (version B):
When decoding a PrivateContentTBE, the application MUST check that
the FramedContentAuthData is valid.
Paragraph (version A):
In the case where the leaf was added to the tree based on a pre-
published KeyPackage, the "lifetime" field represents the times
between which clients will consider a LeafNode valid.  These times
are represented as absolute times, measured in seconds since the Unix
epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum
total lifetime that is acceptable for a LeafNode, and reject any
LeafNode where the total lifetime is longer than this duration.
Paragraph (version B):
In the case where the leaf was added to the tree based on a pre-
published KeyPackage, the "lifetime" field represents the times
between which clients will consider a LeafNode valid.  These times
are represented as absolute times, measured in seconds since the Unix
epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum
total lifetime that is acceptable for a LeafNode, and reject any
LeafNode where the total lifetime is longer than this duration.  In
order to avoid disagreements about whether a LeafNode has a valid
lifetime, the clients in a group SHOULD maintain time synchronization
(e.g., using the Network Time Protocol RFC5905).
Paragraph (version A):
If instead the LeafNode appears in a message being received by
the client, e.g., a proposal, a commit, or a ratchet tree of
the group the client is joining, it is RECOMMENDED that the
client verifies that the current time is within the range of
the "lifetime" field.
Paragraph (version A):
If encoding as an PrivateMessage, encrypt the message using the
"sender_data_secret" and the next (key, nonce) pair from the
sender's handshake ratchet.
Paragraph (version B):
If encoding as a PrivateMessage, encrypt the message using the
"sender_data_secret" and the next (key, nonce) pair from the
sender's handshake ratchet.
Draft: draft-ietf-mls-protocol

Commentary: cc for review
Paragraph (version A):
The parts of the system that perform these functions are collectively
referred to as the Authentication Service (AS) I-D.ietf-mls-
architecture.  A member's credential is said to be _validated with
the AS_ when the AS verifies the credential's presented identifiers,
and verifies that those identifiers match the reference identifiers
for the member.
Paragraph (version B):
The parts of the system that perform these functions are collectively
referred to as the Authentication Service (AS) I-D.ietf-mls-
architecture.  A member's credential is said to be _validated with
the AS_ when the AS verifies that the credential's presented
identifiers are correctly associated with the "signature_key" field
in the member's LeafNode, and verifies that those identifiers match
the reference identifiers for the member.
Draft: draft-ietf-mls-protocol

Commentary: thanks , good catch . should be fixed now . 
 Comment by Algorithm entries use two octets ( ) but only allow 255 Private Use entries . I think that might be a little low . Maybe allow 0xf000 - 0xffff or something ? 
 I agree this should be changed . CCing who I believe initially proposed this .
Paragraph (version A):
Values with the first byte 255 (decimal) are reserved for Private
Use.
Draft: draft-ietf-mls-protocol

Commentary: made me realize that BasicCredential actually does n't exist anymore ! 
 Well , " basic " is listed as a credential type in the IANA registry defined in . That said , your proposed text seems perfectly consistent with the registry and the rest of the document .
Paragraph (version A):
A BasicCredential is a bare assertion of an identity, without any
additional information.  The format of the encoded identity is
defined by the application.
Paragraph (version B):
A "basic" credential is a bare assertion of an identity, without any
additional information.  The format of the encoded identity is
defined by the application.
Draft: draft-ietf-mls-protocol

Commentary: ... by just importing the . lmk if you think we should reference instead . 
 The consensus in saag was to expand Recommended to include " D " to RFC 8447bis . Should probablly do the same here .
Paragraph (version A):
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 B):
Recommended: Whether support for this ciphersuite is recommended
by the IETF MLS WG.  Valid values are "Y", "N", and "D", as
described below.  The default value of the "Recommended" column is
"N".  Setting the Recommended item to "Y" or "D", or changing a
item whose current value is "Y" or "D", requires Standards Action
RFC8126.
Paragraph (version B):
Y: Indicates that the IETF has consensus that the item is
RECOMMENDED.  This only means that the associated mechanism is
fit for the purpose for which it was defined.  Careful reading
of the documentation for the mechanism is necessary to
understand the applicability of that mechanism.  The IETF could
recommend mechanisms that have limited applicability, but will
provide applicability statements that describe any limitations
of the mechanism or necessary constraints on its use.
Paragraph (version B):
N: Indicates that the item has not been evaluated by the IETF
and that the IETF has made no statement about the suitability
of the associated mechanism.  This does not necessarily mean
that the mechanism is flawed, only that no consensus exists.
The IETF might have consensus to leave an items marked as "N"
on the basis of it having limited applicability or usage
constraints.
Paragraph (version B):
D: Indicates that the item is discouraged and SHOULD NOT or
MUST NOT be used.  This marking could be used to identify
mechanisms that might result in problems if they are used, such
as a weak cryptographic algorithm or a mechanism that might
cause interoperability problems in deployment.
Draft: draft-ietf-mls-protocol

Commentary: For consistency with references to other extensions ( and with the IANA registry ) , refer to the extension as " external_pub " .
Paragraph (version A):
In other words, to join a group via an External Commit, a new member
needs a GroupInfo with an "ExternalPub" extension present in its
"extensions" field.
Paragraph (version B):
In other words, to join a group via an External Commit, a new member
needs a GroupInfo with an "external_pub" extension present in its
"extensions" field.
Draft: draft-ietf-mls-protocol

Commentary: The part about doing the lookup in the old tree was in , it was relevant here because of the hash references . This is not a problem anymore since we came back to referencing with leaf index .
Paragraph (version A):
Identify a leaf node matching "removed".  This lookup MUST be done
on the tree before any non-Remove proposals have been applied (the
"old" tree in the terminology of commit), since proposals such as
Update can change the LeafNode stored at a leaf.  Let L be this
leaf node.
Paragraph (version B):
Identify the leaf node matching "removed".  Let L be this leaf
node.
Draft: draft-ietf-mls-protocol

Commentary: As pointed out on the mailing list , this reference does not need to be normative .
Paragraph (version A):
This document registers the "message/mls" MIME media type in order to
allow other protocols (ex: HTTP RFC7540) to convey MLS messages.
Paragraph (version B):
This document registers the "message/mls" MIME media type in order to
allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.
Draft: draft-ietf-mls-protocol

Commentary: This will guarantee that all group members agree on the ciphersuite used . It gives more meaning to statements like " Each MLS session uses a single ciphersuite " . Also , it prevents the following attack : the adversary ( a malicious insider ) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used . Now the new member uses a weaker scheme and the adversary can impersonate them . 
 Interim 2022 - 06 - 02 : Agreement that more binding is better
Paragraph (version B):
The "cipher_suite" is the cipher suite used by the group.
Paragraph (version A):
Verify that the ciphersuite and protocol version of the KeyPackage
match those in use in the group.
Paragraph (version B):
Verify that the ciphersuite and protocol version of the KeyPackage
match those in the "GroupContext".
Paragraph (version B):
The sender type for the MLSAuthenticatedContent encapsulating the
External Commit MUST be "new_member_commit".
Paragraph (version B):
Verify that the "cipher_suite" in the GroupInfo matches the
"cipher_suite" in the KeyPackage.
Draft: draft-ietf-mls-protocol

Commentary: Add new newproposalmember SenderType and rename newmember to newcommit_member . This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case . 
 Interim 2022 - 06 - 02 : Could punt to extensions , but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved , good to merge 
 LGTM , though would still prefer etc . One minor suggestion to lock down the content .
Paragraph (version A):
"new_member": The signature key in the LeafNode in the Commit's
path (see joining-via-external-commits).  The "content_type" of
the message MUST be "commit".
Paragraph (version B):
"new_member_commit": The signature key in the LeafNode in the
Commit's path (see joining-via-external-commits).  The
"content_type" of the message MUST be "commit".
Paragraph (version B):
"new_member_proposal": The signature key in the LeafNode in the
KeyPackage embedded in an External Add Proposal.  The
"content_type" of the message MUST be "proposal"and the
"proposal_type" of the Proposal MUST be "add".
Paragraph (version A):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group, indicated by an "external"
SenderType.  This is useful in cases where, for example, an automated
service might propose to remove a member of a group who has been
inactive for a long time, or propose adding a newly-hired staff
member to a group representing a real-world team.
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group in two cases.  One case, indicated
by an "external" SenderType is useful in cases where, for example, an
automated service might propose to remove a member of a group who has
been inactive for a long time, or propose adding a newly-hired staff
member to a group representing a real-world team.
Paragraph (version B):
The other case, indicated by a "new_member_proposal" SenderType is
useful when existing members of the group can independently authorize
the addition of an MLS client proposing it be added to the group.
External proposals which are not authorized are considered invalid.
Draft: draft-ietf-mls-protocol

Commentary: In , it was pointed out that we previously had a clause : But this was amplified in to say that we also ca n't send Add proposals for users that are already in the group . I think we should talk about if this is the actual desired behavior or not . 
 I agree with  . Specifically I want to make sure an MLS client can replace itself . My other concern is that because we have no guidance yet on identity , we need to make sure that multiple instances / clients of the same user are allowed . 
 Interim 2022 - 05 - 26 : We want to : Avoid having multiple appearances of the same device  a device to resync itself Text at issue here is " An Add proposal is invalid if ... The Credential in the KeyPackage represents a client already in the group according to the application " It sounds like changing to " ... The KeyPackage represents a client already in the group according to the application " would address the immediate concern to write a PR
Paragraph (version A):
The KeyPackage is invalid according to keypackage-validation.
Paragraph (version A):
The Credential in the KeyPackage represents a client already in
the group according to the application.
Paragraph (version B):
An Add proposal is invalid if the KeyPackage is invalid according to
keypackage-validation.
Paragraph (version A):
It contains multiple Add proposals that contain KeyPackages that
represent the same client according to the application (for
example, identical KeyPackages or KeyPackages sharing the same
Credential).
Paragraph (version B):
It contains multiple Add proposals that contain KeyPackages that
represent the same client according to the application (for
example, identical signature keys).
Paragraph (version B):
It contains an Add proposal with a KeyPackage that represents a
client already in the group according to the application, unless
there is a Remove proposal in the list removing the matching
client from the group.
Draft: draft-ietf-mls-protocol

Commentary: At first I was going to make an extension for both KeyPackages and LeafNodes . But I was thinking and could n't come up with a reason for KeyPackages to need this extension , so did just LeafNode . 
 Interim 2022 - 05 - 26 : Agreement to merge is getting used a lot , so maybe or ? to change to 
 What 's the use case for this ? 
 Mentioned at the last interim , but the use - case for this feature is either : giving applications an easier way to lookup the private key corresponding to their LeafNode giving applications a place to put client UUIDs
Paragraph (version A):
If needed, applications may add application-specific unique
identifiers to the "extensions" field of KeyPackage or LeafNode
objects.
Paragraph (version B):
If needed, applications may add application-specific identifiers to
the "extensions" field of a LeafNode object with the "application_id"
extension.
Paragraph (version B):
However, applications SHOULD NOT rely on the data in an
"application_id" extension as if it were authenticated by the
Authentication Service, and SHOULD gracefully handle cases where the
identifier presented is not unique.
Paragraph (version A):
Within MLS, a KeyPackage is identified by its hash (see, e.g.,
joining-via-welcome-message).  The "external_key_id" extension allows
applications to add an explicit, application-defined identifier to a
KeyPackage.
Draft: draft-ietf-mls-protocol

Commentary: Also covers the PSK part of 
 Interim 2022 - 05 - 26 : Ready to go once merge conflicts are resolved . 
 The collection of structs could be less chatty . Suggest PreSharedKeys is only used once , can be inlined in GroupSecrets Use GroupContext for the internals of GroupInfo 
 Note : was fixed in In , we did : So only the following remain : Use GroupContext for the internals of GroupInfo 
 currently described at time of use . In the " Pre - Shared Keys " section , we should just specify that it must always be a fresh value of length The ReInit provisions require , but those for branching do not . Presumably these should be the same ? Currently , the processing rules for PreSharedKey proposal says “ MUST be external ” . This seems overly restrictive ; for example , it rules out the scenario in Figure 8 . Suggest “ MUST NOT be branch / reinit ” instead .
Paragraph (version B):
Each time a client injects a PSK into a group, the "psk_nonce" of its
PreSharedKeyID MUST be set to a fresh random value of length
"KDF.Nh", where "KDF" is the KDF for the ciphersuite of the group
into which the PSK is being injected.  This ensures that even when a
PSK is used multiple times, the value used as an input into the key
schedule is different each time.
Paragraph (version A):
The "psk_nonce" included in the "PreSharedKeyID" of the
resumption PSK MUST be a randomly sampled nonce of length
"KDF.Nh", for the KDF defined by the new group's ciphersuite.
Paragraph (version A):
In addition, to avoid key re-use, the "psk_nonce" included in the
"PreSharedKeyID" object MUST be a randomly sampled nonce of length
"KDF.Nh".
Paragraph (version B):
The "epoch" in the Welcome message MUST be 1.
Paragraph (version A):
The "psktype" in the PreSharedKeyID struct is not set to
"external".
Paragraph (version B):
The "psktype" in the PreSharedKeyID struct is not set to
"resumption" and the "usage" is "reinit" or "branch".