Re: [MLS] All commits = external commit?

Joel Alwen <jalwen@wickr.com> Tue, 13 October 2020 14:58 UTC

Return-Path: <jalwen@wickr.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 61EC63A08A9 for <mls@ietfa.amsl.com>; Tue, 13 Oct 2020 07:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 alPW2XeUAY0t for <mls@ietfa.amsl.com>; Tue, 13 Oct 2020 07:58:44 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 795173A08B2 for <mls@ietf.org>; Tue, 13 Oct 2020 07:58:44 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id n18so24453219wrs.5 for <mls@ietf.org>; Tue, 13 Oct 2020 07:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jAqxinmBjWNpujAuZS4vPzct/I4OhVyR1czb3NgRFGY=; b=KRQ94X9wl8toYOg/jciIme9D+ro+pZ6FhKfbACRmbfL1m5jv4LRR3Ql1VZMCJGaGRr GuLwMnv8oR2HcYd4lAl6CiUNJwv1AFlIrQOBM+HkDbn5VDHntANlJYtDmWFvCTYHE67x 0y0edpR1xxFdnXdxsAiv2KAUIArPQSnRPdaKY+zZQF4rylsRuquNv0vbWeeNcGksNHvO KNYMeZ/6t/YQicmOJdMTtM8kZ9E1AB+4tLnTS3r56Mi1POgx6Co9+3pWiezEWPzxlvwD OuBlUwrymXiZLPysitQvuO748THM/ASV4ZrQ257O4XlGk/9NbFRocgyERFmGn1vBkkJj iCbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jAqxinmBjWNpujAuZS4vPzct/I4OhVyR1czb3NgRFGY=; b=UMQPL+F2io29ZUdsF6Cb5nqv3Vle+JQyNqbdev3jo6GoR9rxxx/ciKYp2zVTY5wwZa 8DcVpiOTkWp0gNf5u9kmRrQ5DtyV0ou5xGbXguAF4eIChQWMosA9Qe6zvm+4SMGkJdSV Bg3SxG1G/UAaymD9vgMozdwZ4s1L1IqUX8BYuW+sW5vduPkLMLJowNx2J0GybWa2fbkq KoR6sy6L/7Fo50B2JQ8IAYQ/utPCp6O3AltApU7vALZ31Rp22HEMfw/xkU07WaZY5Mva ABRBdVZUlpYh5CFSBnyRrsR9R6JrwFI83Aiks1EN0eGDOObVeRnsJNJI/eHvTkZK2q/H 0Qkg==
X-Gm-Message-State: AOAM530oKrX9Zf6esqrUVz2deDZq/7OYN0Zx4dy1XIC1UYyKrT6PkWhm TZlPAGdqubXknhqe90Kan8F2xnLcqZx+hWiy
X-Google-Smtp-Source: ABdhPJydacxC81xPgQVQSxEtVpLF+PfwXScybqqVEH0e4Jm9D//zL73RZ4bHi4vFP35OU/0SD8JQbQ==
X-Received: by 2002:a05:6000:118c:: with SMTP id g12mr46762wrx.246.1602601122353; Tue, 13 Oct 2020 07:58:42 -0700 (PDT)
Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id p13sm27755wmb.5.2020.10.13.07.58.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 07:58:41 -0700 (PDT)
To: Richard Barnes <rlb@ipv.sx>, Brendan McMillion <brendan@cloudflare.com>
Cc: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, Messaging Layer Security WG <mls@ietf.org>
References: <ceb4e95a-09b7-c4cb-cd8f-50641b605fbf@wickr.com> <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> <CAL02cgRKF4pfsovTUYRJAO7Of8sDYWEFNjzMdkPq8b0-t_feuw@mail.gmail.com> <CABP-pSSM14WsC-zX41o9Yp76ne_8B1diSfoRjNs2RFbvwV6QCA@mail.gmail.com> <CAL02cgRKMx3WPvj-urR_saQy41Z+x=8-mjx=1Qug06BhK+u8Bw@mail.gmail.com>
From: Joel Alwen <jalwen@wickr.com>
Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw==
Message-ID: <4ebdc134-59f5-8331-e9c8-ac3c9f343320@wickr.com>
Date: Tue, 13 Oct 2020 16:58:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CAL02cgRKMx3WPvj-urR_saQy41Z+x=8-mjx=1Qug06BhK+u8Bw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/FUDpqWsi9bSBq1TfX_jmmLyaPms>
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, 13 Oct 2020 14:58:48 -0000

