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

Richard Barnes <> Tue, 18 August 2020 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D97493A0A83 for <>; Tue, 18 Aug 2020 12:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tk7r3k_sEKOM for <>; Tue, 18 Aug 2020 12:21:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC6BB3A0A79 for <>; Tue, 18 Aug 2020 12:21:41 -0700 (PDT)
Received: by with SMTP id m7so19341354qki.12 for <>; Tue, 18 Aug 2020 12:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fe50VgcC9Dh4BlXx99VjCdwIoaLbJrpkCXOuN49Dh9g=; b=PD8yLJ7KNkY/+18f+V9Pkiar2VV0y9B2X3Y5RR3EUTtb+E0tCq3YVWdEqQ/60eB0Uu f+hn8yreVTU9O8YuBcp6rAZkw0DEJhPvHee/zJDdHHevC4C1i6WLrg76xtBBUbhyyzbT nbN4LANyZ9jh/qccZNjvBT/enedBfeFkX900hv6FAOM8HDfQFxgqDkKJp8EcftAbJB/k OgGt0H3xB3lKH7HitZC67bFWuDL7DMGJ892LL924dkCzZ8QeXULMf+8lpRq6PufciAOt AIswNW0/LvLxDLyOvP6hTqFX+dQ4ynDsHLLVWQIPcpjMwP077vIuHlFcTj5idUCCa/Um LWlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fe50VgcC9Dh4BlXx99VjCdwIoaLbJrpkCXOuN49Dh9g=; b=O/tnxjqqNbDZ6WOUdR9iWVdI3abbvQ9LEhUjO766ziiY97xh6qJ1RyiGfdJSmQHcKz ncY93coLq2UGAJ3VlFc6gcmP0FW1NwLaIiexrQ4yYAIgkgkOpz9RBYyBfs/hmWt4rQJ6 pufdWR45XTS6Qpa++EX0COU/IluCIPK5eEeQE8ofLWUsJvI5D+v+4WVhUaPtu6QWyR0u cImOggKrwMsREVorJ5cpl8aFCqqisvEyTcWL6VQ2HUjwWh/BVBHsXZJgcDEI2gd6V7/v 5HzwaXWKs4xWyQ0q1gMI0Jl1nuKLcfQIc65uD/Lw2M6oSm2mnX/zYX7Y1qiXqKZv780y 4BpA==
X-Gm-Message-State: AOAM5303f3/jj0MN7Sx+2Z98GyiHxYKRt2gPGs1Ml3QYkDsxAuILdGVe w2XrTuRtSKGKX7KuQqcYwRIijp8UXD59tlkLAMhUxqhLy5paRA==
X-Google-Smtp-Source: ABdhPJxOTU/R5lZodfuwS3UbbHaqeUO0j7jvgX1jjYY8HiXFt6CD4I6zlI4mZGysLvb5tGgy2YNooHAksmwoxtKWtkA=
X-Received: by 2002:a37:8287:: with SMTP id e129mr16611766qkd.132.1597778500634; Tue, 18 Aug 2020 12:21:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 18 Aug 2020 15:21:20 -0400
Message-ID: <>
To: Brendan McMillion <>
Cc: Joel Alwen <>, Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000f5e0a005ad2bcb06"
Archived-At: <>
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Aug 2020 19:21:45 -0000

Brendan: I think you might have the wrong premise in mind here.  The
proposal we have been discussing would authenticate *both* that Alice is
the sender of the message *and* that she's a member of the group.  So other
members of the group could only impersonate Alice if they had compromised
her signing key.

On Tue, Aug 18, 2020 at 12:35 PM Brendan McMillion <brendan=> 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:
> On Tue, Aug 18, 2020 at 7:36 AM Joel Alwen <> 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 mailing list