Session Date/Time: 09 Feb 2023 15:00

MLS

Summary

The MLS Working Group held an interim meeting to review and address comments received from the IESG on the draft-ietf-mls-protocol and draft-ietf-mls-architecture documents. The primary goal was to resolve outstanding issues to facilitate ISG approval and move both drafts into the RFC Editor's queue before the new ISG is seated, ideally by the end of March. The meeting covered several Pull Requests (PRs) for both documents, leading to agreement on most proposed changes and specific wording for several technical points.

Key Discussion Points

Interop Testing Update: Richard mentioned ongoing interoperability testing between multiple MLS implementations (mlspp, OpenMLS, Wicker stack, Inria static, RingCentral participation is sought). Initial testing has revealed minor bugs (e.g., byte field usage). A follow-up call and a dedicated Slack channel (ietf.slack.com) are coordinating these efforts.
Protocol Document (draft-ietf-mls-protocol)
- PR #855: Clarifying Transcription Initialization: Richard introduced this PR, which clarifies how the interim and confirmed transcript hashes are initialized (to zero-length strings). This is a clarification, not a behavior change, and includes a new figure to illustrate the timeline.
  - Brandon raised a concern about the figure's width in text renderings, which Richard and Conrad will address.
  - Raphael confirmed that implementations already agree on the behavior, so this is purely descriptive.
  - Consensus: Tentative agreement to merge, pending Richard and Conrad's satisfaction with the figure's rendering.
- PR #844: Cleanup after Plaintext and Side Effects from Naming: Conrad highlighted this minor cleanup PR for names of labels, which Richard confirmed he had reviewed and approved.
- Other ISG Comments: The remaining PRs on the protocol document were deemed to have adequately addressed ISG review comments, with no further discussion needed on this call.
Architecture Document (draft-ietf-mls-architecture)
- PR #182: Clarification of Terms: Rowan presented this PR, which adds narrative explanations for terms defined in the protocol document but used in architecture. It evolved from a glossary to a narrative style.
  - Britta's suggestion to clarify "Leaf node" to "initiation Leaf node" was accepted to avoid misinterpretation of static state.
  - Consensus: Agreement to merge, with Richard taking the action to push the button including Britta's suggestion.
- PR #187: Fix Author Email Addresses: This PR addresses bounce issues from outdated author email addresses.
  - Consensus: Agreement to merge. Rowan will follow up with one author regarding their affiliation.
- PR #183: Addressing AD Reviews: Rowan detailed numerous changes across this PR, addressing three AD reviews.
  - Key Transparency Reference: Changed from an expired Google project to the "Connex" paper.
  - End-to-End Security: Clarified that end-to-end security is widely used in IM and applicable to other systems (calling, conferencing). Raphael noted the ongoing work on an IETF E2E definition, but the current reference is informational.
  - Scale Consistency: Adopted "tens of thousands" as a consistent scale for group sizes, noting it's an arbitrary but well-tested number by implementations (e.g., Matrix).
  - Public Key Infrastructure (PKI): Clarified PKI roles to include existing roles like Certificate Authorities.
  - Key Package Purpose: Added text explaining the purpose of key packages, including authentication, AD proposals, and ephemeral key encryption.
  - Security Description: Changed "safety" to "provide both performance and security (e.g., integrity and confidentiality)" for MLS users.
  - "Delivering messages": Changed "to a group" to "for a group" to clarify the delivery service's (DS) function in relaying messages addressed to a group to individual members.
  - Privacy Wording: Clarified that MLS assumes a transport layer for metadata privacy, while MLS itself provides confidentiality, integrity, and authentication for application data. Additional properties like partial anonymity or deniability can be achieved through specific architecture designs.
  - Anonymous Credentials for DoS Prevention: Rephrased from "Anonymous credentials" to "use credentials uncorrelated with specific users to help prevent DoS attacks in a privacy preserving manner" in the context of credential issuer DoS protection, to avoid undefined terminology.
  - Deniability: Discussion arose about a contradictory statement regarding deniability. Raphael suggested reverting the proposed change, arguing the prior text better reflected the vagueness of the term and that it was a non-blocking AD comment.
    - Decision: Revert the proposed change on deniability and return to the previous wording.
  - Tone of Language: Toned down instances of "very" or "extremely."
  - Message Deletion: Changed "immediately after encryption or decryption" to "as soon as practical after encryption or decryption" to acknowledge practical display requirements.
  - Correlating Legal Requests: Added a note about the ease of correlating legal requests for push tokens with device information.
  - "Centralized Server": Left "centralized server" as is, rather than changing to "central server," due to numerous existing references. Brendan was fine with this.
  - X.509 Verification "Autonomously": Changed "autonomously" in the context of x.509 verification to "without user interaction," clarifying the intended meaning in contrast to requiring user action for credential verification.
  - Key Transparency in Recommendations: Generalized a recommendation from specifically "key transparency" to "provide one or more out of band authentication mechanisms to limit the impact of an authentication service compromise," while retaining key transparency in other relevant recommendations. Brendan was fine with this.
  - Encrypted Group Operations: Changed "always using Cryptid group operation messages" to "use encrypted group operation messages to limit privacy risks whenever possible" to accommodate legitimate uses of unencrypted messages when enclosed in an encrypted transport.
  - PKI Terminology: Minor change from "certificate authorities" to "certification authorities."
  - Consensus: Agreement to merge PR #183 with the discussed modifications.