On 08/10/2020 02:25, Brendan McMillion wrote:
> Unfortunately the attack outlined above doesn't work

So, the attacks I describe do work for the construction I had outlined at the
start of this thread. So maybe you are (implicitly) thinking about a different
construction?

Put simply, AEC is explicitly designed to allow a non-group member to produce a
valid commit. I.e. given a signing key certified to Alice and the public group
state one can always produce a valid AEC commit from Alice to the group. (This
includes any and all AEAD keys, MACs, etc. needed for the commit packet.
Otherwise AEC wouldn't full-fill its stated purpose.)

Ergo if we use AEC for internal commits too then, to commit on behalf of Alice
(who is already in the group), all I need again is her signing key and the
public group state all of which is available to the adv in the attacks outlined
at the start of the thread.

So trying to read between the lines, my guess is that you are actually thinking
of a hybrid between AEC+SIC for internal commits? Basically, the init_secret is
derived as in AEC (by KEMing to the group) but the current key schedule is also
used to derive a secret used for authenticating group membership of the commitor
(e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for MACing the
MLSPlaintext).

If that's the case, we're back to authenticating group membership for internal
commits which is an absoluately crucial property IMO. But we're also back to not
having full code reuse between external vs. internal commits. And we're
definitely paying a price: internal commits require otherwise needles asymmetric
crypto operations and commits take more bandwidth. Is their any point beyond a
bit (but not full) code reuse between int/ext commits?



On 12/10/2020 22:58, Richard Barnes wrote:
> Sorry that's not super concrete.  Maybe some of the folks doing proofs here
> have thoughts?

So pure AEC for internal commits is definitely much worse in terms of security.
We need internal commitors to prove they know the old epochs key schedule. This
plays a central role in the general security guarantees provided by MLS.

Moreover, when an internal commitor uses bad randomness the security we get from
AEC+SIC is strictly worse than what SIC gives us. Bad randomness ==> secrets
chosen by commitor during the commit are known to (or at least easier to guess)
by the adversary. In this case, for the new epoch_secret[n] to be secure we
can't rely on entropy coming from commit_secret. Instead, we need
init_secret[n-1] to have entropy. For SIC that can be the case (depending on
past corruptions of course) so we're (potentially) good. But for AEC+SIC we're
*always* screwed coz knowing the KEM secret chosen by the commitor lets you
compute init_secret[n-1].



IMO this is all a bit moot anyway. Some limited code reuse is just not worth
extra asymmetric crypto ops. & extra bandwidth. Even with identical security
guarantees I'd say its a bad idea to KEM init_secrets to the group.

- Joël

On 12/10/2020 22:58, Richard Barnes wrote:
> That's a fair point, Brendan.  The thing that still worries me, though, is that
> the KEM operation in an AEC effectively introduces a new independent variable --
> who is the sender for purposes of the KEM operation?  In the DHKEM case, who
> holds the private key corresponding to the ephemeral public key?
> 
> In the external-join case, you need this independent variable, so that the new
> joiner can join the key schedule.  In the internal-commit case, you don't need
> it, so it's purely a source of potential mischief.  It's possible that other
> mechanisms protect against such mischief, but (a) we would need more than
> mailing-list proofs that that was the case, and (b) we would need to somehow
> assure that future extensions to the protocol would interact badly with this
> mechanism.  It seems more conservative to not have the additional choice.
> 
> Sorry that's not super concrete.  Maybe some of the folks doing proofs here have
> thoughts?
> 
> --Richard
> 
> 
> On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion <brendan@cloudflare.com
> <mailto:brendan@cloudflare.com>> wrote:
> 
>     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
>     <mailto: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 <mailto: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
>             <mailto: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 <mailto:MLS@ietf.org>
>             > https://www.ietf.org/mailman/listinfo/mls
> 
>             _______________________________________________
>             MLS mailing list
>             MLS@ietf.org <mailto:MLS@ietf.org>
>             https://www.ietf.org/mailman/listinfo/mls
> 
>         _______________________________________________
>         MLS mailing list
>         MLS@ietf.org <mailto:MLS@ietf.org>
>         https://www.ietf.org/mailman/listinfo/mls
>