Markdown Version | Session Recording

MLS

Summary

The MLS Working Group interim meeting addressed critical administrative and technical items. Key discussions included progress on the working group recharter and the architecture document, as well as a significant portion dedicated to triaging and discussing various proposed extensions. Decisions were made regarding the recharter text, a long-standing architecture comment on encrypted group operations, and the path forward for several extension drafts, including a new proposal for virtual clients and an early look at application state synchronization from the MIMI design team. Post-quantum combiners and attribute-based MLS were also presented.

Key Discussion Points

• Working Group Recharter:

  • Chairs presented updated recharter text following ISG comments, primarily removing historical context.
  • A sense of those present indicated no objection to the streamlined recharter approach.
  • It was agreed to retain a short introductory paragraph on the working group's purpose.

• Architecture Document (RFC 9420-bis comments):

  • Open Issue: "Recommended for encrypted group operations":
    • Discussion centered on the trade-offs of encrypting group operations (e.g., Commit messages).
    • Benjamin and others highlighted the desire for confidentiality vs. practical considerations for server intermediaries (e.g., caching for performance, authorization enforcement).
    • Richard noted current deployments (e.g., WebEx) not encrypting commits for scale, while decentralized networks (e.g., a client working with a decentralized network) require encryption.
    • It was acknowledged that while encryption is "morally correct," mechanisms for leaking necessary public information to servers are not standardized, or come at a higher cost.
    • A decision was made for Benjamin to work with the chairs to craft text for the informational document that highlights these trade-offs and avoids making a strong "must" recommendation that might conflict with existing or planned deployments, while still emphasizing confidentiality.
  • Other Editorial Comments: Benjamin confirmed he would review and address remaining comments, noting that some changes (e.g., using RFC 2119 language) would not be made as it's an informational document.
  • PR 243 (remove encrypted state on servers): After discussion about the existence of use cases for encrypted state on servers but lack of public references or specified mechanisms, it was decided to merge PR 243 and remove the contentious sentence.

• Extensions Triage and Discussion:

  • The chairs noted the growing list of proposed extensions and the need to prioritize and manage work.
  • General guidance: Smaller, broadly useful extensions might go into a single "MLS Extensions" document, while larger or more niche ones should be separate drafts.
  • Additional Credential Types (Richard):
    • Richard reiterated its readiness and implementation plans, requesting adoption.
    • Concerns about an external dependency (OpenID VC) potentially holding up the main MLS extensions document were raised.
    • It was agreed to proceed with adopting it as a separate document once the recharter is complete, with the possibility of merging it into the main extensions document later if timing aligns.
  • Common Operational Patterns / User Tree (Brendan): Brendan noted this is maturing in parallel with other drafts and has ongoing interest.
  • Virtual Clients (Conrad):
    • Conrad presented the concept of "virtual clients" allowing multiple "emulator clients" to cooperatively operate as a single MLS client (e.g., multi-device users, organizational hierarchies).
    • Benefits include performance gains in large groups (fewer members, cheaper updates), especially with PQ cipher suites, and metadata hiding.
    • Technical challenges discussed: synchronizing secret trees (potential need for puncturable PRFs, making it non-vanilla MLS compatible), and key storage (secure enclaves, shared secrets potentially outside hardware protection). Rafael clarified current secure enclave limitations for HPK keys but acknowledged Richard's note on Apple's evolving support.
    • Limitations identified: Difficulty for external entities to remove individual emulator clients, and complexities for new devices to externally join a virtual client setup.
    • The chairs encouraged further discussion and collaboration on the draft.
  • MIMI Application State Synchronization (Richard, Rowan):
    • Richard introduced early ideas from the MIMI design team for an extension to synchronize application-level state within an MLS group via a group context extension and a new proposal type (appsync).
    • Rowan elaborated on the concept of an application registry for state blobs and the debate between opaque vs. structured updates.
    • Conrad raised questions about the application ID registry (IANA) and potential overlap/interaction with the "safe extensions" draft. Richard suggested "safe extensions" are for modifying MLS behavior, while this is for generic application state agreement.
  • Post-Quantum Combiners (Cesson, BR):
    • Nick provided an update on CFRG's plan to develop generic combiners and potentially a single hybrid CHEM specification.
    • Cesson presented two flexible combiner approaches:
      • Key Management Session Combiner: Uses two groups (at least one MLS) to send an AEAD key in one session and the ciphertext (encrypted key) in the other.
      • Exporter Combiner: Uses classical and PQ MLS sessions, with exporter keys linking them. Classical sessions handle frequent (partial) commits for efficiency, while PQ sessions handle less frequent (full) commits, avoiding constant PQ costs.
    • BR emphasized the strategic, long-term focus beyond immediate hybrid solutions, aiming for efficiency and flexibility in PQ authentication.
    • Richard questioned the properties of the classical group given a quantum attacker and suggested a combined PQ migration draft.
    • Benjamin raised practical engineering concerns about synchronization between two groups and the need for a common framing format to maintain API simplicity for applications. BR proposed a use case where a PQ group serves as a key pool for hardening classical subgroups without direct synchronization.
  • Self-Remove (Rowan): Rowan discussed refreshing the self-remove draft, but also exploring an alternative where external commits could access all pending valid proposals, potentially making self-remove unnecessary and simplifying other external proposals (e.g., appsync). BR questioned its feasibility in decentralized environments.
  • MLS Key Package Context (Rowan): Still under consideration, with further thought needed on whether it belongs at the application or MLS layer.
  • Verifiable Credentials for Attribute-Based MLS (David):
    • David proposed using verifiable credentials and attributes for authentication in MLS groups (e.g., access based on university degree) instead of identity, aiming for greater privacy in decentralized settings.
    • Conrad requested clarification on the use case and how verification would occur (other group members verifying credentials).
    • The chairs offered to guide David in preparing an Internet Draft to present his ideas for further group discussion.

