Re: [MLS] Re-randomized TreeKEM

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Thu, 24 October 2019 07:24 UTC

Return-Path: <konrad.kohbrok@datashrine.de>
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 EACFB120824 for <mls@ietfa.amsl.com>; Thu, 24 Oct 2019 00:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 ehHi6jJuh-Cd for <mls@ietfa.amsl.com>; Thu, 24 Oct 2019 00:24:28 -0700 (PDT)
Received: from mx2a.mailbox.org (mx2a.mailbox.org [80.241.60.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68071120860 for <mls@ietf.org>; Thu, 24 Oct 2019 00:24:27 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2a.mailbox.org (Postfix) with ESMTPS id 81073A3369 for <mls@ietf.org>; Thu, 24 Oct 2019 09:24:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id Pco-9pNpX-5L for <mls@ietf.org>; Thu, 24 Oct 2019 09:24:20 +0200 (CEST)
To: mls@ietf.org
References: <5b1d9cb1-509a-da7d-1361-188dfe0f21d6@wickr.com> <4BEAE096-9597-4619-ADD4-CE13E899481B@inria.fr> <CAMvzKsgMvLP5mmk8fOoTopKhFM6+EQzognv4Eq_FfMHSs9qwiA@mail.gmail.com> <5673C061-B15D-4DD2-A90C-4F179E82C31A@inria.fr> <133ba15a-037f-6a3b-182c-836b14ba233b@wickr.com> <B8059BBC-8368-4C6B-B64C-3B98153F9A4E@cloudflare.com> <a1033442-7394-bdb7-5be3-24b92d75290d@wickr.com> <CABP-pSQ5fQ8ohsnB2XJDLgXEh=PcHmhrrPY-76Pr9evx0g1_QQ@mail.gmail.com> <924d06c6-aa9e-2a8f-ba2e-abaae1b152e2@wickr.com> <CABP-pSSwjq33c7Rg3BWHEgAJH2hkGzvOczjuXtv7GNwHbtFpYw@mail.gmail.com> <0c91edbb-2426-c175-2d35-2ca3fed76902@cs.ox.ac.uk> <CABP-pSTiR7aYhDKT3P5jqjBHvFQ7a8C7SZUDLtvZqc7gSkEBcg@mail.gmail.com> <5a2a13e8-30d5-a3be-a49c-c4495f45e498@cs.ox.ac.uk> <CABP-pSQGQEc39hJ-WDp7rJcJGzOrW-03NY5gyVhm_WywFRL__g@mail.gmail.com>
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Message-ID: <360fb300-6171-3def-4ca7-8d56b5f8bef0@datashrine.de>
Date: Thu, 24 Oct 2019 09:24:18 +0200
MIME-Version: 1.0
In-Reply-To: <CABP-pSQGQEc39hJ-WDp7rJcJGzOrW-03NY5gyVhm_WywFRL__g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/P4BjcEyTdprV9oVYw5VJAAYmj3I>
Subject: Re: [MLS] Re-randomized TreeKEM
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: Thu, 24 Oct 2019 07:24:31 -0000

Hi Brendan,

> There's no benefit to processing random Updates from random users. Even in
> RTreeKEM, the benefit comes from processing the one Update from the one
> compromised user. In TreeKEM, you need to process the compromised user's Update
> and then everybody else's, which takes 2-4 times as long or so. So this is the
> same, regardless of the group size.

I might be confused what we're talking about here. In RTreeKEM processing a
random update from a random user allows the processing party to achieve FS.
Meaning that if previous messages and key material are deleted properly, even a
full compromise of the processing party doesn't give the adversary access to
those deleted messages. In regular TreeKEM on the other hand, processing the
update only gives the sending party FS guarantees.

Regarding Dennis' example:

> This doesn't agree with my understanding of MLS. The way I'm reading your
> example, AEAD(m, ...) is application data? There's a section in the spec titled
> "Sender Ratchets" that describes how after application data is decrypted, the
> symmetric decryption key and anything that you might be able to derive it from
> is erased. So all of that erasing happens at t+1 and the adversary has nothing
> to work with at t+2.
>
> If on the other hand, AEAD(m, ...) is referring to something in the handshake
> messages, that shouldn't be an issue either. Yes, the ciphertexts can still be
> decrypted but epoch_secret[n] = HKDF(init_secret[n-1] || update_secret) where
> update_secret is what's decrypted, and init_secret[n-1] was deleted after the
> handshake message was processed. The adversary shouldn't have access to
> init_secret[n-1], so he can't compute the next epoch secret.

You have a good point in that the deletion of the init_secret gives you some
form of FS, but it's somewhat fragile in that if the adversary has gotten hold
of an init_secret in the past by some other means (e.g. compromise of another
party), that fragile FS is gone.

The way I understand MLS (and I might well be confused about this) and the way
FS works is as follows.

Example:
The adversary compromises A and thus gets the init_secret of epoch t. Then A
issues an update, recovering from the compromise. Some messages are sent and
some parties send updates. However, in TreeKEM if the adversary compromises some
party B at epoch t+x that has not issued an update since the compromise of A,
all messages sent in epochs t..t+x are exposed. This is because that party's
HPKE keys have not changed. Those compromised HPKE keys of B allow the adversary
to decrypt the update messages from the wire and, together with the init_secret
of epoch t, lets them decrypt any message that was sent since then. Handshake or
otherwise. In RTreeKEM on the other hand, the HPKE keys are updated as soon as
A's (or any other) update is processed and thus every processing party
immediately achieves FS.

Note, that if I understand the key schedule correctly, deleting the encryption
key doesn't give you FS, because the adversary can still derive all the
necessary keys once they have compromised the handshake secrets and get the
group key as detailed in the example. Feel free to correct me on this, though.