Re: [MLS] All commits = external commit?

Richard Barnes <rlb@ipv.sx> Wed, 07 October 2020 15:48 UTC

Return-Path: <rlb@ipv.sx>
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 409753A0AA1 for <mls@ietfa.amsl.com>; Wed, 7 Oct 2020 08:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.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 fmC17KyhUuzb for <mls@ietfa.amsl.com>; Wed, 7 Oct 2020 08:48:54 -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 60D7B3A0A82 for <mls@ietf.org>; Wed, 7 Oct 2020 08:48:54 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id w12so3287145qki.6 for <mls@ietf.org>; Wed, 07 Oct 2020 08:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PE8lzhZcountODNx2WZciJEuusfh8XVsaZqmxSugGbY=; b=HObAy1ReOOKfdl3wjlkoRInAelvjmh1Z9glWBhrixhbkmFNesWMpgTGUsFmwmq0hgP iBqOAndYzHv9YN1/3ftkUCmXyQetxOvZY5yCg8SWaf7z/vHTcWK25zyhwBGaY5iWIl5i gU3sQB0oLcLqquLCLtzeIxO2XwflQ8Jitg/epfGSz85U+Khoi01KBQ6WM7HNrcZ9s6Fd 6OBpthtbdfVGjd2SjwxoHbjYQm66wceGAEYnoewPUuhqUvycG9/zIg3IU2px+mmS2mwf NS4own5uCIR77CY/RNdRT6xPD0qNm9aE+bPhoTl8WMZNL/N8eQP0CA/zb/uFVNQ5GwwP cbFQ==
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=PE8lzhZcountODNx2WZciJEuusfh8XVsaZqmxSugGbY=; b=Vr1ECcKABjJSdEqyH/n/n6pHT8+lrg8c/UpRBkwHVwKegqj40Q1F2H6RqhRbX7OES/ x+5w9Sb92APoHEGf/SO3iPd0FRaI9kTACVKDeBCFugI7iz74HjNyitK98yxu1KG9sNbx 9JolkEDrbHyySX3twIpOW+r+OIRRqMPgRciPCD75PQTPJF62/Hcc9GoDAr8jRaCCi0Rm qe3JWbUWKLEKz9jbgReL7F7aQeadm6mZ5LmkKI/+iCXEQ8JH1bPeIc1wqYi3NaGQN93r EaejqrCwE393rwlcSQgPsXbMYdQqySdVRpZzOTe9pW7eUj8y+MNE6NY0Nf2rKVjbvmgZ l75w==
X-Gm-Message-State: AOAM532U8of18zJ45JDbnHm0w36s4SY3zHjaFXYLwnqqYdMQxt/NeiY8 Nc7ePtOfaTS7WSq89wgcv/xMKoxeMmqudsOAqIwUUA==
X-Google-Smtp-Source: ABdhPJwB7x86gHL9txi9nv/pOvX0rpePOYq/eN6zVlf2O4qwSvhe+nYriZfrCXGpEZKZ07yLOtowe2j//YdWVirtYE8=
X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr2245688qkk.490.1602085733162; Wed, 07 Oct 2020 08:48:53 -0700 (PDT)
MIME-Version: 1.0
References: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com> <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com>
In-Reply-To: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 7 Oct 2020 11:48:40 -0400
Message-ID: <CAL02cgRKF4pfsovTUYRJAO7Of8sDYWEFNjzMdkPq8b0-t_feuw@mail.gmail.com>
To: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>
Cc: Joel Alwen <jalwen@wickr.com>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000006722205b116a7d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/pb2q3rDLWeEJEWdO4lJhgImHSUA>
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: Wed, 07 Oct 2020 15:48:56 -0000

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
>