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

Commentary: Thank you  ! 
 Just so folks are aware , here is how the figure renders now : < img width="457 " alt="image " src="https://user- "
The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol
specification has the role of defining a Group Key Agreement, all the
necessary cryptographic operations, and serialization/deserialization
functions necessary to create a scalable and secure group messaging
protocol.  The MLS protocol is meant to protect against
eavesdropping, tampering, message forgery, and provide good
properties such as forward-secrecy (FS) and post-compromise security
(PCS) in the case of past or future device compromises.
This document describes a general secure group messaging
infrastructure and its security goals.  It provides guidance on
building a group messaging system and discusses security and privacy
tradeoffs offered by multiple security mechanism that are part of the
MLS protocol (e.g., frequency of public encryption key rotation).
The document also extends the guidance to parts of the infrastructure
that are not standardized by the MLS Protocol document and left to
the application or the infrastructure architects to design.
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.
This document describes a general secure group messaging
infrastructure and its security goals.  It provides guidance on
building a group messaging system and discusses security and privacy
tradeoffs offered by multiple security mechanisms that are part of
the MLS protocol (e.g., frequency of public encryption key rotation).
The document also provides guidance for parts of the infrastructure
that are not standardized by the MLS Protocol document and left to
the application or the infrastructure architects to design.
While the recommendations of this document are not mandatory to
follow in order to interoperate at the protocol level, they affect
the overall security guarantees that are achieved by a messaging
application.  This is especially true in case of active adversaries
that are able to compromise clients, the delivery service or the
authentication service.
While the recommendations of this document are not mandatory to
follow in order to interoperate at the protocol level, they affect
the overall security guarantees that are achieved by a messaging
application.  This is especially true in case of active adversaries
that are able to compromise clients, the delivery service, or the
authentication service.
Draft: draft-ietf-mls-architecture

Commentary: I a short section after discussing architectural issues for content framing and negotiation . It suggests [ 1 ] if the application does n't have a more specific proposal . [ 1 ] 
 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: Thanks for cleaning up a bit ! Looks good in general , just a few nits .
The attacker can generate and inject any message in the
unprotected transport layer.
The attacker can generate, inject and delete any message in the
unprotected transport layer.
Each encrypted MLS message carries a "generation" number which is
per-sender incrementing counter.  If a group member observes a gap in
the generation sequence for a sender, then they know that they have
missed a message from that sender.  MLS also provides a facility for
group members to send authenticated acknowledgements of application
messages received within a group.
Each encrypted MLS message carries a "generation" number which is a
per-sender incrementing counter.  If a group member observes a gap in
the generation sequence for a sender, then they know that they have
missed a message from that sender.  MLS also provides a facility for
group members to send authenticated acknowledgements of application
messages received within a group.
As discusssed in delivery-service, the Delivery Service is trusted to
select the single Commit message that is applied in each epoch from
among the ones sent by group members.  Since only one Commit per
epoch is meaningful, it's not useful for the DS to transmit multiple
Commits too clients.  The risk remains that the DS will use the
ability maiciously.
As discusssed in delivery-service, the Delivery Service is trusted to
select the single Commit message that is applied in each epoch from
among the ones sent by group members.  Since only one Commit per
epoch is meaningful, it's not useful for the DS to transmit multiple
Commits to clients.  The risk remains that the DS will use the
ability maliciously.
Draft: draft-ietf-mls-architecture

Commentary: Mainly focused on cleaning up grammar , but also fixing some things that have gone stale , like the idea that the MLS protocol is " abstract " . 
 This looks good ! Thank you ! 
 Looks good ! Just two comments on client identity .
Formally, a client is a set of cryptographic objects composed by
public values such as a name (an identity), a public encryption key
and a public signature key.  Ownership of a client by a user is
determined by the fact that the user has knowledge of the associated
secret values.  When a client is part of a Group, it is called a
Member and its signature key pair uniquely identifies it to other
clients or members in the Group.  In some messaging systems, clients
belonging to the same user must all share the same signature key
pair, but MLS does not assume this.
Users will often use multiple clients, potentially one or more per
device (phones, web clients or other devices...), and may choose to
authenticate using the same signature key across devices, using one
signature key per device or even one signature key per group.
Formally, a client is a set of cryptographic objects composed by
public values such as a name (an identity), a public encryption key
and a public signature key.  Ownership of a client by a user is
determined by the fact that the user has knowledge of the associated
secret values.  When a client is part of a Group, it is called a
Member.  In some messaging systems, clients belonging to the same
user must all share the same signature key pair, but MLS does not
assume this.
Users will often use multiple devices, e.g., a phone as well as a
laptop.  Different devices may be represented as different clients,
with independent cryptographic state, or they may share cryptographic
state, relying on some application-provided mechanism to sync across
devices.
Draft: draft-ietf-mls-architecture

Commentary: Minor corrections throughout from joint edits by and Some description text . 
 In the section " Groups , Members , and Clients " , the definition of a group in MLS is the set of clients that have knowledge of the shared group key , which is established in the group key exchange . The spec then goes on to say that " Until a Member has contributed to the group secret , other members can not assume she is a member of the group . " This phrasing of what constitutes a group member is quite weak and does not actually reflect the security properties of the underlying group key exchange . If a member has not contributed to the shared group secret , she can not be considered a member of the group , as 1 ) she should not be able to learn the group key ( without acting adversarially outside of the protocol ) , and 2 ) other members can not verify her membership Instead , I would rephrase this description of a member / non - member to say something stronger , like " Until a Member has been to the group by another member --- thereby requiring that she contributes to the group secret in this process in such a way that is verifiable to other group members -- she will not be able to participate as a member of the group . " 
 Good idea . An edit on this has been to PR . 
 I might be missing something here : Ca n't a party be to a group ( thus learning the group secret ) and from that point never contribute to the shared group secret ? That party would still be able to encrypt and decrypt application messages . 
 Hi could you please check the current document and propose a new phrasing if needed ? Thanks : ) 
 confirmed to me offline that this issue was addressed in 
 Modulo a few nits that can be fixed post - merge , this looks quite good Thanks to you three for the PR !
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 contributed to the group secret, other members
cannot assume they are a member of the group.
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.
Draft: draft-ietf-mls-architecture

Commentary: As the title says , this PR does n't change any text , but simply moves the sections on - to the section in preparation for further PRs . , where we plan on going into more detail on each of these properties . This PR is joint work with and 
 Thanks !
As described in client-compromise, MLS provides strong authentication
within a group, such that a group member cannot send a message that
appears to be from another group member.  Additionally, some services
require that a recipient be able to prove to the service provider
that a message was sent by a given client, in order to report abuse.
MLS supports both of these use cases.  In some deployments, these
services are provided by mechanisms which allow the receiver to prove
a message's origin to a third party (this if often called "non-
repudiation"), but it should also be possible to operate MLS in a
"deniable" mode where such proof is not possible.
MLS provides strong authentication within a group, such that a group
member cannot send a message that appears to be from another group
member.  Additionally, some services require that a recipient be able
to prove to the service provider that a message was sent by a given
client, in order to report abuse.  MLS supports both of these use
cases.  In some deployments, these services are provided by
mechanisms which allow the receiver to prove a message's origin to a
third party (this if often called "non-repudiation"), but it should
also be possible to operate MLS in a "deniable" mode where such proof
is not possible.
Draft: draft-ietf-mls-architecture

Commentary: Thank you !
Group membership is itself sensitive information and MLS is designed
so drastically limit the amount of persisted metadata.  However,
large groups often require an infrastructure which provides server
fanout.  In the case of client fanout, the destinations of a message
is known by all clients, hence the server usually does not need this
information.  However, they may learn this information through
traffic analysis.  Unfortunately, in a server side fanout model, the
DS can learn that a given client is sending the same message to a set
of other clients.  In addition, there may be applications of MLS in
which the group membership list is stored on some server associated
with the DS.
Group membership is itself sensitive information and MLS is designed
to drastically limit the amount of persisted metadata.  However,
large groups often require an infrastructure which provides server
fanout.  In the case of client fanout, the destinations of a message
is known by all clients, hence the server usually does not need this
information.  However, they may learn this information through
traffic analysis.  Unfortunately, in a server side fanout model, the
DS can learn that a given client is sending the same message to a set
of other clients.  In addition, there may be applications of MLS in
which the group membership list is stored on some server associated
with the DS.
Draft: draft-ietf-mls-architecture

Commentary: Fix typo . 
 Thanks you !
with the MS.
with the DS.
Draft: draft-ietf-mls-architecture

Commentary: Thank you !
Messaging Layer Security (MLS) specifies an architecture (this
document) and an abstract protocol MLSPROTO for providing end-to-end
security in this setting.  MLS is not intended as a full instant
messaging protocol but rather is intended to be embedded in a
concrete protocol such as XMPP RFC6120.  In addition, it does not
specify a complete wire encoding, but rather a set of abstract data
structures which can then be mapped onto a variety of concrete
encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON
RFC7159.  Implementations which adopt compatible encodings will have
some degree of interoperability at the message level, though they may
have incompatible identity/authentication infrastructures.  The MLS
protocol has been designed to provide the same security guarantees to
all users, for all group sizes, even when it reduces to only two
users.
Messaging Layer Security (MLS) specifies an architecture (this
document) and an abstract protocol MLSPROTO for providing end-to-end
security in this setting.  MLS is not intended as a full instant
messaging protocol but rather is intended to be embedded in a
concrete protocol such as XMPP RFC6120.  In addition, it does not
specify a complete wire encoding, but rather a set of abstract data
structures which can then be mapped onto a variety of concrete
encodings, such as TLS RFC8446, CBOR RFC7049, and JSON RFC7159.
Implementations which adopt compatible encodings will have some
degree of interoperability at the message level, though they may have
incompatible identity/authentication infrastructures.  The MLS
protocol has been designed to provide the same security guarantees to
all users, for all group sizes, even when it reduces to only two
users.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS I-D.ietf-tls-tls13.
However, as noted above, the security of MLS will generally survive
compromise of the transport layer, so long as identity keys provided
by the AS are authenticated at a minimum.  However, MLS ciphertext
contain the Group Identifier, Epoch number and Content Type that may
be use to improve attacks on the privacy of the group.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS RFC8446.  However, as
noted above, the security of MLS will generally survive compromise of
the transport layer, so long as identity keys provided by the AS are
authenticated at a minimum.  However, MLS ciphertext contain the
Group Identifier, Epoch number and Content Type that may be use to
improve attacks on the privacy of the group.
Draft: draft-ietf-mls-architecture

