Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

Joel Alwen <jalwen@wickr.com> Tue, 18 August 2020 18:26 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 D55573A0966 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 11:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_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=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 5M1_a3whxv_0 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 11:26:03 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0: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 BBAC83A095E for <mls@ietf.org>; Tue, 18 Aug 2020 11:26:03 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id y206so10357002pfb.10 for <mls@ietf.org>; Tue, 18 Aug 2020 11:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=31RQ+lrlOpPLSPmWmjwymUUGTO85xDB9pc/NHxvzAZw=; b=UPMGbx/pMnp+6+cQ0YlxdUPxJX0PcaqdngnMROl7BhVsMvuCdPuOudlZZehO8tgKs1 P+4LnZl5eH+DIrvuoQPs6mKjyikwRHjLSbusSxJd1XX+W/SP3bLnDStwXUD4gTYUckgJ 3aDQWqMyFhyQJKKo3ETPYCeGWC0tSVTYTkTcjhcEOoBsMB6DiNKSLbxSaKtrYVqXLqYh BnS/VQ0C9aHnDchkpLIFEizrzx0b1xYTugRE3wAccUzXI/5omb1JFMjZDIhesRJGZV8q yVn9geXJp6tiVSLLgllZ9V36FeQb8j9cZVmi8GQMlIlobhqAcL+xgDy821Kekf4gRncd GXIw==
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=31RQ+lrlOpPLSPmWmjwymUUGTO85xDB9pc/NHxvzAZw=; b=rJpkg35BgNEqgXCNH/QKK80dzEHlOfXKaBy3KUO1t1OhQWVw+ZBJE455MFD1e0ayg8 M3N/gYnOnpx3vw1QQcthwS/HefuLybp37ycaBxrrz9Ere1fxlN95FssNmA4/BOXW2qG2 xzGBgEHVlEfErVqMepwRxd0WZC0roawYp4qMM1tqFuVRnyLMZnsJiS0GPL6AquoN2XPs JiZKFmtXVCJAY09g6rzeHTANGLj3c1bGdd1aG1eFQtshTvskTeKqFqJo5XvfN5LQZsSy YQusczoaZxzprQz189aHgH2C8pb8AuM77BPRy72zSNz0Jqd7WM07X8wWmb5jsI8FpG2e NV+g==
X-Gm-Message-State: AOAM530vhfktrT3aKWWdw+5ewcROL1/+oPozxTO5/+iFqADdOdHXBLZt ug/lgrn0jIDGDjjJj6KnOnG3O0aGB360yd8CY4iaXg==
X-Google-Smtp-Source: ABdhPJz2BMIDUut9E5Z7yNgl/PFxQk27QQmlFJKSgt4Bz8AVXmD88/BcvE2vpDswmFMl8Hz78kZCLYyDj6S2hNmT8KU=
X-Received: by 2002:aa7:9ec4:: with SMTP id r4mr16665811pfq.48.1597775163020; Tue, 18 Aug 2020 11:26:03 -0700 (PDT)
MIME-Version: 1.0
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <CABP-pSSBcf_BUXPp=uxWMpBviBday8-utGzo=ksPG4Ei=_x3ag@mail.gmail.com> <7abf555f-a266-f62f-2a22-8b0f389304d5@wickr.com> <CABP-pSSzZnqaB95RreekLJ2Fx_HZP4X4CuL0RU6_wRqNEVO+3w@mail.gmail.com>
In-Reply-To: <CABP-pSSzZnqaB95RreekLJ2Fx_HZP4X4CuL0RU6_wRqNEVO+3w@mail.gmail.com>
From: Joel Alwen <jalwen@wickr.com>
Date: Tue, 18 Aug 2020 20:25:53 +0200
Message-ID: <CANYP602_ixw_tCg9iBswd6PP6fn=-ndt7=U3w+k9ArVP8MU+Kg@mail.gmail.com>
To: Brendan McMillion <brendan@cloudflare.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005f37005ad2b05fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/pMUjgOYhTjECpRqd_1t-Fjbguck>
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule
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, 18 Aug 2020 18:26:08 -0000

Chaining key pairs builds a PCS sig scheme from a standard one. (No FS
needed.)

PCS sigs could be helpful as a complementary mechanism for getting yet more
PCS auth. If so it seems worth it to think if we cant get a more efficient
construction of PCS sigs.

Regardless, proving to receivers that the author of a message knows the
current group key schedule still seems prudent to me.

- Joël.

On Tue, 18 Aug 2020, 19:37 Brendan McMillion, <brendan@cloudflare.com>
wrote:

