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

[Sean Turner <[e-mail]>]

Richard suggested we put back the 1st para.  I incorporated that change into the PR:
https://github.com/mlswg/wg-materials/pull/16/files

spt

> On Jan 24, 2024, at 21:59, Sean Turner <[e-mail]> wrote:
> 
> I took a stab at removing the intro.  We can review tomorrow:
> https://github.com/mlswg/wg-materials/pull/16
> 
> spt
> 
>> On Jan 24, 2024, at 11:36, Sean Turner <[e-mail]> wrote:
>> 
>> 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.
>>> 
>>> 
>>> 
>> 
>