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

[Sean Turner <[e-mail]>]

Hi! Brendan had another grammar fix that I incorporated. Squashed and merged the recharter text. Will forward it on to Paul.

spt

> On Jan 25, 2024, at 12:23, Sean Turner <[e-mail]> wrote:
> 
> 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.
>>>> 
>>>> 
>>>> 
>>> 
>> 
>