Messaging Layer Security
charter-ietf-mls-01-00
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-04
|
01-00 | John Scudder | [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 … [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. |
2024-01-04
|
01-00 | John Scudder | Ballot comment text updated for John Scudder |
2024-01-04
|
01-00 | John Scudder | [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 … [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. > |
2024-01-04
|
01-00 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-01-04
|
01-00 | Éric Vyncke | [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 … [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. |
2024-01-04
|
01-00 | Éric Vyncke | Ballot comment text updated for Éric Vyncke |
2024-01-03
|
01-00 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2024-01-03
|
01-00 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2024-01-03
|
01-00 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2024-01-03
|
01-00 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-01-02
|
01-00 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2024-01-02
|
01-00 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2024-01-02
|
01-00 | Éric Vyncke | [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 … [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? |
2024-01-02
|
01-00 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-12-20
|
01-00 | Cindy Morgan | WG action text was changed |
2023-12-20
|
01-00 | Cindy Morgan | WG review text was changed |
2023-12-20
|
01-00 | Cindy Morgan | WG review text was changed |
2023-12-20
|
01-00 | Cindy Morgan | Created "Ready for external review" ballot |
2023-12-20
|
01-00 | Cindy Morgan | State changed to Start Chartering/Rechartering (Internal Steering Group/IAB Review) from Draft Charter |
2023-12-19
|
01-00 | Paul Wouters | Telechat date has been changed to 2024-01-04 from 2018-05-24 |
2023-12-19
|
01-00 | Paul Wouters | Added charter milestone "Submit MLS extensions I-D to IESG as Proposed Standard", due December 2024 |
2023-12-19
|
01-00 | Paul Wouters | State changed to Draft Charter from Approved |
2023-12-19
|
01-00 | Paul Wouters | New version available: charter-ietf-mls-01-00.txt |
2022-03-23
|
01 | Amy Vezza | Responsible AD changed to Paul Wouters from Benjamin Kaduk |
2018-05-29
|
01 | Cindy Morgan | New version available: charter-ietf-mls-01.txt |
2018-05-29
|
00-03 | Cindy Morgan | State changed to Approved from External review |
2018-05-29
|
00-03 | Cindy Morgan | IESG has approved the charter |
2018-05-29
|
00-03 | Cindy Morgan | Closed "Approve" ballot |
2018-05-29
|
00-03 | Cindy Morgan | WG action text was changed |
2018-05-29
|
00-03 | Benjamin Kaduk | New version available: charter-ietf-mls-00-03.txt |
2018-05-24
|
00-02 | Benjamin Kaduk | [Ballot comment] I still need to tweak the language a little in response to comments received. |
2018-05-24
|
00-02 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-05-24
|
00-02 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-05-24
|
00-02 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-05-23
|
00-02 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2018-05-23
|
00-02 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-05-23
|
00-02 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-05-23
|
00-02 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-05-23
|
00-02 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-05-23
|
00-02 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2018-05-23
|
00-02 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-05-22
|
00-02 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-05-22
|
00-02 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-05-22
|
00-02 | Eric Rescorla | [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla |
2018-05-18
|
00-02 | Spencer Dawkins | [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 … [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? |
2018-05-18
|
00-02 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-05-18
|
00-02 | Mirja Kühlewind | [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 … [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). |
2018-05-18
|
00-02 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-05-14
|
00-02 | Amy Vezza | Telechat date has been changed to 2018-05-24 from 2018-05-10 |
2018-05-14
|
00-02 | Amy Vezza | Created "Approve" ballot |
2018-05-14
|
00-02 | Amy Vezza | Closed "Ready for external review" ballot |
2018-05-14
|
00-02 | Amy Vezza | State changed to External review from Internal review |
2018-05-14
|
00-02 | Amy Vezza | WG new work message text was changed |
2018-05-14
|
00-02 | Amy Vezza | WG review text was changed |
2018-05-14
|
00-02 | Amy Vezza | WG review text was changed |
2018-05-14
|
00-02 | Amy Vezza | WG review text was changed |
2018-05-10
|
00-02 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-05-10
|
00-02 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-05-10
|
00-02 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-05-09
|
00-02 | Ben Campbell | [Ballot comment] Should the first sentence be scoped to "messaging applications" or are we contemplating using this with other sorts of applications? |
2018-05-09
|
00-02 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-05-09
|
00-02 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-05-09
|
00-02 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2018-05-09
|
00-02 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-05-09
|
00-02 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-05-09
|
00-02 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-05-08
|
00-02 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-05-03
|
00-02 | Eric Rescorla | [Ballot comment] I am heavily involved |
2018-05-03
|
00-02 | Eric Rescorla | Ballot comment text updated for Eric Rescorla |
2018-04-30
|
00-02 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-04-28
|
00-02 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-04-28
|
00-02 | Benjamin Kaduk | Added charter milestone "Submit message protection protocol to IESG as Proposed Standard", due September 2019 |
2018-04-28
|
00-02 | Benjamin Kaduk | Added charter milestone "Submit key management protocol to IESG as Proposed Standard", due June 2019 |
2018-04-28
|
00-02 | Benjamin Kaduk | Added charter milestone "Submit architecture document to IESG as Informational", due January 2019 |
2018-04-28
|
00-02 | Benjamin Kaduk | Added charter milestone "Initial working group document adopted for message protection", due September 2018 |
2018-04-28
|
00-02 | Benjamin Kaduk | Added charter milestone "Initial working group documents for architecture and key management", due May 2018 |
2018-04-28
|
00-02 | Benjamin Kaduk | New version available: charter-ietf-mls-00-02.txt |
2018-04-28
|
00-01 | Benjamin Kaduk | WG action text was changed |
2018-04-28
|
00-01 | Benjamin Kaduk | WG review text was changed |
2018-04-28
|
00-01 | Benjamin Kaduk | WG review text was changed |
2018-04-28
|
00-01 | Benjamin Kaduk | Created "Ready for external review" ballot |
2018-04-28
|
00-01 | Benjamin Kaduk | State changed to Internal review from Informal IESG review |
2018-04-28
|
00-01 | Benjamin Kaduk | Placed on agenda for telechat - 2018-05-10 |
2018-04-28
|
00-01 | Benjamin Kaduk | Initial review time expires 2018-05-05 |
2018-04-28
|
00-01 | Benjamin Kaduk | State changed to Informal IESG review from Not currently under review |
2018-04-28
|
00-01 | Benjamin Kaduk | New version available: charter-ietf-mls-00-01.txt |
2018-04-28
|
00-00 | Benjamin Kaduk | Notification list changed to rlb@ipv.sx |
2018-04-28
|
00-00 | Benjamin Kaduk | New version available: charter-ietf-mls-00-00.txt |