Re: [MLS] All commits = external commit?

Brendan McMillion <brendan@cloudflare.com> Thu, 08 October 2020 00:24 UTC

Return-Path: <brendan@cloudflare.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 CDD743A0BD7 for <mls@ietfa.amsl.com>; Wed, 7 Oct 2020 17:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=cloudflare.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 X_AnmKFZjegs for <mls@ietfa.amsl.com>; Wed, 7 Oct 2020 17:24:52 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 B39DC3A0AB5 for <mls@ietf.org>; Wed, 7 Oct 2020 17:24:52 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id c62so5227265qke.1 for <mls@ietf.org>; Wed, 07 Oct 2020 17:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DnXHizpvnFr8liglDlzYm5vyD0OtjPBKepXwNGcE1PE=; b=Mk0xLuHOoO7e76Ng/ojUuLlbsAXCJ4CQK22dOGtea76ecF5+QY3QDrkugwKbKhJRxv UQxwGuAdwxpC23GotaHp2hEwDcOqBRKM1105KLQzmrCeoNl3N1/I45GJW23zeqbdgdbj oNDSOJ0VCQXxbVpVp0QDuLZTrTQWHmvzmFts8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DnXHizpvnFr8liglDlzYm5vyD0OtjPBKepXwNGcE1PE=; b=hBe6NT7W9UDg/ClTW5mjfHPr/4kEVebR5NLrKokmsrG/M2bebhm9J2vjRyHi/rRJC9 mHxkNmseEkkb0olhHQMBXrv2s0PtSy0lAQe2ndFSV+P5tDFH0HIv0LwWrtRir3PVfM/B nxxOQaMknI9twwhu5sqEh/azQy1N5cueaX4rO9mwHJxVeG1UOWV0nPY+JBhn9dQ8Wwhz PwL4UUgDlYm2Zx5qErSdCwVgXCkhVirTY/K3VLYjqsKm6J8jzSv3591o+OcPHIHpyems ovJHGH1MYehEEjrPXQqjxAOhXrhLAZdFeSuAC9hxDV5S3sMTSm5uG3Uvz1bEXzLUoe/O 2Aqg==
X-Gm-Message-State: AOAM5318KxYjyuxpbjD2zvAl/8dRJ6jN3qo1imPA2HVvEVY6kwgsDY0j reOYyktW6Qnm/VsjgdAbXXBDx23Z7ZFe1V3xfJfYdw==
X-Google-Smtp-Source: ABdhPJxTGD13j0G6FBXbeu7fepZxliFP9UFMjK3sPbG1oErhIHlKX2cMTkMBJKxt3lD0BEbdziy323UyVjr0CExTwYI=
X-Received: by 2002:a37:6d4:: with SMTP id 203mr5514981qkg.150.1602116691711; Wed, 07 Oct 2020 17:24:51 -0700 (PDT)
MIME-Version: 1.0
References: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com> <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> <CAL02cgRKF4pfsovTUYRJAO7Of8sDYWEFNjzMdkPq8b0-t_feuw@mail.gmail.com>
In-Reply-To: <CAL02cgRKF4pfsovTUYRJAO7Of8sDYWEFNjzMdkPq8b0-t_feuw@mail.gmail.com>
From: Brendan McMillion <brendan@cloudflare.com>
Date: Wed, 7 Oct 2020 17:25:17 -0700
Message-ID: <CABP-pSSM14WsC-zX41o9Yp76ne_8B1diSfoRjNs2RFbvwV6QCA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, Messaging Layer Security WG <mls@ietf.org>, Joel Alwen <jalwen@wickr.com>
Content-Type: multipart/alternative; boundary="0000000000004c79cd05b11ddc4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/pijKBmYnEIGzc76W1nhS4NCTRjo>
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: Thu, 08 Oct 2020 00:24:55 -0000

Unfortunately the attack outlined above doesn't work because if an attacker
has Alice's state from a previous epoch and Alice has since Updated,
they're unable to encrypt MLSCiphertext or authenticate MLSPlaintext
messages. The attacker could use Alice's signing private key to send an Add
proposal and Commit, but they'd be marked as being from an external sender.
There's no distinction between Alice being in the group already or the
attacker adding Alice to groups she was never in to begin with -- this is a
risk inherent with allowing external joiners, not the asymmetric Commit
mechanism itself.

On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes <rlb@ipv.sx> wrote:

> Thanks for this analysis, Joël.  This aligns with my intuition as well,
> and seems like a good rationale for a hard prohibition on AEC /
> ExternalCommit from group members.  (Something about which I had waffled in
> a previous email.)
>
> Another way to think about this: PCS with regard to a member is about
> removing an old version of that member (as represented by an HPKE key and
> signing key).  AEC is designed to allow joins, which means that
> AEC-from-inside allows the old, compromised version of the member to
> rejoin, which kills PCS.
>
> --Richard
>
> On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert <raphael=
> 40wire.com@dmarc.ietf.org> wrote:
>
>> 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
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>