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

Commentary: Just some nits I noticed .
A certificate authority or similar service which signs some sort
of portable credential binding an identity to a key.
A certification authority or similar service which signs some sort
of portable credential binding an identity to a key.
To route messages between Clients and to act as a message
broadcaster, taking in one message and forwarding it to multiple
Clients (also known as "server side fanout").
Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely
on the deletion and replacement of keying material, any Client which
is persistently offline may still be holding old keying material and
thus be a threat to both FS and PCS if it is later compromised.  MLS
does not inherently defend against this problem, but MLS-using
systems can enforce some mechanism for doing so.  Typically this will
consist of evicting Clients which are idle for too long, thus
containing the threat of compromise.  The precise details of such
mechanisms are a matter of local policy.
Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely
on the deletion and replacement of keying material, any Client which
is persistently offline may still be holding old keying material and
thus be a threat to both FS and PCS if it is later compromised.  MLS
does not inherently defend against this problem, but MLS-using
systems can enforce some mechanism for doing so.  Typically this will
consist of evicting Clients which are idle for too long, thus
containing the threat of compromise.  The precise details of such
mechanisms are a matter of local policy and beyond the scope of this
document.
It is important the 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 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: We need an IANA considerations section even if we make no requests of them . It 's just part of the process and the section can be removed during the final publication phase .
Finally, Clients should not be able to perform DoS attacks denial-of-
service.
Draft: draft-ietf-mls-architecture

Commentary: Text stolen from mls - protocol to let people know where to find the GH pages .
The source for this draft is maintained in GitHub.  Suggested changes
should be submitted as pull requests at https://github.com/mlswg/mls-
architecture.  Instructions are on that page as well.  Editorial
changes can be managed in GitHub, but any substantive change should
be discussed on the MLS mailing list.
Draft: draft-ietf-mls-architecture

Commentary: Change reference to XMPP to the current RFC . Change heading of " Deniability " section , which also discusses non - repudiation , to " Non - Repudiation and Deniability " . I wondered if that latter section should note that a third - party ( ie , non - Member ) can not identify a sender from a given encrypted message , but then I wondered if that was the case or not . 
 Thanks !
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 RFC3920.  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.
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.
Draft: draft-rescorla-mls-architecture

Commentary: Clarifications on PCS and cross - reference on first occurrence .
Bob and/or Charlie respond to Alice's message.  Their messages
might trigger a new key derivation step which allows the shared
group key to be updated, thus providing post-compromise security.
Bob and/or Charlie respond to Alice's message.  Their messages
might trigger a new key derivation step which allows the shared
group key to be updated to provide post-compromise security fs-
and-pcs.
MLS provides additional protection regarding secrecy of past messages
and future messages.  These cryptographic security properties are
Perfect Forward Secrecy (PFS) and Post-Compromise Security (PCS).
PFS ensures that access to all encrypted traffic history combined
with an access to all current keying material on clients will not
defeat the secrecy properties of messages older than the oldest key.
Note that this means that clients have the extremely important role
of deleting appropriate keys as soon as they have been used with the
expected message, otherwise the secrecy of the messages and the
security for MLS is considerably weakened.
MLS provides additional protection regarding secrecy of past messages
and future messages.  These cryptographic security properties are
Perfect Forward Secrecy (PFS) and Post-Compromise Security (PCS).
PFS ensures that access to all encrypted traffic history combined
with an access to all current keying material on clients will not
defeat the secrecy properties of messages older than the oldest key
of the client.  Note that this means that clients have the extremely
important role of deleting appropriate keys as soon as they have been
used with the expected message, otherwise the secrecy of the messages
and the security for MLS is considerably weakened.
Draft: draft-rescorla-mls-architecture

Commentary: As per   meetup , malicious insiders should be considered as a potential threat , though perhaps in a restricted set of scenarios . It is probably bad if a malicious group member can trivially DoS people , for example , as in naïve ART .
In general we do not consider denial of service to be the
responsibility of the protocol.  However, it should not be possible
for anyone to perform a trivial denial of service from which it is
hard to recover.
Draft: draft-rescorla-mls-architecture

Commentary: Add user stories
Roles: Users in groups have equal rights for managing groups and
sending messages, unless specified otherwise outside the protocol.
Draft: draft-rescorla-mls-architecture