Decisions and Action Items

• Chairs (Sean/Nick):
  • Finalize and submit the streamlined recharter text, incorporating the agreed-upon introductory paragraph.
  • Initiate adoption calls for extensions that have demonstrated strong support (e.g., additional credential types) once the recharter is complete.
  • Assist David with the process of developing an Internet-Draft for Attribute-Based MLS.
• Benjamin:
  • Work with chairs to craft text for the architecture document's "recommended for encrypted group operations" comment, highlighting trade-offs.
  • Address remaining editorial comments on the architecture document.
  • Merge PR 243 for the architecture document.
• Richard:
  • Pursue the adoption of the "Additional Credential Types" draft as a separate document, working on its OpenID dependency.
  • Continue work on the MIMI AppState Sync proposal, considering its interaction with "safe extensions."
• Conrad:
  • Seek feedback and collaboration on the "Virtual Clients" draft, particularly regarding practical and security considerations.
• Rowan:
  • Refresh the "Self-Remove" draft or develop a new draft proposing the alternative mechanism for external commits accessing pending proposals, inviting collaboration.
  • Further consider the "MLS Key Package Context" extension.
• Cesson / BR:
  • Continue developing the flexible Post-Quantum Combiners proposals and share draft text for discussion on the mailing list, incorporating feedback on engineering and security aspects.
• David:
  • Work with the chairs to prepare an Internet-Draft for "Verifiable Credentials for Attribute-Based MLS" to present his ideas more formally to the WG.

Next Steps

• The chairs will move forward with the recharter and architecture document finalization in the coming weeks.
• Calls for adoption for established extensions (e.g., Additional Credential Types) will be initiated after the recharter is complete.
• Authors of new proposals (Virtual Clients, AppState Sync, Post-Quantum Combiners, Attribute-Based MLS) are encouraged to continue refining their drafts, circulate them on the mailing list, and seek collaborators for further development.
• The working group anticipates continuing discussions on these extensions at IETF 119 in Brisbane, with dedicated time expected.