Messaging Layer Security
charter-ietf-mls-02

[Ballot comment]
Are the seven named extensions intended to be in a single document (draft-ietf-mls-extensions)?  If not, please expand the milestone list to cover the expected documents.

[Ballot comment]
Nice text but I *strongly* suggest to indicate the intended status of all the work items; as we all know, there is a big difference between experimental and proposed standards. Let's be clear.

[Ballot comment]
I think that the reduction of MLS introduction (between charter proposal 01-00 and 01-01) is good progress. It makes the charter look more accurate and refreshed.

[Ballot comment]
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.

[Ballot comment]
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.
>

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
I'm looking at "In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols", and I'm wondering whether these lessons have already been written down, or if the working group plans to write them down. I don't see any mention of either an existing reference or a deliverable, so thought I would ask. Is a list of lessons learned something that would have value outside the work MLS would be chartered to do?

I saw Mirja's comment about naming drafts in the charter - that's actually a good thing to notice, because someone might argue that the working group isn't chartered to work on another approach, if the working group encounters problems with its initial direction.

One phrasing I see used, is something like

"The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol, based
on pre-standardization implementation and deployment experience, and generalizing the design described in draft-hamilton-quic-transport-protocol, draft-iyengar-quic-loss-recovery, draft-shade-quic-http2-mapping, and draft-thomson-quic-tls."

I also see charters that say something like "the working group will use draft-foo and draft-bar as a starting point".

-- not part of my ballot position, only curiosity --

I have an honest question (which will affect my ballot position in no way, so cluing me in privately would be a reasonable response).

I see people talking a lot more often about perfect forward secrecy than about

o Post-compromise security - Full compromise of a node at a
  point in time does not reveal future messages sent within the group

Is "post-compromise security" equally well understood in the community?

[Ballot comment]
Based on the feedback provided by Paul Wouters: What's the relationship to ORT?

Also a minor comment: Not sure if the drafts need to be listed in the charter. This seems very unusal as there should still be an adoption call (after the wg has been formed).