Re: [MLS] John Scudder's No Objection on charter-ietf-mls-01-00: (with COMMENT)

[Sean Turner <[e-mail]>]

HI! I will take a stab at addressing these changes in the GH repo and we can discuss tomorrow.

spt

> On Jan 4, 2024, at 11:23, John Scudder via Datatracker <[e-mail]> wrote:
> 
> John Scudder has entered the following ballot position for
> charter-ietf-mls-01-00: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-mls/
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
>