Messaging Layer Security
charter-ietf-mls-01-00

My comments can be summed up as agreement with Éric’s "May I also suggest 
to reduce the leading part of the charter about the history and achievements 
of the MLS WG?”. If the history is to be kept (which I don't prefer, 
even after reading Sean's reply, but wouldn't block on) then there are 
a bunch of errors that need to be fixed, noted below. The easiest fix though,
would be to just remove the historical parts.

> The Messaging Layer Security (MLS) protocol, RFC 9420, specifies a key
> establishment protocol that provides efficient asynchronous group key
> establishment with forward secrecy (FS) and post-compromise security (PCS)
> for groups in size ranging from two to thousands.

Fine. But I think you could remove the bullet list of properties. Anyone 
curious can go read the RFC, can't they?

But if the bullet list is retained, it needs a fix, noted below.

> 
> MLS has the following properties:
> 
> o Message Confidentiality - Messages can only be read
> by members of the group
> o Message Integrity and Authentication - Each message
> has been sent by an authenticated sender, and has
> not been tampered with
> o Membership Authentication - Each participant can verify
> the set of members in the group
> o Asynchronicity - Keys can be established without any
> two participants being online at the same time
> o Forward secrecy - Full compromise of a node at a point
> in time does not reveal past messages sent within the group
> o Post-compromise security - Full compromise of a node at a
> point in time does not reveal future messages sent within the group
> o Scalability - Resource requirements have good scaling in the
> size of the group (preferably sub-linear)

The parenthetical comment "(preferably sub-linear)" made sense in the 
previous charter, but doesn't make any sense in describing the properties
of an approved protocol specification. Either delete the parenthetical, 
or fix it.

> 
> It is not a goal of this group to enable interoperability/federation
> between messaging applications beyond the key establishment,
> authentication, and confidentiality services. Full interoperability
> would require alignment at many different layers beyond security,
> e.g., standard message transport and application semantics. The
> focus of this work is to develop a messaging security layer that
> different applications can adapt to their own needs.
> 
> While authentication is a key goal of this working group, it is not
> the objective of this working group to develop new authentication
> technologies. Rather, the MLS protocol provides a way to leverage
> existing authentication technologies to associate identities with
> keys used in the protocol, just as TLS does with X.509.

Again, I think the history lesson below seems surplus to requirements:

> 
> While developing the MLS protocol, the group drew on lessons learned
> from several prior message-oriented security protocols, in addition
> to the proprietary messaging security protocols deployed within
> existing applications:
> 
> o S/MIME - https://tools.ietf.org/html/rfc5751
> o OpenPGP - https://tools.ietf.org/html/rfc4880
> o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
> o Double Ratchet - https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
> 
> The working group followed the pattern of TLS 1.3, with specification,
> implementation, and verification proceeding in parallel. When we arrived
> at RFC, we had several interoperable implementations as well as a thorough
> security analysis.

If you think it's important to say "this is how the WG wants to work" then
I suggest re-wording it in terms like that instead of "this is what we did
before" which doesn't say anything about expectations going forward.

The next paragraph doesn't make any sense because its context is material
from the old charter, that was deleted for this one:

> 
> Note that consensus is required both for changes to the protocol mechanisms
> from these documents and retention of the mechanisms from them. In particular,
> because something is in the initial document set does not imply that there is
> consensus around the feature or around how it is specified.

I think the above paragraph can be deleted, or if you think it has 
a nugget in it that needs to be retained, it needs a rewrite.

> 
> Now that MLS has been published, the group will work on the following MLS
> protocol extensions:

You could drop "Now that MLS has been published" but whatever.

> 
> Support for use of MLS in protocols developed by the MIMI working group
> Support for new credential types
> Support for common operational patterns in messaging applications
> Support for quantum resistance
> Framework for safe extensibility
> Detection of lost application messages
> Support for sending messages to individual members of a group
> Many of extensions to support these features will be included in
> draft-ietf-mls-extensions, but some of the extensions will be published in
> seperate Internet-Drafts.
> 

The sentence above, parsed closely, seems to indicate you don't intend to
publish RFCs, just Internet Drafts. Probably s/Internet-Drafts/specifications/
I guess.

To be honest, I was about to ballot a BLOCK based on the absence of intended status for the work items in the charter itself.

May I also suggest to reduce the leading part of the charter about the history and achievements of the MLS WG?

It would also be nice to clear the MLS architecture document lingering in revised-ID-needed state for nearly one years.