Commentary: This PR aims to fix some odd formulations , whilst maintaining the intended meaning of the sentences . 
 Thanks !
This document describes the reference architecture, functional and
security requirements for the Messaging Layer Security (MLS)
protocol.  MLS provides a security layer for group messaging
applications with from two to a large number of clients.  It is meant
to protect against eavesdropping, tampering, and message forgery.
This document describes the reference architecture, functional and
security requirements for the Messaging Layer Security (MLS)
protocol.  MLS provides a security layer for group messaging
applications, where the number of clients ranges from two to many.
It is meant to protect against eavesdropping, tampering, and message
forgery.
An Authentication Service (AS) which is responsible for
maintaining user long term identities, issuing credentials which
allow them to authenticate each other, and potentially allowing
users to discover each others long-term identity keys.
An Authentication Service (AS) which is responsible for
maintaining user long term identities, issuing credentials which
allow them to authenticate each other, and potentially allowing
users to discover each other's long-term identity keys.
The protocol is designed in a way that limits the server-side (AS and
DS) metadata footprint.  The DS only persists data required for the
delivery of messages and avoid Personally Identifiable Information
(PII) or other sensitive metadata wherever possible.  A Messaging
Service provider that has control over both the AS and the DS, will
not be able to correlate encrypted messages forwarded by the DS, with
the initial public keys signed by the AS.
The protocol is designed in a way that limits the server-side (AS and
DS) metadata footprint.  The DS only persists data required for the
delivery of messages and avoids Personally Identifiable Information
(PII) or other sensitive metadata wherever possible.  A Messaging
Service provider that has control over both the AS and the DS, will
not be able to correlate encrypted messages forwarded by the DS, with
the initial public keys signed by the AS.
Draft: draft-ietf-mls-architecture

Commentary: There were some odd formulations in section 3.1.3 . I hope I addressed those issues without changing the intended meaning .
It is typically expected for users within Group to own different
devices.
A new device can be added to a group by sharing of an existing client
secrets or be considered as a new client by the protocol.  This
client will not gain access to the history even if it is owned by
someone who owns another member of the Group.  Restoring history is
typically not allowed at the protocol level but applications can
elect to provide such a mechanism outside of MLS.
It is typically expected for users within a Group to own different
devices.
A new device can either be added to a group by sharing secrets of an
existing client or be considered as a new client by the protocol.
This client will not gain access to the history even if it is owned
by someone who owns another member of the Group.  Restoring history
is typically not allowed at the protocol level but applications can
elect to provide such a mechanism outside of MLS.
MLS adopts the Internet threat model RFC3552 and therefore assumes
that the attacker has complete control of the network.  It is
intended to provide the security services described in in the face of
such attackers.  In addition, these guarantees are intended to
degrade gracefully in the presence of compromise of the transport
security links as well as of both clients and elements of the
messaging system, as described in the remainder of this section.
MLS adopts the Internet threat model RFC3552 and therefore assumes
that the attacker has complete control of the network.  It is
intended to provide the security services described in the face of
such attackers.  In addition, these guarantees are intended to
degrade gracefully in the presence of compromise of the transport
security links as well as of both clients and elements of the
messaging system, as described in the remainder of this section.
Draft: draft-ietf-mls-architecture

Commentary: In the section 3.1.7 . Compatibility with future versions of MLS , the word " messages " is duplicated . 
 Thanks
It is important that multiple versions of MLS be able to coexist in
the future.  Thus, MLS offers a version negotiation mechanism; this
mechanism prevents version downgrade attacks where an attacker would
actively rewrite messages messages with a lower protocol version than
the ones originally offered by the endpoints.  When multiple versions
of MLS are available, the negotiation protocol guarantees that the
version agreed upon will be the highest version supported in common
by the group.
It is important that multiple versions of MLS be able to coexist in
the future.  Thus, MLS offers a version negotiation mechanism; this
mechanism prevents version downgrade attacks where an attacker would
actively rewrite messages with a lower protocol version than the ones
originally offered by the endpoints.  When multiple versions of MLS
are available, the negotiation protocol guarantees that the version
agreed upon will be the highest version supported in common by the
group.
Draft: draft-ietf-mls-architecture

Commentary: Should I add a sentence in the protocol document as well ?
The Delivery Service is also responsible for allowing users to add,
remove or update their initial keying material and to ensure that the
identifier for these keys are unique accross all keys stored on the
DS.