mimi

Summary

This meeting covered several key aspects of the Mimi protocol, including protocol updates, anti-abuse mechanisms, metadata privacy enhancements, content formatting, room policy, and user discovery. Discussions focused on technical details, security considerations, and future directions of the protocol.

Key Discussion Points

Mimi Protocol Updates: Discussion covered recent PRs merged, including semi-private messaging, abuse reporting mechanisms, group info and ratchet tree protection, and a diagram explaining the franking mechanism.
Anti-Abuse Mechanisms (Franking): Extensive discussion of the franking mechanism for abuse reporting, including its security rationale, potential vulnerabilities (e.g., malicious follower servers), and integration with MLS. A request was made for a security review by CFRG.
Metadata Privacy: Review of efforts to enhance metadata privacy, including minimal metadata mode using pseudonyms and encryption. Key management challenges associated with pseudonymization were discussed.
Content Formatting: Discussion of various issues related to content formatting, including C-Bore encoding, self-deleting messages (relative vs. absolute expiration), GitHub flavored markdown, message editing, and last scene.
Room Policy: Presentation of room policy concepts, including membership styles, capabilities, and roles. Examples of strict administrator, cooperative, and moderated room policies were provided. A call for adoption of the room policy document was made.
User Discovery: Initial presentation of the user discovery problem, terminology (CSIP, MSP, CSI), and high-level requirements. Discussion covered the need for verifiably authorized mappings from CSIs to MSPs.

Decisions and Action Items

Mimi Architecture Draft: Rohan Mahy will repost the Mimi architecture draft, which has expired.
Agenda Swap: Conrad Cobbrook's presentation on pseudonyms will follow the Mimi Protocol presentation. Discovery will be discussed in the second session.
CFRG Review: Submit the franking mechanism to CFRG for a security review.
Room Policy Document Adoption: Issue a call for adoption of the Mimi room policy document to the mailing list.
Franking Issue 89: Discuss Franking Issue 89 relating to Malicious follower can mall server Frank? in an interim.

Next Steps

Continue discussion of User Discovery requirements after lunch.
Address open issues and cleanup existing PRs.
Harmonize web bug fix with attachment draft and perform a security analysis.
Further develop pseudonym draft.
Refine the definition of room policy.
Define a baseline identity mechanism and credential definitions.
Implement Mimi and provide feedback.

Session Date/Time: 07 Nov 2024 13:00

mimi

Summary

This meeting focused on a detailed review of the MIMI discovery requirements draft. The discussion covered recipient, sender, and discovery provider requirements, with a strong emphasis on privacy considerations, enumeration attacks, and the involvement of MSPs (Messaging Service Providers) and CSIPs (CSI Providers). Several points were raised concerning wording, clarity, and the feasibility of certain requirements. A decision was made to reframe the anti-enumeration requirement as a "should" rather than a "must" due to challenges in defining and measuring success. There was a call for adoption of a new draft after addressing comments raised during the meeting.

Key Discussion Points

Recipient Requirements:
- Debate on the phrasing of recipient vs. sender authentication and the need to align them.
- Concern raised about MSPs being able to impersonate any CSI and need for a mechanism like "ID Prover" to prevent this.
- Discussion of whether the mapping is from CSI to MSP or CSI-SSP pair.
- Word smithing to improve the clarity that the recipient must authorize mapping.
Sender Requirements:
- The "retrieve all mappings" requirement (number 4) was discussed in the context of distributed discovery providers and the implications for federation.
- Verification of mappings (number 5): Clarification of whether online interaction with CSIP is needed. General agreement on the need for a cryptographic means for senders to validate mappings.
Discovery Provider Requirements:
- Discussion about the meaning of "zero mappings exist" and its implications.
- Deep dive into Requirement 7 and the need for privacy. The discussion was framed around a need to not leak both sides of the graph.
- Concerns about potential oversharing between discovery providers (Requirement 8). Suggestions to ensure it's no more onerous than requirement 7.
- Agreement to remove "between clients and servers" from requirement 9.
- Extensive discussion around protecting mapping data against enumeration attacks (Requirement 10), including potential mitigation strategies and concerns about feasibility.
- Disagreement on how to enumerate. Is is the act of a bad actor that does not know anything? Or is it about linking more data than you should?
Interim Meetings:
- Confirmation that bi-weekly interims have been productive.
- General agreement to continue the bi-weekly cadence and canceling if there is nothing to discuss.

Decisions and Action Items

Action Item: Chairs to cut a new version of the draft.
Action Item: Chairs to tweak requirements to address comments raised during the meeting.
Action Item: Chairs to reframe requirement on enumeration attacks as a "should" instead of "must."
Decision: No more often than bi-weekly interims, with cancellations allowed if there is nothing to discuss.
Action Item: Chairs will follow up with Richard on room policy comments.

Next Steps

Circulate a new draft of the discovery requirements on the mailing list.
Open call for adoption of the updated draft.
Schedule the next bi-weekly interim meeting.
Chairs to submit the new milestones.