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

Brendan McMillion <> Tue, 18 August 2020 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC5943A0EAC for <>; Tue, 18 Aug 2020 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSUmIN1LtYsz for <>; Tue, 18 Aug 2020 09:34:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74DA83A0F2E for <>; Tue, 18 Aug 2020 09:34:53 -0700 (PDT)
Received: by with SMTP id e5so15568424qth.5 for <>; Tue, 18 Aug 2020 09:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cWOE9XzEZMCYeqS37aXBMiH/VA3kMr54zVletvoFxLE=; b=ylA4j8QhEVOoeUnOcrj6Sous/jPj7YUHhxod+GKT2NmIlkaM50wRPz7q0L525rUGqn +1twNnlOO3CcvhHf+5c7qtqGs85czyM554HjclPPyW19WDiG7PcO7ee+an+S32h76Qx2 9pjYWcbUqDUVjTVSWP0KpXlSQn2vzdnc9azFw=
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=cWOE9XzEZMCYeqS37aXBMiH/VA3kMr54zVletvoFxLE=; b=A4jE/dynburXLg0FlEH45epWDRnz3EOofRP7ss8NcHxnrjWK+UpVZFlihGOQhDGYMK B6EHMEmrywcrFtrVEWbrf+/+NWbc91oJ8Qw/L7sy50qkWi14/dpt+CZPjESbnGHIaURK 0x7hM9Cg1+LlSyr9M3Nd82PG+cpFfUFuIndgniozjNlCDSXPBKHJ7omZgtwXp7GXZ4Um cQax8CrAiHdlGrG5xIrvhRP4WoiyRExDeSvZ5KjSdHE/BnJ/sxOpvDSTCOVy/Avv6b0I DY//rwQtXAlXV72Jama6MoafUA78EK/oWd2merSHYVSWpt3Vcp0mrzOW2EKfgWeXa57H +DMw==
X-Gm-Message-State: AOAM5302mnQ+zNDidfqpZiVL/OraADhiemrbpt0cLX3Ya6HlPLx7dSOQ N2n9m2j/A1OLqpQg1b1zpg2EoJh0YgBTBTcN1kYpxQ==
X-Google-Smtp-Source: ABdhPJwDC2NbaGWgNcaUkebFMssY5UyHDJnsBoSHDogj9E18jKYbbqnhznKmZNXFX6YyC+nY02nSPXq08nd9v6T0e1Y=
X-Received: by 2002:aed:27d5:: with SMTP id m21mr19264377qtg.4.1597768492263; Tue, 18 Aug 2020 09:34:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brendan McMillion <>
Date: Tue, 18 Aug 2020 09:34:41 -0700
Message-ID: <>
To: Joel Alwen <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="0000000000006a547d05ad2977ed"
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 16:34:57 -0000

> 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
> 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