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

Commentary: This replaced PR which has broken merge conflicts . 
 I 've reverted this . It was prematurely merged . I 'll open a new PR once I have had time to examine this . 
 This was discussed in the interim today and is the same as the content that was in . Thanks , -rohan   l Vice President  , Architecture Chat : on    team messaging . Zeta Project Germany GmbH l Rosenthaler Straße 40 , , % C2%A0++Berlin,%C2%A0+Germany&entry = gmail&source = g10178 Berlin , , % C2%A0++Berlin,%C2%A0+Germany&entry = gmail&source = gGermany , % C2%A0++Berlin,%C2%A0+Germany&entry = gmail&source = gGeschäftsführer / Managing Director :   HRB beim   ,      
 That 's fine , but I still want to go over it before it merges .
MLS provides a way for _clients_ to form _groups_ within which they
can communicate securely.  For example, a set of users might use
clients on their phones or laptops to join a group and communicate
with each other.  A group may be as small as two clients (e.g., for
simple person to person messaging) or as large as tens of thousands.
A client that is part of a group is a _member_ of that group.
MLS provides a way for _clients_ to form _groups_ within which they
can communicate securely.  For example, a set of users might use
clients on their phones or laptops to join a group and communicate
with each other.  A group may be as small as two clients (e.g., for
simple person to person messaging) or as large as tens of thousands.
A client that is part of a group is a _member_ of that group.  As
groups change membership and group or member properties, they advance
from one _epoch_ to another and the cryptographic state of the group
evolves.
The group is represented using a _ratchet tree_, which represents the
members as the leaves of a tree.  It is used to efficiently encrypt
to subsets of the members.  Each member has a _LeafNode_ object in
the tree holding the client's identity, credentials, and
capabilities.
Various messages are used in the evolution from epoch to epoch.  A
_Proposal_ message proposes a change to be made in the next epoch,
such as adding or removing a member.  A _Commit_ message initiates a
new epoch by instructing members of the group to implement a
collection of proposals.  Proposals and Commits are collectively
called _Handshake messages_.  A _KeyPackage_ provides keys that can
be used to add the client to a group, including its LeafNode, and
_Signature Key_.  A _Welcome_ message provides a new member to the
group with the information to initialize their state for the epoch in
which they were added.
Of course most (but not all) applications use MLS to send encrypted
group messages.  An _application message_ is an MLS message with an
arbitrary application payload.
Finally, a _PublicMessage_ contains an integrity-protected MLS
Handshake message, while a _PrivateMessage_ contains a confidential,
integrity-protected Handshake or Application message.
For a more detailed explanation of these terms, please consult the
MLS protocol specification.
Draft: draft-ietf-mls-architecture

Commentary: noted in that an important function of the AS is to ensure that clients come to consistent evaluations of credentials . We should make that recommendation in this document , including the fact that consistency is needed when validity can change over time .
Within an MLS group, every member is authenticated to other member,
by means of credentials issued and verified by the Authentication
Service.  MLS does not prescribe what actions, if any, an application
should take in the event that a group member presents an invalid
credential.  For example, an application may require such a member to
be immediately evicted, or may allow some grace period for the
problem to be remediated.  To avoid operational problems, it is
important for all clients in a group to have a consistent view of
which credentials in a group are valid, and how to respond to invalid
credentials.
Within an MLS group, every member is authenticated to other member by
means of credentials issued and verified by the Authentication
Service.  MLS does not prescribe what actions, if any, an application
should take in the event that a group member presents an invalid
credential.  For example, an application may require such a member to
be immediately evicted, or may allow some grace period for the
problem to be remediated.  To avoid operational problems, it is
important for all clients in a group to have a consistent view of
which credentials in a group are valid, and how to respond to invalid
credentials.
In some authentication systems, it is possible for a previously-valid
credential to become invalid over time.  For example, in a system
based on X.509 certificates, credentials can expire or be revoked.
Fortunately, the MLS update mechansisms allow a client to replace an
old credential with a new one.  This is best done before the old
credential becomes invalid.
In some authentication systems, it is possible for a previously-valid
credential to become invalid over time.  For example, in a system
based on X.509 certificates, credentials can expire or be revoked.
The MLS update mechanisms allow a client to replace an old credential
with a new one.  This is best done before the old credential becomes
invalid.
Draft: draft-ietf-mls-architecture

