Re: [MLS] All commits = external commit?

Raphael Robert <raphael@wire.com> Tue, 06 October 2020 16:55 UTC

Return-Path: <raphael@wire.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BBE3A0D84 for <mls@ietfa.amsl.com>; Tue, 6 Oct 2020 09:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxsKYM3Yw7Ja for <mls@ietfa.amsl.com>; Tue, 6 Oct 2020 09:55:44 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4C4113A0D81 for <mls@ietf.org>; Tue, 6 Oct 2020 09:55:44 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id t9so5647566wrq.11 for <mls@ietf.org>; Tue, 06 Oct 2020 09:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kyhOq/s8b3n/O0IfOdMxGz0Dc5trRWk7FDjsL2qRDIw=; b=Vc2xjmg6fydf5Pfb631gffJae7jsGYAMNHXEeQrNAB+4aVnIdYUiXHrPzDJyj2F10+ ztXyh8j0PXEbjsVt/rDbpxFEBf9oDu1PR/YYeEemalEWIsnEdoQRsEh4qRRkiCfSu4up FFrnywxw/KlPxReJLOTZRscaTRLJ3kbV5zGd4CTaJp93ESEZWW5/aQCnWL7dsbwk6+ZE 1umrC2H6oycQkKSWs8+x4OLmnSU6Dp5DPC60HtzzzVarRMEhj0A41s2VBHuRFmKTRe1e 8s/1YU2c0wulTiJTm3vaKrLPjmdfMTG/rRxJf1eLbIO+o4Xgt3jiq1utQmKjgAQJZJu1 cTLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kyhOq/s8b3n/O0IfOdMxGz0Dc5trRWk7FDjsL2qRDIw=; b=jbHPqwuWZEN3UKMLFhVRE5vGT4/Ju7mMtDnyB5K5ryWy+vRab0OqbEK312ychMSQvc 78l/g7kRC3JoCM5x5HQdhff8Mcf914DajV7zJyQ7UKDfCm/ePum3E8POUndHMGiRwELY RitTKhgBiNefoxb6YcIlYq87QdMBWYG/Bbg+Pl8lBv+jr8Q3OKIOGspNUwU+3iRIkJ4/ GwB85UAozbDiFqgQcNWq1Ga4jSFgKSu5QFc6dQeqhdOF17d2WypQ8aJy6rduYlZlVAmy Zz73c1EACzhiK5Z/JYR5BXPAd7m3wQO9zCc7Y0p5JZQqbvWYfxzdfmu9V/CpD5imYDpy bMBA==
X-Gm-Message-State: AOAM530ldxWwD+OKKScw7bR7KoXXA6NdEFWWIfZTEv808gG1jldFE6YR JYqWBu7gBDuhpu/8H02CchpSk08WK5T6XA==
X-Google-Smtp-Source: ABdhPJzZZEcjc3HTKMGBZkohdAvnYnMLxB9s3slLxD2byW4sp226KsALO4ZOllshL0o35f2T75d5HA==
X-Received: by 2002:a5d:6886:: with SMTP id h6mr6285303wru.374.1602003342406; Tue, 06 Oct 2020 09:55:42 -0700 (PDT)
Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id u15sm4586603wml.21.2020.10.06.09.55.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 09:55:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Raphael Robert <raphael@wire.com>
In-Reply-To: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com>
Date: Tue, 6 Oct 2020 18:55:40 +0200
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com>
References: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com>
To: Joel Alwen <jalwen@wickr.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Mxm48mOI3-awDq0Il9zUgg5UOwg>
Subject: Re: [MLS] All commits = external commit?
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: Tue, 06 Oct 2020 16:55:46 -0000

I second that assessment, my idea behind External Commits was to offer a mechanism where internal Commits couldn’t be used. External Commits should remain optional (this can easily be achieved by not providing the ExternalCommitInfo package to new members) and when they are used they should be used as a last resort mechanism (meaning there really is no way to add a member with an internal Commit).

I also think MLS should should remain in the position to cover most scenarios from mainstream consumer messaging to messaging in high security environments. External Commits make the former much more accessible but shouldn’t jeopardise the latter.

Raphael

> On 6 Oct 2020, at 18:38, Joel Alwen <jalwen@wickr.com> wrote:
> 
> Hey people,
> 
> To follow up on the discussion at the end of the Interim about whether to use
> the new "asymmetric external commit" (AEC) mechanism for internal commits I
> wanted to summarize my thoughts here. For brevity let SIC be our current
> "symmetric internal commit" mechanism.
> 
> - AEC requires extra asymmetric crypto operations (both for committer and
> receiver) compared to SIC which I think we should avoid if we can, even at the
> cost of some code complexity.
> 
> - AEC doesn't ensure the committer knows the old epoch's key schedule. This can
> play a deciding role in several types of attacks.
> 
> Consider this execution:
> 
> 1. Alice is in a group. Her state leaks (including her signining key).
> 2. Alice commits (to arbitrary propal).
> 
> At this point, the adversary can still forge a new AEC from Alice but not an SIC.
> 
> Worse, step 2 could have instead been "Alice sends an update proposal replacing
> her leaf HPKE but keeping the her sig keys (e.g. because new credentials are
> costly to come by). Someone commits to the new proposal." At this point I'd
> expect PCS to have kicked in for Alice (as it does when using SIC). But not for
> AECs since Alice's signing key is all thats needed to forge a new AEC.
> 
> I think it is not worth weakening security this way if we dont have to.
> (Especially, since in some deployments external commits may not be a supported
> feature at all.)
> 
> - As for what may or may not be displaid to users, that's really up to the
> implementation. IMO our goal should be to make the protocol as secure as we can
> subject to reasonable costs. Which aspects of the resulting security properties
> are ultimately communicated to users should, in principle, be left up to
> implementations. That means we shouldn't be designing away security features
> only because we think they might be hard to communicate. (Nor does it seem that
> inconceivable to me that some implementation may end up explicitly signaling
> whether a commit was external vs internal.)
> 
> - Joël
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls