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

Joel Alwen <jalwen@wickr.com> Tue, 18 August 2020 14:36 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 D889E3A0B4E for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 07:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 HPl-oSviiQRN for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 07:36:18 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 5F58C3A0B79 for <mls@ietf.org>; Tue, 18 Aug 2020 07:36:18 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id a14so15445095edx.7 for <mls@ietf.org>; Tue, 18 Aug 2020 07:36:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=from:subject:autocrypt:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AW79SmbYxYG2SFlgTcH1CvoT0vB1X1orO9Gy6/fbpCs=; b=05ZDuHWUYTwMNnf56gBHFXSBGds7km2OWGZqtJuxiQL04sQZ0EOdOGgJfWy7mpP7Zn Y57LsvhcIEsFI/H/+z4gX32b0BUf+vm2flLCLdlw4xhlYuy+0uEPysO08Qpx0Sm3bm01 Fe802xAr5hdXEDaeHrwP0SB/pJ9U7msYIjJidTNKTSwMSd87VtilQeEfHgg2TJ8g4vWO dP1wmCUW3Fanjz+pzU14kNHN2VDGwhCHqjGaaCQ9fVE8B6SYqwyl1G3G0OR+7jHllJjp o3xM30YCMwPzv4NsiG1PpL7IcAIMXvGGg/Jyh2t9/R9Wl2DrPr9HSVwmoB8byTI/tXOp mRww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:autocrypt:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=AW79SmbYxYG2SFlgTcH1CvoT0vB1X1orO9Gy6/fbpCs=; b=MYS1+MCc0NU/GXCEcCCgXFUQqt7rnO9FyUvhEmm4w4IIPXiZl20ROQKWapB4st0uep 3+OD7iYJqvMITiPHLC0BsuprHIaRHdSmdb9lw1XsV+F486LKQEyINtam68whbkBGaqXK uvooB8OHL3QHNHcRESICdN4ma5xFyLevtYmLs3Wdxa+L1022pyeTc/oz6nZ9AYXoiZDb X5fwhQcutGKNjZnOfwUaTzsa7r7U888Gle4WYcpSRZZg6ZTGmbSUNJZfEP/5OLHgaICw E6SogvE3UmqmJdSXJap0CHYTqTqXX+Dn4W2f6bdo97A7AvGrOwIvJIcg7G+A+ymoUN/U FFyQ==
X-Gm-Message-State: AOAM532dwcS9T2bEaiw2CzCO1HKMZB41Djuljwjpobz1TDVC/6pmG3vk a6TqNvbZyLstTR73CK1RmACwSuN8gj72Nw==
X-Google-Smtp-Source: ABdhPJzocSVKPWQxhK+WxENdv8AajYJQ6V0n2CX3GxSlWY5wUPNg2PVYHX11l7JscVaAVrbkuHt9Kw==
X-Received: by 2002:a50:c089:: with SMTP id k9mr19557476edf.110.1597761376303; Tue, 18 Aug 2020 07:36:16 -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 g25sm15647701edp.22.2020.08.18.07.36.15 for <mls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 07:36:15 -0700 (PDT)
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==
To: Messaging Layer Security WG <mls@ietf.org>
Message-ID: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com>
Date: Tue, 18 Aug 2020 16:36:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/3SzIzRwdEGPgvq6X2zTlB19WXgk>
Subject: [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 14:36:20 -0000

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.