Commentary: Comment by It scares me a bit that this could possibly not be detected at all ? What is the scenario where it can not be detected ? 
 It 's actually non - trivial to guarantee detection . Consider a scenario like the following : A , B , C , D are in a group The DS decides to partition the group into ( AB ) ( CD ) The DS forwards commits and messages within a partition , but not across partitions . As a result , the two subgroups work fine , but they diverge from each other This will be immediately obvious if two participants in opposite partitions ever try to compare state across the partition boundary , say by checking whether a message arrived or even by comparing the value . But it will be invisible if nobody does -- it just looks like the other partition is offline at the moment . And note that comparing across the partition boundary has to be done out of band , because the DS is blocking in - band comms across the boundary . To prevent this with any reliability , you would need a consensus protocol by which a quorum of members verify that they 've received a Commit . And even then , the members outside any particular quorum could be partitioned . In any case , designing a consensus protocol is clearly outside the MLS WG charter . The silver lining here , as the document notes , is that the protocol fails closed . If two members have different views of the group , then they can not communicate . 
 This is only true wrt to handshake messages . The DS can still reorder and provide an inconsistent view of application messages . We intentionally punted this to an extension ( which I realize now we never specified in the extensions doc ) to give applications leeway in the ordering / delivery guarantees provided to application messages . Handshake messages require reliable and in - order but application messages may or may not .
