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

Raphael Robert <> Tue, 18 August 2020 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD3EF3A0F07 for <>; Tue, 18 Aug 2020 09:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SfrGfjhTFFcZ for <>; Tue, 18 Aug 2020 09:24:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B50303A0ECE for <>; Tue, 18 Aug 2020 09:24:41 -0700 (PDT)
Received: by with SMTP id a15so18822319wrh.10 for <>; Tue, 18 Aug 2020 09:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=H4h3tF12ZEfzFPQYMHCWJSsoJtIfIJv7oryRTFK6VaQ=; b=HTZvW3fHCLgVHQr6RPIkoZqaLgT8VXOEFNyhRKtToUfuBahrZH3VLPbKrpmYTDOuMI tQ36ky9Sbp/s4wMQKpqLtqxvEuxYrTyMtVEkz6kl5NsAxxC9Ee53731GkA38jGIqWO2B MLkhKssfgzhOsVvYHm6Lx3XgH4DkQ7YUj6swSsIfvQp3AykKFkJwERTNEBCnzFJu8Y1p c/2K/owHRIuKqWrEChfPoZXnlZq6bGpXf5hE5aaXVJwY1QKmGTuyhD1m7aidbmJmz/ab L62ARF4Npq8jlWlgqkGfUa4BgH/jNhCJIDNJEiGa0NSEWNUo8++ImI6kNs70fEImf1mV cInA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=H4h3tF12ZEfzFPQYMHCWJSsoJtIfIJv7oryRTFK6VaQ=; b=nEKBJeDI7FdaDPcIuImBUQdgnPtk88PQ17oBpxdQ/YDGG6AoQRhH2NoRqi1Q1RViVp PaSw650T4OUVTupIwkcnK1qdpmhC2ozbW/wbINRiH6RjUv4lw47p/AaWHxkDaad/7y20 yGXomcOM+XG+RbGTjImc0rK50klEiF5VZthsp+6G2x+Xqj8Aj1OGEWs8u22ASZA3IIj3 umcFcujg9mh53yB+6kN8uNV6+V9LWxMelxa2yOkVoAgkqVCqPvYT5FvX3ha3IEvyc44K NU1BFu6hjZNV3OwgY3VryfyhENOWAFj++D37larqhbPsMtOPBa8LYBR4fpZMwI3gB+78 F0yg==
X-Gm-Message-State: AOAM531tgGCvySja+jsziruq/LhBvHXm3eqJTAHUbpaj3dwJzcp9+izi DJRRVixenoA4qH9Tnl/Mvq8BLA==
X-Google-Smtp-Source: ABdhPJzSEdoMuGkMsQU87mhZZ10+bxh5s3XWJggfWKyfrVhlR4Hx/v0KWI2o4KQ0Xa+qCQn/xJjv9A==
X-Received: by 2002:adf:94c3:: with SMTP id 61mr20017637wrr.289.1597767879882; Tue, 18 Aug 2020 09:24:39 -0700 (PDT)
Received: from ([]) by with ESMTPSA id p8sm36106657wrq.9.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 09:24:39 -0700 (PDT)
From: Raphael Robert <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE883FF8-0E7B-4904-AC68-CAF55A2D2D68"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 18 Aug 2020 18:24:38 +0200
In-Reply-To: <>
Cc: Richard Barnes <>, Messaging Layer Security WG <>
To: Joel Alwen <>
References: <> <> <> <>
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 16:24:49 -0000

I think what you just described is indeed a combination of option 1 & 2. It’s a MAC over the payload we want to authenticate, but it’s implicit and we only include it in the MLSPlaintextTBS. Or in other words, we stripped it from MLSPlaintext because it is implicitly known to any valid member of the group.


> On 18 Aug 2020, at 18:16, Joel Alwen <> wrote:
> Yeah, I like Option 2 here. I like that it avoids growing packet size.
> One caveat though: I'd go for the MAC(...) version rather than the
> confirmation_key. For starters thing including confirmation_key doesnt
> authenticate the contents of the packet. But even if it did, signatures aren't
> meant to hide the contents of what was signed. (Amend you favorite sig scheme to
> tack on the message at the end a signature and you've still got a secure
> signature scheme. But clearly not a message hiding one.) That means that AFAIK
> neither ECDSA nor EdDSA etc. were designed or analyzed for such a property. So
> this would amount to a very non-standard use of a signature schemes by MLS. Not
> saying it doesn't work for the particular sig schemes in our ciphersuite. But
> its def. not how signatures are "meant" to be used.
> But that leaves Option 2 with, say, including tag = MAC(conf_key,
> conf_trans_hash || MLSPlaintext.content) into whats being signed which I like
> and think gets the job done. Both conf_* values are taken from the current
> epoch. By MLSPlaintext.content I mean whats now called MLSPlaintextTBS.
>> I would propose that we do need something additional on Commit messages as
>> well as Proposals.
> @Richard: For Proopsals I think this works. Is that about what you had in mind
> for commits too?
> - Joël
> On 18/08/2020 17:26, Richard Barnes wrote:
>> Thanks for pointing this out, Joël.  I agree that the attacks you're describing
>> should work as things are currently specified.  And they're salient, especially
>> the "replace Alice in the group" one.
>> Also agree with Raphael is correct that Commit is not affected by this, since
>> someone who is not a member won't be able to generate the right confirmation
>> value.  However, I don't think this is actually the right design to adopt for a
>> general solution to this problem.  Confirmation verifies group membership
>> *after* processing the handshake message; the point here is that we should also
>> have a membership check *before* processing handshake messages.  In particular,
>> I would propose that we do need something additional on Commit messages as well
>> as Proposals.
>> Thinking about solutions here, a couple of options come to mind:
>> 1. Use MLSCiphertext, but with an integrity-only encapsulation
>> 2. Incorporate in the signature something that is only known to the group (e.g.,
>> confirmation_key or MAC(confirmation_key; confirmed_transcript_hash ||
>> Proposal/Commit))
>> Option (1) has the appeal that you would only ever send MLSCiphertext, though
>> switching between encrypted/not could be problematic.  Option (2) seems a lot
>> more appealing: It doesn't add any overhead, since the group-secret value
>> doesn't need to be sent.  And we already switch between the signature context
>> that is added for group members vs. external.  In fact, I think option (2) would
>> just amount to a one-line change to include an extra, secret value in the
>> context at the top of the MLSPlaintextTBS struct.
>> The only thing that seems odd about (2) is overloading signature verification in
>> that way, i.e., using the ability to generate a signature over a secret thing to
>> prove you know the secret thing.  That doesn't seem obviously flawed to me, but
>> worth thinking about.
>> Does that make sense to folks?
>> --Richard
>> On Tue, Aug 18, 2020 at 10:55 AM Raphael Robert
>> < <> < <>>> wrote:
>>    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.
>>    Raphael
>>> 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
>>> <> < <>>
>>> <>
>>    _______________________________________________
>>    MLS mailing list
>> <> < <>>
>> <>