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

Joel Alwen <jalwen@wickr.com> Tue, 18 August 2020 15:16 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 6BDE03A0C92 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 08:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, 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 Aod31OGpYkDS for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 08:16:55 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 9A86D3A0C8B for <mls@ietf.org>; Tue, 18 Aug 2020 08:16:48 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id t10so22519735ejs.8 for <mls@ietf.org>; Tue, 18 Aug 2020 08:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S1JKtN4K4AqKtaVmuSCvrySYYE1sgggA4D2Mpn0aVe8=; b=ohmtDr/gnUOVEk/ZAhDyCc8wxXcMQjNeX5N3Yjg8egN4y2PN7HtL20ftouXWMwXMIZ EM+VlSMjl76iaGs8C3NurB+tMWIdoXr3MgaPkTRL7C1zLdMH5EP4/vyo3CVhsfqszxpk 3khhjvDOlQk8EMR8a0cSjndhujZNOE6FZqtKmM1WNh3j3pLIj2AYjNjYuXbcylL3m7q2 mwG+f+9kD0EAxx/Z3JNAVUlga5DmD7unlo498wnUP6D3scVrPYYlIJ0lYTo54qXGt/Hv ENwrL5/i+dBog4zlpz1zEwv3MCSeMDpZLeguRUdRO/i4tWrf8tYQ/iyGXMVsUY/iKYJh V2Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=S1JKtN4K4AqKtaVmuSCvrySYYE1sgggA4D2Mpn0aVe8=; b=ZpIN8jVYX15L/Fp5cpIQ1B35XhNCKFzO+mtX9XK18tgmejV6AKdi4z7tHovPFyqU6K SzsoVN3kSXqBBjcjBrOW7LOs7msy18cvLnMDlkN0BwvoqDG1iam3XASKU/Ilfmftnfy+ tphug75VVP1jDvOkAi/3RGGnUhSUHcqMBGFyHbhxqJRpz3j6JpFphxkP0YLOeSNtmEp9 ZnSHhs+oPul6F9VntPLTMm1jAIdX8vxPM0t8rGiaCtdg6u/C+FVDn28i9ORzdyonzWYR 1aL2eSn5GjCpBFb6iX8vf8HRjacO/vosihaQDLqhVkFzazr7QQDwIr6KXitkorNeGZcS mhpg==
X-Gm-Message-State: AOAM530Ydfhiz5FUaJeq+O4YVfwF+tQaXo1RdQrF/plBVgDkzANcEpxv 3AzyYIuAl1q10dp68VZe4dhK7g4/fCmTXw==
X-Google-Smtp-Source: ABdhPJx7Q8jOC0myziVSk1sVIyAhEs+6pRNbDSmuJYp66K5K+WEW165vJAesMy8TaTITtBqx4YdVHg==
X-Received: by 2002:a17:906:2e51:: with SMTP id r17mr20092646eji.308.1597763806499; Tue, 18 Aug 2020 08:16:46 -0700 (PDT)
Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id qk30sm16653467ejb.125.2020.08.18.08.16.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 08:16:46 -0700 (PDT)
To: Raphael Robert <raphael@wire.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <F5B1E029-D8B4-4BEA-BF7A-CDD531D662BD@wire.com>
From: Joel Alwen <jalwen@wickr.com>
Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw==
Message-ID: <ae733939-9536-ec3e-67bf-24d1a7112ffc@wickr.com>
Date: Tue, 18 Aug 2020 17:16:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <F5B1E029-D8B4-4BEA-BF7A-CDD531D662BD@wire.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/YF0Xrca6Tcuy95fMlKPey-9m8Ds>
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 15:16:57 -0000

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

Yup, all this only applies for that case.

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

TBH for commit messages I haven't thought it through yet. (The attack on
Proposals looked like enough of an issue that we might wanna do something
already.) But on further thought we might be OK already for commit msgs. The
confirmation_tag is, in particular, also a MAC of the MLSPlaintext packet's
content as that's part of the confirmed_transcript_hash. That really doesn't
leave any room to reuse Alice's confirmation_tag values to forge a non-trivial
commit on her behalf. So a non-trivial forgery requires computing fresh tag
values but that won't work with out the symmetric key schedule which was the goal.

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

Indeed. As far as I can tell those simply having nothing at all that depends on
the symmetric key schedule.

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

Given that Commit's seem ok as is, how about adding an opaque tag<0...255> to
MLSPlaintext struct if and only if content_type == proposal && sender_type ==
member. In that case we set tag := KDF.Extract(confirmation_key,
MLSPlaintextTBS). (Here, conf key is taken from the current epoch.)

- Joël


On 18/08/2020 16:55, 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 <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
>> https://www.ietf.org/mailman/listinfo/mls
>