Markdown Version | Session Recording

Session Date/Time: 04 Dec 2024 17:00

MIMI

Summary

This interim meeting focused on reviewing open issues across the adopted MIMI protocol and content format documents. Key discussions revolved around establishing concrete transport and encoding mechanisms, clarifying policy definitions, addressing security considerations related to timestamps and message ordering, and refining how historical data and replies are handled. Several issues were closed, while others require further discussion on the mailing list or new proposals to be drafted.

Key Discussion Points

• Agenda Review: The chairs (led by Roman) requested participants to note well the IETF Code of Conduct and intellectual property policies. The agenda centered on reviewing open issues for the MIMI protocol and content format documents, as the room policy document had no open items. A decision was made to prioritize issues over open pull requests.
• MIMI Protocol Document Issues:
  • Room metadata: The issue is considered addressed by the new draft-mimi-room-policy document. Rowan will send a message to the mailing list to confirm if this resolution is satisfactory to previous commentators.
  • Support external media requests: This issue is blocked by the need to articulate a consistent threat model. It was suggested that the threat model should be developed either in the protocol or architecture document, with a sense of those present indicating the architecture document as a natural fit.
  • Binary encoding for Mimi transport (Issue 25) and Transport semantics (Issue 26): The documents currently list TLS (presentation language/codec) and HTTPS as notional. The proposal is to conduct a consensus call on the mailing list to make these choices concrete, in the absence of concrete alternatives.
  • Shape of policy: With the adoption of a separate room policy document, it was decided to close this issue and migrate any relevant discussions to the new policy document's repository.
  • Continue fetching key packages directly: This issue was closed as the design has evolved to resolve key packages through the Hub, rendering the direct fetching mechanism obsolete.
  • Knock knock. Do we need 'em?: The utility of a "knock knock" feature in an end-to-end encrypted, federated context was questioned. Members were hesitant to define a clear use case or implementation strategy. A proposal to drop support if no compelling use cases are articulated will be sent to the mailing list.
  • XMPP compatibility: It was noted that there isn't interest within the WG for an XMPP-based protocol. The issue was closed, with the understanding that transport-related aspects of XMPP are covered by Issue 26.
  • Figure out versioning: This is considered a critical aspect for MIMI's long-term viability, particularly regarding allowing implementations to speak multiple protocol versions and enabling dynamic upgrades. Rowan will draft an initial proposal, with Rafael (Phoenix) offering to contribute based on their experience.
  • Add description of flows with pseudonyms: This issue was resolved by the merge of related PRs (PR 90/91).
  • Move franking assertion map to Mimi content (Issue 91): The protocol document currently depends on the content format for franking assertions. The proposed solution is for the content format document to describe franking for the MIMI protocol, thereby unlinking the two documents while allowing a stable reference. Rowan will detail this rationale in the issue.
• MIMI Content Document Issues:
  • CBOR encoding, decide if we want to tag URIs (Issue 16): Based on guidance from CBOR experts, if an item is always a URI, it should not be tagged. An action was noted to remove such tags from the document.
  • Do timestamps need time tags? (Issue 17): The discussion centered on whether sub-millisecond timestamp granularity is necessary, particularly for message ordering in busy groups. A mailing list discussion is required to establish consensus on this requirement.
  • Last-seen (Issue 25) and Sender timestamp in delivery reports (Issue 28): These issues involve complex security considerations around message ordering and potential manipulation by malicious hubs or clients. It was suggested that some of these concerns might be better addressed at the MLS app_a layer. A clear problem statement and threat model are needed before proceeding. Conrad will draft this problem statement.
  • Rationale and problems for additional hash in in-reply-to (Issues 29 and 34): The current use of a plaintext content hash in in-reply-to was identified as a potential forward secrecy vulnerability. Rafael proposed using a per-message unique salt (similar to the client franking key) hashed with the message content for in-reply-to, especially for history mechanisms. Conrad will draft a proposal for this mechanism and clarify the attacks it aims to mitigate.
  • Reference via RFC 2392 Ur and disposition in-line (Issue 30): Marvin requested more concrete guidance on handling inline HTML references. Rowan will draft a PR with proposed text.
  • Getting rid of part index (Issue 31): While desirable, eliminating explicit part indexing might complicate inline content references. Rowan will address this after work on Issue 30 is complete, proposing a solution on the mailing list.
  • Move franking assertion from Mimi protocol into Mimi content (Issue 33): This is the content-side counterpart to MIMI Protocol Issue 91.
  • Create registry for Mimi content extension map keys (Issue 36): Based on new appsync work by Richard Barnes, there's a need for a MIMI-specific registry of component IDs (e.g., ur:ietf:mimi:participant-list) for application state stored in MLS group context extensions.
• Implementation Update: Teimo, Marvin, and Rowan are actively working on MIMI content implementations, with more feedback and minor issues expected soon.

Decisions and Action Items

Decisions:

• MIMI Protocol #24 (Shape of policy): Closed. Discussions to move to the draft-mimi-room-policy document.
• MIMI Protocol #29 (Continue fetching key packages directly): Closed, as current design uses Hub resolution.
• MIMI Protocol #35 (Add description of flows with pseudonyms): Closed, resolved by PR 90/91.
• MIMI Protocol #32 (XMPP compatibility): Closed. Transport considerations are covered by MIMI Protocol #26.

Action Items:

• Rowan:
  • Email MIMI list regarding MIMI Protocol #23 (Room metadata) to confirm resolution by draft-mimi-room-policy.
  • Email MIMI list to establish consensus for making TLS presentation language (encoding) and HTTPS (transport) concrete (MIMI Protocol #25, #26).
  • Email MIMI list to request use cases for MIMI Protocol #20 (Knock knock), or propose dropping support if none.
  • Draft a proposal for versioning mechanisms (MIMI Protocol #36).
  • Add rationale for franking assertion dependency to MIMI Protocol #91.
  • Remove URI tags from the Mimi Content document (MIMI Content #16) (to be batched with other changes).
  • Email MIMI list for consensus on supporting sub-millisecond timestamps (MIMI Content #17).
  • Write a PR with proposed text for MIMI Content #30 (RFC 2392 Ur and disposition in-line).
  • Write text for MIMI Content #30, then revisit MIMI Content #31 (Getting rid of part index) and propose a solution on the mailing list.
  • Add a link to MIMI Protocol #91 in MIMI Content #33.
• Conrad:
  • Draft a problem statement and a proposal for a mechanism (using salt + message content hash) for MIMI Content #25 (Last-seen) and MIMI Content #29/#34 (Rationale and problems for additional hash in in-reply-to), potentially in collaboration with the MLS WG, with an aim for next year.
• Chairs:
  • Create a new issue for the threat model (MIMI Protocol #93), to be placed in the architecture document (related to MIMI Protocol #21).

Next Steps

• The next MIMI interim meeting is tentatively scheduled for March 18th. Attendees should check the working group page for accurate schedule and joining information.
• Participants are encouraged to follow up on the assigned action items and bring any further questions or proposals to the mailing list.
• Implementers are expected to continue their work on MIMI content and protocol, providing valuable feedback and new issues as they arise.
• Suggestions for future agenda items are welcome and can be sent to mimi@ietf.org.