**Session Date/Time:** 26 Feb 2025 17:00

# [MIMI](../wg/mimi.html)

## Summary

This MIMI interim meeting focused on updates to both the MIMI Content and MIMI Protocol drafts, with significant discussion around managing open issues and a new proposal for unified client-to-Hub confidentiality and integrity mechanisms. Key updates for the content draft included guidance for multi-part content, rebuilt examples, and timestamp standardisation. For the protocol draft, progress on several PRs was noted, alongside a detailed discussion on key management for encrypted metadata in Minimal Metadata Rooms. A new proposal for "I-message" and "C-message" encapsulations was introduced to address client-Hub security requirements in a unified manner, with the chairs confirming this work is within the working group's charter.

## Key Discussion Points

*   **MIMI Content Draft Updates:**
    *   **PR #48 (Multi-part Content Guidance):** Introduced a paragraph providing guidance on handling multi-part content, specifically warning against double-rendering inline content referenced by Content ID. Teemo committed to reviewing this PR.
    *   **PR #46 (Examples & Consistency):** Restructured all examples to be script-generated, ensuring consistency and validation against the CDDL. This included:
        *   Standardising timestamps to use RFC 9581 (CBOR Extended Time), allowing for either integer or tagged values.
        *   Adopting URI Mimi URI style names.
        *   Mitigating a SHA-256 length extension attack by re-tapping the salt at the end of messages.
    *   **MIMI Content Issue Triage:**
        *   Many issues are tied to existing PRs and will be closed upon merging.
        *   An issue was created to register integer keys used for Mimi content extensions.
        *   Issues related to delivery reports were proposed to be left open due to a lack of implementation experience.
        *   Four issues proposing new functionality were suggested to be marked "won't fix" for now, with documentation on how they could be added as extensions in the future.

*   **MIMI Protocol Draft Updates:**
    *   Merged franking fixes, search structure changes, and consistency fixes since the O2 draft.
    *   Three open PRs were highlighted:
        *   **PR #101 (Handshake Bundle Fan-out):** Addresses how proposals within a handshake bundle are fanned out as a single unit, particularly for client self-removal scenarios.
        *   **PR #102 (Participant List & Room Metadata):** Proposes moving the participant list and room metadata from `draft-ietf-mimi-app-components` into `mimi-protocol`.
        *   **Minimal Metadata Rooms (MMR) PR:** Aims for improved privacy by reducing metadata exposure, including a credential for pseudonyms and real identity encryption, and related key management.

*   **Key Management for Encrypted Metadata:**
    *   Discussion on the current static key approach in the MMR PR being unsatisfactory for key management.
    *   A more robust key wrapping scheme (similar to MLS key trees) is envisioned to provide forward secrecy and post-compromise security, working even after a participant leaves the group.
    *   A sense of those present indicated comfort with merging the credential-related aspects of the MMR PR now, while deferring the generic key management solution for later development.

*   **I-Message and C-Message Proposal (Client-Hub Security):**
    *   Richard proposed designing a unified confidentiality encapsulation ("C-message") and/or an integrity encapsulation ("I-message") for all communications between clients and the Hub.
    *   This proposal aims to replace the current semi-private message mechanism and address franking requirements in a less complex, more unified way.
    *   **Security Considerations:** Extensive discussion on key management and authentication.
        *   Concern was raised about potential man-in-the-middle attacks by follower servers if the Hub's key is not sufficiently authenticated or agreed upon by the group.
        *   Options explored included 1:1 MLS sessions, a second MLS group including the Hub, or synchronising symmetric keys.
        *   Using the Hub as an external sender in MLS, with its signature key authenticated within the group, was seen as a promising direction.
    *   **Charter Scope:** Rowan raised a question about the charter's allowance for defining new cryptographic mechanisms outside of MLS. The chairs clarified that while the charter prohibits *extensions to MLS*, defining mechanisms for client-to-Hub communication that are external to MLS itself, if necessary for MIMI, is within scope. Implementers are more concerned with overall complexity than the specific document where such mechanisms are defined.

## Decisions and Action Items

*   **Decision:** For MIMI Content issues where there is no active author commitment, the working group agreed to close them, ensuring a record of the rationale is maintained in the issue.
*   **Decision:** For MIMI Protocol's Minimal Metadata Rooms (MMR) PR, the working group agreed to merge the credential-related aspects first, with the more generic key management scheme to be developed and added later.
*   **Decision:** The proposed work on "I-message" and "C-message" for unified client-to-Hub confidentiality and integrity encapsulations was deemed to be within the MIMI working group's charter.

*   **Action Item (Rowan):** Update the Mimi content draft on the data tracker to reflect merged changes.
*   **Action Item (Rowan):** Create a PR to register the integer keys used for Mimi content extensions.
*   **Action Item (Teemo):** Review PR #48 (multi-part content guidance) for Mimi content.
*   **Action Item (Conrad):** Work on the key management solution for encrypted metadata and "connection stuff" related to PR #101.
*   **Action Item (Richard, Conrad, Rowan):** Iterate on the I-message and C-message proposal, potentially drafting a small standalone document or a detailed mailing list post to gather further input, before integrating into Mimi protocol.

## Next Steps

*   The working group participants (Richard, Conrad, Rowan) will continue to refine the I-message and C-message proposal, addressing the security and key management considerations raised.
*   Chairs reminded the working group to consider and propose agenda items for the upcoming IETF 122 meeting.