However, note that a malicious Delivery Service could also reorder
messages or provide an inconsistent view to different users.  The
protocol is designed such that this only results in a group no longer
being functional and the group members possibly detecting this and
requesting reinitialization.
However, note that a malicious Delivery Service could also reorder
messages or provide an inconsistent view to different users.  The
"generation" counter in MLS messages provides per-sender loss
detection and ordering that cannot be manipulated by the DS.  A
mechanism for more robust protections is discussed in I-D.ietf-mls-
extensions.  A DS can cause a partition in the group by partitioning
key exchange messages; this can be detected only by out of band
comparison (e.g., confirming that all clients have the same
"epoch_authenticator" value`).
Draft: draft-ietf-mls-architecture

Commentary: Made minor changes to the section of content and framing . Updated reference draft - mahy - mls - content - neg -draft - mahy - mls - content - adv The recommended mechanism is advertising content / media types , not a full negotiation mechanism .
Application messages carried by MLS are opaque to the protocol; they
can contain arbitrary data.  Each application which uses MLS needs to
define the format of its "application_data" and any mechanism
necessary to negotiate the format of that content over the lifetime
of an MLS group.  In many applications this means managing format
migrations for groups with multiple members who may each be offline
at unpredictable times.
Application messages carried by MLS are opaque to the protocol; they
can contain arbitrary data.  Each application which uses MLS needs to
define the format of its "application_data" and any mechanism
necessary to determine the format of that content over the lifetime
of an MLS group.  In many applications this means managing format
migrations for groups with multiple members who may each be offline
at unpredictable times.
Draft: draft-ietf-mls-architecture

Commentary: According to I - D Nits : Checking nits according to : The abstract seems to contain references ( [ I - D.ietf - mls - protocol ] ) , which it should n't . Please replace those with straight textual mentions of the documents in question . The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate , even if it appears to use RFC 2119 keywords . RFC 2119 keyword , line 557 : ' forked group states MUST be deleted ... ' 
 TY ! 
 Thanks
The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol
specification has the role of defining a Group Key Agreement
protocol, including all the cryptographic operations and
serialization/deserialization functions necessary for scalable and
secure group messaging.  The MLS protocol is meant to protect against
eavesdropping, tampering, message forgery, and provide further
properties such as Forward Secrecy (FS) and Post-Compromise Security
(PCS) in the case of past or future device compromises.
The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
specification has the role of defining a Group Key Agreement
protocol, including all the cryptographic operations and
serialization/deserialization functions necessary for scalable and
secure group messaging.  The MLS protocol is meant to protect against
eavesdropping, tampering, message forgery, and provide further
properties such as Forward Secrecy (FS) and Post-Compromise Security
(PCS) in the case of past or future device compromises.
Draft: draft-ietf-mls-architecture

Commentary: The references at the end of the Security Considerations were n't in kramdown format . Fixed .
Various academic works have analyzed MLS and the different security
guarantees it aims to provide.  The security of large parts of the
protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11)
and [AJM20] (draft 12).
Individual components of various drafts of the MLS protocol have been
analyzed in isolation and with differing adversarial models, for
example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20]
analyze the ratcheting tree as the sub-protocol of MLS that
facilitates key agreement, while [BCK21] analyzes the key derivation
paths in the ratchet tree and key schedule.  Finally, [CHK21]
analyzes the authentication and cross-group healing guarantees
provided by MLS.
Various academic works have analyzed MLS and the different security
guarantees it aims to provide.  The security of large parts of the
protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and
AJM20 (draft 12).
Individual components of various drafts of the MLS protocol have been
analyzed in isolation and with differing adversarial models, for
example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21
analyze the ratcheting tree as the sub-protocol of MLS that
facilitates key agreement, while BCK21 analyzes the key derivation
paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes
the authentication and cross-group healing guarantees provided by
MLS.
Draft: draft-ietf-mls-architecture

Commentary: WGLC comments on Operation Requirements section . Added several overlooked requirements 
 Discussed on 12/8 interim , and folks seemed fine with this . I.e. , it 's ready to merge .
Issuing new credentials,
Validating whether or not two credentials represent the same
client.
Issuing new credentials with a relevant credential lifetime,
Validating a credential against a reference identifier,
Optionally revoking credentials which are no longer authorized.
Downloading KeyPackages for specific clients, and uploading new
KeyPackages for a user's own clients.
Uploading new KeyPackages for a user's own clients.
Downloading KeyPackages for specific clients.  Typically,
KeyPackages are used once and consumed.
A policy on which ciphersuites are acceptable.
A policy on any mandatory or forbidden MLS extensions.
When proposals from external senders are allowed.
When external joiners are allowed.
When proposals from external senders are allowed and how to
authorize those proposals.
When external joiners are allowed and how to authorize those
external commits.
Which other proposal types are allowed.
A policy of when members should commit pending proposals in a
group.
A policy of how to protect and share the GroupInfo objects needed
for external joins.
Draft: draft-ietf-mls-architecture

Commentary: This PR pulls in the CAP theorem - related discussion from which is a more helpful way to frame DS design .
However, note that a Delivery Service could also reorder messages or
provide an inconsistent view to different users not just
accidentally, but maliciously.  The protocol is designed such that
this only results in a group no longer being functional and the group
members possibly detecting this and requesting reinitialization.
However, note that a malicious Delivery Service could also reorder
messages or provide an inconsistent view to different users.  The
protocol is designed such that this only results in a group no longer
being functional and the group members possibly detecting this and
requesting reinitialization.
Draft: draft-ietf-mls-architecture

Commentary: Thanks  ! I 'll merge this modulo the deletion of the paragraph regarding " being a member " since that was specifically discussed during an interim call .
Users will often use multiple devices, e.g., a phone as well as a
laptop.  Different devices are represented as different clients with
independent cryptographic state.
Users will often use multiple devices, e.g., a phone as well as a
laptop.  The formal definition of a Group in MLS is the set of
clients that have knowledge of the shared group secret established in
the group key establishment phase of the protocol and have
contributed to it.  Until a Member has been added to the group and
contributed to the group secret in a manner verifiable by other
members of the group, other members cannot assume that the Member is
a member of the group.  Different devices are represented as
different clients with independent cryptographic state.
Draft: draft-ietf-mls-architecture

Commentary: Particularly in multi - device scenarios ( where a user has more than one device ) , we should recommend that clients correlate the set of devices of each user across groups . This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member . If a device credential does not appear in all groups after a while , clients have an indication that the credential might have been created without the user 's knowledge . This should however only be a recommendation since it might not be a desirable property in all scenarios . In practical terms , users might also need some time to add their new device to all of the groups , therefore a grace period might be needed . Taking the latter into account , correlating users ' devices across groups is more of a detection mechanism than a prevention mechanism . 
 " In many uses of MLS , there are multiple MLS clients which represent a single user ( for example a human user with a mobile and desktop version of an application ) . Often the same set of clients is represented in exactly the same list groups . In applications where this is the case , clients can compare the set of devices of each user across groups . This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member . If a device credential does not appear in all groups after some relatively short period of time , clients have an indication that the credential might have been created without the user 's knowledge . As this may take some time , correlating users ' devices across groups is more of a detection mechanism than a prevention mechanism . " 
 I lightly edited prose and turned it into PR . 
 Made a quick pass . I think we should stick with " clients " rather than " devices " .
inconsistencies in a user's device set, so correlating users' clients
across groups is more of a detection mechanism than a prevention
mechanism.
inconsistencies in a user's client set, so correlating users' clients
across groups is more of a detection mechanism than a prevention
mechanism.
Draft: draft-ietf-mls-architecture

Commentary: As discussed in today 's interim . This is essentially repushing which should not have been reverted . 
 Interim 2022 - 06 - 09 : Informational refence from RFC to a draft is allowed Agreement to just un - revert / re - land 
 Fixed in
Application messages carried by MLS are opaque; they can contain
arbitrary data.  The MLS framing for application messages also
provides a field where clients can send information that is
authenticated but not encrypted.  Such information can be used by
servers that handle the message, but group members are assured that
it has not been tampered with.
Application messages carried by MLS are opaque to the protocol; they
can contain arbitrary data.  Each application which uses MLS needs to
define the format of its "application_data" and any mechanism
necessary to negotiate the format of that content over the lifetime
of an MLS group.  In many applications this means managing format
migrations for groups with multiple members who may each be offline
at unpredictable times.
The MLS framing for application messages also provides a field where
clients can send information that is authenticated but not encrypted.
Such information can be used by servers that handle the message, but
group members are assured that it has not been tampered with.
Draft: draft-ietf-mls-architecture

Commentary: Reverts mlswg / mls - architecture This has not been merged for a reason , namely I do n’t want the dependency on an unpublished draft .
Application messages carried by MLS are opaque to the protocol; they
can contain arbitrary data.  Each application which uses MLS needs to
define the format of its "application_data" and any mechanism
necessary to negotiate the format of that content over the lifetime
of an MLS group.  In many applications this means managing format
migrations for groups with multiple members who may each be offline
at unpredictable times.
The MLS framing for application messages also provides a field where
clients can send information that is authenticated but not encrypted.
Such information can be used by servers that handle the message, but
group members are assured that it has not been tampered with.
Application messages carried by MLS are opaque; they can contain
arbitrary data.  The MLS framing for application messages also
provides a field where clients can send information that is
authenticated but not encrypted.  Such information can be used by
servers that handle the message, but group members are assured that
it has not been tampered with.
Draft: draft-ietf-mls-architecture

Commentary: This PR adds a short paragraph referencing the various academic works that has gone into MLS . The references to the various works still need to be cleaned up , which I will do once the list is complete . In particular , each reference needs to be checked for correctness ( eprint version vs. publicized version ) and then included as informal reference in the yaml header of the document . 
 Is there another RFC you can point to that links academic papers on the protocol ? I 'd expect TLS 1.3 to be a good example of this , but I do n't see them do this . The references should be cited properly if we do include it ( ie , as citations at the top of the file ) 
 The references are in the appendices . For instance The reader should refer to the following references for analysis of the TLS handshake : [ DFGS15 ] , [ CHSV16 ] , [ DFGS16 ] , [ KW16 ] , [ Kraw16 ] , [ FGSW16 ] , [ LXZFH16 ] , [ FG17 ] , and [ BBK17 ] . 
 TLS 1.3 as cited by was indeed the inspiration for this . The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the " Informal References " section . As noted above , I intend to properly format all the references once we agree on what references to include , as formatting them into the right yaml is a bit of a pain . 
 Thanks  !
Various academic works have analyzed MLS and the different security
guarantees it aims to provide.  The security of large parts of the
protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11)
and [AJM20] (draft 12).
Individual components of various drafts of the MLS protocol have been
analyzed in isolation and with differing adversarial models, for
example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20]
analyze the ratcheting tree as the sub-protocol of MLS that
facilitates key agreement, while [BCK21] analyzes the key derivation
paths in the ratchet tree and key schedule.  Finally, [CHK19]
analyzes the authentication and cross-group healing guarantees
provided by MLS.