Subject: [saag] MLS@IETF104

From: Sean Turner <[email-masked]>
Date: Thu, 28 Mar 2019 13:30:37 +0100

MLS met on Tuesday and Thursday.  Both active WG drafts, the architecture and protocol, were discussed along with a potential new WG draft that supports federations and the status of security analysis.

draft-ietf-mls-architecture - Benjamin Beurdouche (Inria) provided a summary of revisions since the last meeting.  As the plan is to essentially move this draft substantially toward completion the WG will focus on the open issues (concurrency of group operations, metadata retention, ephemeral signature, and deniability) and the editorial (more precise security guarantees, privacy recommendations for Application metadata, and federated-related additions).  gh repo can be found here: https://github.com/mlswg/mls-architecture

draft-ietf-mls-protocol - Richard Barnes (CIsco) and Raphael Robert (Wire) provided a summary of changes from version -04 and reviewed a number of open issues and PR related to simplifying the key schedule, decoupling identifiers, server initiated removes, and using a common framing, Work continues … the gh repo can be found here: https://github.com/mlswg/mls-protocol

draft-omara-mls-federation - Emad Omara's (Google) individual draft intends to standardize the minimum information needed to allow different MLS clients to encrypt/decrypt messages to each other.  Use cases include different clients and a single, shared delivery service as well different clients and different delivery services.  Much of the discussion centered on whether the entire roster who be shared and.  In the end, there was no objection to working on federation and the WG call for adoption will begin on the list shortly after IETF 104.

Deniability - Sofia Celi (Centro de Autonomia Digital) presented an overview of deniability including it’s security properties, previous work, and limitations as deniability applies in the group messaging.  There were no objections to the WG considering this as a feature for MLS. While there were no objections to exploring deniability properties for MLS, there were preferences expressed for making deniability an optional feature in order to support enterprise environments where deniability is not a desired featured.

Formal security analysis - Karthikeyan Bhargavan (Inria) explained that the MLS protocol is not so simple any more with multiple drafts and features (key exchange, Sender/Message/Key Authentication, and message protection).  However, there are multiple symbolic analyses and cryptographic definition proofs as well as one verified implementation; there are security definitions and proofs for core key exchange.  However, the drafts are changing at a great rate making analysis harder.  He proposed a more TLS-like process proposal where certain drafts are called “stable” for review and changes include rationale for change including security performance goals (and why what was there previously does not work).  The WG felt that this was a fair request and will investigate adopting such the proposals to make security analysis for future versions easier.

Cheers,

Nick and Sean