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

Joel Alwen <jalwen@wickr.com> Tue, 18 August 2020 16:55 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 9672F3A0F6F for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 09:55:12 -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 WNpwUv_lCHrh for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 09:55:10 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 309153A0F86 for <mls@ietf.org>; Tue, 18 Aug 2020 09:55:10 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id jp10so22950341ejb.0 for <mls@ietf.org>; Tue, 18 Aug 2020 09:55:10 -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=DZ0iFGKXqtIqJJmn8BiOI5xndHr6PH8pNjOlPx7fy4Y=; b=nUNANdirj3PCwAHIJLdGDjn1SzDaS+lt9R6kjm1+XsAeQodE/Ay0d/2lfrcX/B3WZK Vvn6A2nt/6mFIiwSvmauYo03V/G78Clsr+u5tLMmwjKFlN5Hbq9BcYsvcw2QOVDRx6ju e5dHxWGO+JAUfcHVKNPXQIfruBBdZ4azBDMZ/iUvgTBhhIyZlI6tadic76tLqICQGLJ9 mgctS/0tNCNeXxAr3cVzawIyUkXcUlDBFUsMkU3tDm4o9qnu9SSWuUYrsJJJvyRrx/Ox fBUW4fA2I5Ai7f0i4s5SaTNirmtJGkICxqx8QmIwJH8WbAWf2NDU/ZX1m025R336QopY t9JA==
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=DZ0iFGKXqtIqJJmn8BiOI5xndHr6PH8pNjOlPx7fy4Y=; b=ZXw++FIpaenoFX3/rGS8OQ52U3ORvivt+qPdyAAhuGugNSQv4NqYfbiW6ANIEurpBi pRtd9BmkBS/oRepRZXvM9AkyRDm21kDnSMshYrRQ10oGMakjVmCabA15V7puPozJApb+ 7guzy/gJmN2zQVoZNAIbpIolAZK6Z7hRb59x3soBWAOjlI/UrHuoCauta9uSh5bEbIgV oqfU6U7e4bemkuC3YIQ2euuWLJ7kMq7ipoPaE8awPpxH8RI3Diyqjs60jBBxZF7YWPMh TUx2eUsggq7b1Zm2B54VlZBIlEpcotJb/8AAYbysB+f85WYwv+cRCgRp4+Rv2tPjEcti ZGNw==
X-Gm-Message-State: AOAM531PJp7s8Bj4pjt9uX824xyFWaoJrcrjIvXKROQggBhI4DyspZCb tR0LmGf4CrkxKJsOIG5pO/3J+R0eD4avjg==
X-Google-Smtp-Source: ABdhPJxaAcQPe3lvkbPPCqSXFUIy2qn3RNR0ki3Qk9Y8zTblI0M6fcclnXQsZpLkAfFok568djoTEQ==
X-Received: by 2002:a17:906:d102:: with SMTP id b2mr20013556ejz.465.1597769708132; Tue, 18 Aug 2020 09:55:08 -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 i35sm4811017edi.41.2020.08.18.09.55.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 09:55:07 -0700 (PDT)
To: Brendan McMillion <brendan@cloudflare.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <CABP-pSSBcf_BUXPp=uxWMpBviBday8-utGzo=ksPG4Ei=_x3ag@mail.gmail.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: <7abf555f-a266-f62f-2a22-8b0f389304d5@wickr.com>
Date: Tue, 18 Aug 2020 18:55:07 +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: <CABP-pSSBcf_BUXPp=uxWMpBviBday8-utGzo=ksPG4Ei=_x3ag@mail.gmail.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/-I-sQQXMmtj0c-xf-DwDMdIYSE4>
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 16:55:13 -0000

> My objection to this is that Alice can still be impersonated by members in the group, if we only have symmetric forward-secure authentication.

I'm missing how FS sigs (or any other FS auth primitive) helps. My understanding
is FS auth primitives prevent leaked keys from being used to authenticate
messages in *past* time periods. But the attack involves signing messages for
time periods (epochs) after the leak occurred not before the leak. Imagine we
could deterministically ratchet sig key pairs forward much like we can MAC keys.
We'd have an FS sig scheme but I dont see how this fixes the problem.

Which is not to say that FS sigs dont solve an auth problem for MLS. Just,
AFAIK, not this one. (Rather they help prevent forgeries in bygone epochs.)

What I do agree with is that other group members (that know Alice's sig key) can
still impersonate her in future epochs till she updates the key. The same is
true when sending MLSCiphertexts.

Unfortunately, for epochs between when Alice's state is leaked and when Alice
finally updates her (authentication specific) asymmetric key material I see no
way around this. It seems inherent to the adversarial model since other group
member know and can do everything Alice can during those epochs.

One thing we could look at are PCS signatures. Something like the Updateable PKE
scheme in the RTreeKEM work. Namely every time you sign you also re-randomize
your signing key (or simply sample new ones). That way leaking your old key
doesnt let me sign under your re-randomized new key just like in UPKE leaking
your old decryption key doesnt let me read ciphertexts encrypted to your
re-randomized new key. Make sense?


- Joël


On 18/08/2020 18:34, Brendan McMillion wrote:
>     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: https://mailarchive.ietf.org/arch/msg/mls/o3fmIul_4s6STmnqmz514cjADpw/
> 
> 
> On Tue, Aug 18, 2020 at 7:36 AM Joel Alwen <jalwen@wickr.com
> <mailto: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 <mailto:MLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mls
>