Sean Turner <sean@sn3rd.com> Thu, 28 March 2019 12:30 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D75271203ED for <mls@ietfa.amsl.com>; Thu, 28 Mar 2019 05:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FXT1ddCHWUl0 for <mls@ietfa.amsl.com>; Thu, 28 Mar 2019 05:30:42 -0700 (PDT)
Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD951204AD for <mls@ietf.org>; Thu, 28 Mar 2019 05:30:42 -0700 (PDT)
Received: by mail-yw1-xc2a.google.com with SMTP id w66so2632840ywd.4 for <mls@ietf.org>; Thu, 28 Mar 2019 05:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=rFtfegI/fsQzq29UYDXRLj+sNESsW/BdlNoLM0CU8uE=; b=mRQKcFfPt9/fXvOpMCCd+NakwfcNZlyET+7dv0Q5/a/z3oZzS0EmKiH3VDoJCx1ztj ZVXsWMuYcgncqR3P+lx7OOa1b4Yg83/8IhX1/ERerXGtzuARIszUg1hI8/MWwp79pdeZ 1qKfHzoZe2AlTc+Z2bWhrnOEoWbNDPTdeE+50=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=rFtfegI/fsQzq29UYDXRLj+sNESsW/BdlNoLM0CU8uE=; b=jAOxub5dBa2EgzEhSiFdoehbFYBkJHjyURtbvshT0sI68BA5P1kMtnOZo9dQZQH29a JLP6/GIS3TXiBQkDoCkHIsKnrTPr5itJdFuuLT7s2/4doYphP8bkvvvtkBFSmsM49+io wOkNwKvxXWuUYynmunNHDOlXrQWSnpmRrtgR9rldx7o2PQx3XjsEVrV8BkrfPr1a39eC ITGNJHS794NXD+vXrDIWAcsJe4DtMtn0ZmcEzs7CKaFL1vR6YIlUPhe2i1zt46wdZhHi vcDqdFJ8DJQG/bPE5byPcTJypP9fvCnt1Z7wc+4tP7I1LqT15MicZl2tSI6EmKRS681X pleA==
X-Gm-Message-State: APjAAAUUkx+v5deDZtZbMPY//uKx3vPkRtJ5k3BmZ5HQ9TeLNyrdNDTT mkcu8YdvWi16MvXG/nisptGvwQ==
X-Google-Smtp-Source: APXvYqxXRsIojskurQ27BnMCv1m7RzbXOngWApVt1VzGMOI/m2lwo1gRi5MVQieRd04/O72onxZ6qA==
X-Received: by 2002:a25:9945:: with SMTP id n5mr34078208ybo.453.1553776241522; Thu, 28 Mar 2019 05:30:41 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:c1ec:6bbe:60d6:361d? ([2001:67c:370:128:c1ec:6bbe:60d6:361d]) by smtp.gmail.com with ESMTPSA id l82sm7460569ywl.6.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 05:30:40 -0700 (PDT)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <C2875CEC-D24E-4AFF-8381-911178B49772@sn3rd.com>
Date: Thu, 28 Mar 2019 13:30:37 +0100
Cc: mls@ietf.org
To: saag@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/nJ4jbIkVh10FfiuEfkEF5dDBauA>
Subject: [MLS] MLS@IETF104
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 12:30:48 -0000

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.


Nick and Sean