**Session Date/Time:** 25 Jan 2024 18:00

# [TIGRESS](../wg/tigress.html)

## Summary

The TIGRESS Working Group held its first interim meeting of 2024 to discuss the two proposed relay server drafts: `draft-vinura-tigress-relay-server` (Draft V) and `draft-rola-tigress-relay-server` (Draft R). The meeting included a presentation comparing the two drafts on security, privacy, user experience, effectiveness, and deployability, followed by a detailed technical discussion on several comparison points. A significant portion of the meeting was dedicated to the IETF's process for establishing consensus and the current lack of broad participation from diverse stakeholders beyond the initial contributors. No decision was made regarding draft adoption, and the chairs indicated a need for consultation with the Area Directors on the future direction of the working group.

## Key Discussion Points

*   **Draft Comparison Presentation:** Yogesh presented a comparison of Draft V and Draft R, highlighting differences based on defined relay server requirements:
    *   **Security:**
        *   **Mailbox Identifier Uniqueness:** Draft V uses server-generated UUIDs for guaranteed uniqueness, while Draft R relies on client-generated random numbers. Debate ensued regarding the statistical probability of collisions for random numbers in cryptographic protocols, with Eric (Draft R author) and Aaron asserting that widely-accepted IETF protocols rely on similar assumptions, making Draft R's approach functionally sound.
        *   **Initiator/Recipient Binding:** Draft V uses "device claims" for binding. Draft R's author clarified that its design ensures only the first recipient gets the key through message deletion, and explicit cookies are not a core requirement for this security property, contrary to initial comparison claims.
        *   **Monitoring/Disruption with Known Mailbox ID:** Yogesh argued that in Draft R, if an attacker knows the initial mailbox identifier (`R`), they could potentially monitor or disrupt subsequent communication, especially if the client fails to delete messages promptly. Eric countered that the system involves a race condition similar to other protocols and that subsequent message addresses are obscured.
        *   **Lingering Mailboxes:** Draft V includes server-side periodic cleanup and lifetime guarantees for mailboxes. Draft R primarily relies on client-side deletion, which Yogesh noted could lead to security issues if clients crash or fail to delete. Eric stated that server-side cleanup could be added easily if deemed important.
    *   **Privacy:** Initial concerns regarding the use of cookies in Draft R for tracking were discussed and largely tabled, as Eric clarified that cookies are not essential to the design and context isolation could prevent tracking if they were used.
    *   **User Experience & Effectiveness:** The presentation outlined differences in handling notifications, invitation channels, and message flows (e.g., turn-taking, cancellations), with Draft V claiming better support.
    *   **Deployability:** Yogesh and Matias highlighted that Draft V is currently deployed in various verticals (car connectivity, scooter keys, multi-family homes) by multiple device manufacturers for over two years, positioning it as a proven solution.
*   **IETF Process and Consensus:**
    *   Chair Leaf expressed concern that the IETF is not a venue for "rubber stamping" existing solutions, regardless of their current deployment status.
    *   Emphasis was placed on the need for broader participation and demonstrated consensus from a diverse range of stakeholders beyond the existing implementers (e.g., car manufacturers, hotel chains, other new actors).
    *   It was clarified that IETF consensus requires active review, comments, and expressions of support/concern on the mailing list from a wide array of participants, not just internal reviews or liaison relationships.
    *   The current level of participation in the TIGRESS WG was deemed "anemic," primarily involving contributors from Apple, Google, and Eric (as an individual contributor).
    *   The chairs indicated that without broader engagement, the Area Directors would likely not approve publication, and the working group faces potential closure.

## Decisions and Action Items

*   **No decision** was made regarding the adoption of either `draft-vinura-tigress-relay-server` or `draft-rola-tigress-relay-server`.
*   **Action Item for Chairs:** Discuss the path forward for the TIGRESS Working Group with the IETF Area Directors.
*   **Action Item for current contributors (especially from Apple):** Actively recruit representatives from other verticals and interested companies to join the TIGRESS mailing list, provide feedback, and review drafts to build broader IETF consensus.

## Next Steps

*   The chairs will communicate the outcome of discussions with the Area Directors and propose next steps for the TIGRESS WG on the mailing list.
*   The working group requires significantly increased and diverse participation to demonstrate IETF consensus. Without this, potential outcomes include:
    *   A joint working group redesign of the protocol.
    *   Continuation with `draft-vinura-tigress-relay-server`, but only if substantial additional participation is secured.
    *   Closure and disbandment of the working group.
    *   Alternatively, `draft-vinura-tigress-relay-server` could be pursued as an individual submission for an informational RFC.