- Zahad Sarker's "Discuss" Comment (Secure Transport Recommendation): This discuss comment questioned the lack of an explicit recommendation for using secure transport for MLS. Richard presented a proposed text.
  - Britta highlighted concerns about prescriptive language if applications cannot use TLS/QUIC. Rowan agreed that any statement should be advisory, emphasizing metadata confidentiality and reliable delivery.
  - Decision: Add a new sentence to Section 7.1 (Assumptions on Transport Security): "It is recommended to use secure transports that provide reliable delivery and protect metadata confidentiality whenever possible, such as TLS or QUIC. If other transports are used, implementers should explain how these properties are provided." Rowan will include this in an existing PR.
IETF 116 Session Planning:
- Sean noted that with the documents heading to the RFC Editor queue, the main work shifts to copy editing and potential Auth48 review (2-3 months). Future work includes Federation and Extensions.
- Rowan advocated for requesting a session for IETF 116 (Yokohama) to demonstrate the working group is active, especially with external interest (e.g., Digital Markets Act workshop discussions on MLS interoperability). He suggested focusing on MLS Extensions and Federation.
- Raphael supported having a session, noting his likely attendance.
- Decision: Request an hour-long MLS Working Group session for IETF 116, likely on a Thursday or Friday afternoon, to discuss MLS Extensions and Federation documents. Rowan will prepare presentations for these topics.
Unaddressed ART Area Comments: Rowan brought up three ART area comments that were not "discuss" blockers but remain points of interest:
1. Lack of a strong narrative on extensibility.
2. Unclear impact of Delivery Service (DS) implementation choices on client behavior.
3. Difficulty of client removal from a group.
- Rowan acknowledged these are important but do not belong in the architecture document as long treatises. He offered to collaborate on non-WG drafts for these if there is interest.
- Consensus: The working group agrees these are important considerations for future work or external discussion but should not be added to the current architecture document.

Decisions and Action Items

PR #855 (Protocol Document): Tentatively agreed to merge, pending Richard and Conrad's final review of the figure's rendering.
PR #844 (Protocol Document): Merge.
PR #182 (Architecture Document): Merge, including Britta's suggestion for "initiation Leaf node." Richard will push the button.
PR #187 (Architecture Document): Merge. Rowan will reach out to the author regarding affiliation.
PR #183 (Architecture Document): Merge, with the specific changes discussed (e.g., deniability revert, x.509 wording, encrypted group operations). Rowan will implement the changes, and Richard will push the button.
Zahad Sarker Discuss Comment: Add the following text to Section 7.1 of the architecture document: "It is recommended to use secure transports that provide reliable delivery and protect metadata confidentiality whenever possible, such as TLS or QUIC. If other transports are used, implementers should explain how these properties are provided." Rowan will add this to an existing PR.
IETF 116 Session: Request an hour-long MLS Working Group session for IETF 116 (likely Thursday/Friday afternoon) to discuss MLS Extensions and Federation documents. Rowan will prepare presentations.
Minor Edits: Richard to address any formatting issues remaining from PR merges. Nick's readability comments on the architecture document will be addressed offline before sending to the RFC Editor.

Next Steps

Working Group Chairs and Authors will finalize the discussed Pull Requests for both documents and push new versions.
Once ADs clear the "discusses," the documents will be submitted for ISG approval.
Upon ISG approval, the documents will enter the RFC Editor's queue, anticipated to take 2-3 months before publication as RFCs, including an Auth48 review phase.
The Working Group will proceed with work on the MLS Extensions and Federation documents, with an IETF 116 session requested to discuss progress.
Consideration of MLSv2 and other long-term topics will follow initial publication.
The three unaddressed ART area comments (extensibility, DS implementation impact, client removal difficulty) will be kept in mind for potential future discussions or separate informational drafts.