Commentary: As usual , rough push . Multiple passes needed .
The trust establishment step of the MLS protocol is followed by a
conversation protection step where encryption is used by clients to
transmit authenticated messages to other clients through the DS.
This ensures that the DS doesn't have access to this Group-private
content.  MLS provide security properties such repudiability and
unlinkability additionnally to message secrecy, integrity and
authentication (see below).
Message Secrecy in the context of MLS means that only intended
recipients, currently valid members of the group, should be able to
read the message.  A corollary to that statement is that AS and DS
can't read the content of messages sent between Members as they are
not Members of the Group.  It is expected from MLS to optionnally
provide additional protections regarding traffic analysis techniques
to reduce the ability of adversaries or a compromised member of the
messaging system to deduce the content of the messages depending on
(for example) their size.  One of these protection is typically
padding messages in order to produce ciphertexts of standard length.
While this protection is highly recommended it is not mandatory as it
can be costly in terms of performance for clients and the MS.
MLS provides additional protection regarding secrecy of past messages
and future messages.  These cryptographic security properties are
Perfect Forward Secrecy (PFS) and Post-Compromise Security (PCS).
PFS ensures that access to all encrypted traffic history combined
with an access to all current keying material on clients will not
defeat the secrecy properties of messages older than the oldest key.
Note that this means that clients have the extremely important role
of deleting appropriate keys as soon as they have been used with the
expected message, otherwise the secrecy of the messages and the
security for MLS is considerably weakened.
Message Integrity and Authentication are properties enforced by MLS.
When the protocol is under attack, it is typically expected by the
threat model that messages will be altered, dropped or substituted by
the adversary.  MLS guarantees that under these circumstances an
honest client will not accept one of these scenarios and will reject
messages modified in transit or that have not by successfully
authenticated as a message from the correct Member.
Draft: draft-rescorla-mls-architecture

Commentary: The current naming is confusing : MS stands for " Message Switch " and " Messaging Server " but not for " Messaging Service " AS stands for " Authentication Server " and " Authentication Service " . The proposed change gives : MS as " Messaging Service " ( AS * + DS ) AS as " Authentication Service " DS as " Delivery Service " the " Server"s being the endpoints and not the functionality
An Authentication Server (AS) which is responsible for maintaining
user identities, issuing credentials which allow them to
authenticate to each other, and potentially distributing user
keying material.
A Message Switch (MS) which is responsible for delivering messages
between users.  In the case of group messaging, the message switch
may also be responsible for acting as an "exploder" where the
sender sends a single message to a group and the switch then
forwards it to each recipient.
In many systems, the AS and the MS are actually operated by the same
entity and may even be the same server.  However, they are logically
distinct and, in other systems, may be operated by different entities
so we show them as separate here.  Other partitions are also
possible, such as having a separate directory server.
An Authentication Service (AS) which is responsible for
maintaining user identities, issuing credentials which allow them
to authenticate to each other, and potentially distributing user
keying material.
A Delivery Service (DS) which is responsible for delivering
messages between users.  In the case of group messaging, the
delivery service may also be responsible for acting as an
"exploder" where the sender sends a single message to a group and
the switch then forwards it to each recipient.
In many systems, the AS and the DS are actually operated by the same
entity and may even be the same server.  However, they are logically
distinct and, in other systems, may be operated by different entities
so we show them as separate here.  Other partitions are also
possible, such as having a separate directory server.
Alice, Bob, and Charlie authenticate to the MS and store some
keying material which can be used to encrypt to them for the first
time.
When Alice wants to send a message to Bob and Charlie, she
contacts the MS and looks up their keying material.  She uses
those keys to establish a set of keys which she can use to send to
Bob and Charlie.  She then sends the encrypted message(s) to the
MS, which forwards them to the ultimate recipients.
Alice, Bob, and Charlie authenticate to the DS and store some
keying material which can be used to encrypt to them for the first
time.
When Alice wants to send a message to Bob and Charlie, she
contacts the DS and looks up their keying material.  She uses
those keys to establish a set of keys which she can use to send to
Bob and Charlie.  She then sends the encrypted message(s) to the
DS, which forwards them to the ultimate recipients.