> I actually describe in the thread I linked how to take a standard FS
> signature and turn it into a PCS signature. While it's baked into the
> primitive, essentially what's happening is that every time Alice sends an
> Update, she generates a new signing key and certifies it with her old
> signing key before discarding the old signing key. So if Alice's Update is
> accepted by the group, anyone who compromised the old signing key can't
> sign new messages because they don't have the private key of the *new*
> signing key.
>
> On Tue, Aug 18, 2020 at 9:55 AM Joel Alwen <jalwen@wickr.com> wrote:
>
>> > My objection to this is that Alice can still be impersonated by members
>> in the group, if we only have symmetric forward-secure authentication.
>>
>> I'm missing how FS sigs (or any other FS auth primitive) helps. My
>> understanding
>> is FS auth primitives prevent leaked keys from being used to authenticate
>> messages in *past* time periods. But the attack involves signing messages
>> for
>> time periods (epochs) after the leak occurred not before the leak.
>> Imagine we
>> could deterministically ratchet sig key pairs forward much like we can
>> MAC keys.
>> We'd have an FS sig scheme but I dont see how this fixes the problem.
>>
>> Which is not to say that FS sigs dont solve an auth problem for MLS. Just,
>> AFAIK, not this one. (Rather they help prevent forgeries in bygone
>> epochs.)
>>
>> What I do agree with is that other group members (that know Alice's sig
>> key) can
>> still impersonate her in future epochs till she updates the key. The same
>> is
>> true when sending MLSCiphertexts.
>>
>> Unfortunately, for epochs between when Alice's state is leaked and when
>> Alice
>> finally updates her (authentication specific) asymmetric key material I
>> see no
>> way around this. It seems inherent to the adversarial model since other
>> group
>> member know and can do everything Alice can during those epochs.
>>
>> One thing we could look at are PCS signatures. Something like the
>> Updateable PKE
>> scheme in the RTreeKEM work. Namely every time you sign you also
>> re-randomize
>> your signing key (or simply sample new ones). That way leaking your old
>> key
>> doesnt let me sign under your re-randomized new key just like in UPKE
>> leaking
>> your old decryption key doesnt let me read ciphertexts encrypted to your
>> re-randomized new key. Make sense?
>>
>>
>> - Joël
>>
>>
>> On 18/08/2020 18:34, Brendan McMillion wrote:
>> >     So to that end, how
>> >     about we modify MLS such that MLSPlaintext packets coming from
>> group members
>> >     must also be authenticated using something from the application key
>> schedule.
>> >
>> >
>> > My objection to this is that Alice can still be impersonated by members
>> in the
>> > group, if we only have symmetric forward-secure authentication.
>> >
>> > There's been some discussion in the past about using forward-secure
>> signatures
>> > that might be worth looking into instead, which would fully address
>> this attack
>> > vector:
>> https://mailarchive.ietf.org/arch/msg/mls/o3fmIul_4s6STmnqmz514cjADpw/
>> >
>> >
>> > On Tue, Aug 18, 2020 at 7:36 AM Joel Alwen <jalwen@wickr.com
>> > <mailto:jalwen@wickr.com>> wrote:
>> >
>> >     Hey everyone,
>> >
>> >     Something thats been bugging Marta Mularczyk and Daniel Jost and me
>> for a bit
>> >     now is that handshake messages sent out as MLSPlaintext packets are
>> only
>> >     authenticated using signatures, but not using the group's key
>> schedule. For
>> >     non-members that makes sense but for group members that's weaker
>> than need be.
>> >
>> >     Suppose Alice is in a group using signing key pair (spk, ssk). I
>> corrupt her to
>> >     learn ssk. Now I loose access to her device again. Later she
>> generates a fresh
>> >     key package with her same spk but a new HPKE key for her leaf. She
>> sends out and
>> >     update proposal for her new key package and someone commits to the
>> update.
>> >
>> >     Expected result: she (and the group at large) has achieved PCS
>> again.
>> >
>> >     Actual result: using her stolen ssk I can still forge a new
>> proposal's (sent as
>> >     MLSPlaintext packets) coming from Alice. Some things I could do
>> with this power:
>> >      - I can generate a new key package kp for Alice using her spk and
>> some HPKE key
>> >     she doesn't know. Then I forge an update proposal for Alice with
>> kp. If it gets
>> >     committed I've effectively kicked her out of the group.
>> >      - I could forge Add's and Remove's coming from Alice, so I could
>> trick the
>> >     group into thinking Alice is trying to Add my account to the group
>> or remove
>> >     some other group member.
>> >
>> >     Lemme know if I've missed something here in that scenario...
>> >
>> >
>> >     If I didn't miss anything and the attacks really work as advertised
>> then IMO
>> >     this is kinda weak sauce and worth avoiding if possible. So to that
>> end, how
>> >     about we modify MLS such that MLSPlaintext packets coming from
>> group members
>> >     must also be authenticated using something from the application key
>> schedule.
>> >     Now the above attacks fail. As soon as Alice's update is gets
>> committed I no
>> >     longer know the group's key schedule and so can't forged packet
>> from Alice. More
>> >     generally, this brings the PCS guarantees when using MLSPlaintexts
>> frameing in
>> >     line with what we're getting from MLSCiphertext packets.
>> >
>> >     Any thoughts?
>> >
>> >     - Joël
>> >
>> >
>> >
>> >     PS. For concreteness, we could probably extend the current
>> mechanism for getting
>> >     concistancy (the confirmation_tag) to also provide symmetric key
>> authentication.
>> >     E.g. include most of the MLSPlaintext content into whats being
>> tagged by
>> >     confirmation_tag. That would cover the case of a commit packet and
>> doesn't even
>> >     grow the size of MLSPlaintext packets over the current design.
>> >
>> >     For a proposal packet we could also have a confirmation_tag but
>> this one is
>> >     computed using the *current* epoch's confirmation_key and
>> >     confirmed_transcript_hash.
>> >
>> >     _______________________________________________
>> >     MLS mailing list
>> >     MLS@ietf.org <mailto:MLS@ietf.org>
>> >     https://www.ietf.org/mailman/listinfo/mls
>> >
>>
>