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

Raphael Robert <> Tue, 18 August 2020 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A59EA3A0BA0 for <>; Tue, 18 Aug 2020 07:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ZmvsqnQn4QX for <>; Tue, 18 Aug 2020 07:55:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EF1F3A0B9B for <>; Tue, 18 Aug 2020 07:55:38 -0700 (PDT)
Received: by with SMTP id r4so18529795wrx.9 for <>; Tue, 18 Aug 2020 07:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nj5gi+Ht8oxksNM9XM8ocuIRPbYMK6u95I59PegSE9E=; b=vM6863SeakfZowX2FOWoVbdMnyZFMIe+CY3vSDsqArI5YvSim7aWlCRyaH/5G2hCE5 b1Yv+LdWhSQetWEVSrZLYnKQ+pDD/tilMoi54SyAy4IPaMLhqE3kGHMy/7OcAFG/jXKk yejVeEVBtKzcDpXH8l7PzwnfPFu1N6p0VBMckBy5u++WDLoFKMXZBNVTcq1I5V3bygbh LI6mO4RadTzLKcum2s12oHCyNoxPu8XG/Bua6NKln2sDaYQSwRoa+a72bQ7sItIXxn1Y k/xAhRrHfmhBh3m1oVeUUNTzmI66L+KUvOuUVkbdi6ZANDSYk6n23tl/XrOzrcPlH0H+ dxVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nj5gi+Ht8oxksNM9XM8ocuIRPbYMK6u95I59PegSE9E=; b=KnvXF9lR43lBtJ14jC6/wY5wLkN48ZzcN9cH5JYjju22BQmTgz3iQUmA1BJjJey1SM hHuUoLE7oiSDb5vykPHkpAuu1eNv6+8hkr4CkOccPD9Dr+dgnDWWsayfC6BHpD6ywNKJ ACqgjvRet3ihIlauN5p7rhTiNQXJNBo7+ABcxEhRLsDCE/KhbgCNDyG3uNHeljPgQLHH MPP+XYcjwRM4x4TOy4LkpngG2XhvDqBu28ZeGwyVWaRvMUwCYeL8bWmfitar6PEH9eqq dQUbDEbMzHNSaaLuvU1NYmMlYVIIiU99zKQ8rrSykVCsC6Ak1YI6j0oLJMMu6aetsTea 2I9w==
X-Gm-Message-State: AOAM5314sLdEvNB/5tFtG/LNlycCYBDbo5iphMcaWet8bABzaP9RLc3w uVaEtfHWT/99jtzaFjk18YEt7Q==
X-Google-Smtp-Source: ABdhPJxMluANW6uT5bmyA0T65+yG4It4gO95vbmWw+C2oozJ2xAh4aEw+PBiS4t+aVZ4pQwfdfACtA==
X-Received: by 2002:a5d:526d:: with SMTP id l13mr19553282wrc.279.1597762536592; Tue, 18 Aug 2020 07:55:36 -0700 (PDT)
Received: from ([]) by with ESMTPSA id t14sm37951357wrg.38.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 07:55:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Raphael Robert <>
In-Reply-To: <>
Date: Tue, 18 Aug 2020 16:55:34 +0200
Cc: Messaging Layer Security WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Joel Alwen <>
X-Mailer: Apple Mail (2.3608.
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 14:55:41 -0000

Hi Joel,

For context: this would only apply when applications use cleartext MLSPlaintext for HS messages. The recommendation is still to encrypt them and send them around as MLSCiphertext.
That being said, we said we would like to support scenarios where HS messages are not necessarily encrypted.

Question: would this attack work with Commit messages? I’m thinking that they would be rejected because the attacker cannot compute the confirmation_tag.

As you mention in the PS, the easy target would be Proposal messages.

I’d be interested to see what exactly you would propose as a mitigation mechanism.


> On 18 Aug 2020, at 16:36, 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