Re: [MLS] Re-randomized TreeKEM

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Wed, 23 October 2019 14:50 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 36CBA1209A2 for <mls@ietfa.amsl.com>; Wed, 23 Oct 2019 07:50:55 -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 l8HhaUZvQ5XA for <mls@ietfa.amsl.com>; Wed, 23 Oct 2019 07:50:52 -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 96D87120932 for <mls@ietf.org>; Wed, 23 Oct 2019 07:50:51 -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 CBB70A373D for <mls@ietf.org>; Wed, 23 Oct 2019 16:50:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id V4ZTtYunsPRr for <mls@ietf.org>; Wed, 23 Oct 2019 16:50:46 +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>
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Message-ID: <30eb3e89-7d6b-f23a-fdd8-38c34f298fae@datashrine.de>
Date: Wed, 23 Oct 2019 16:50:45 +0200
MIME-Version: 1.0
In-Reply-To: <CABP-pSSwjq33c7Rg3BWHEgAJH2hkGzvOczjuXtv7GNwHbtFpYw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/PQFie2InT75c9pzSGn4vye7Abv8>
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: Wed, 23 Oct 2019 14:50:58 -0000

> Let's work an example. Say we set a policy that everyone should try to Update
> every 12h and those that don't will be removed after 24h. One user is
> compromised. How long is it until full FS and PCS is restored?
> 
>   * If the user is prevented from sending new Updates:
>       o Whether you use TreeKEM or RTreeKEM, the group is secure again after the
>         user is removed. So after 24h at most, but 12h on average if the user is
>         compromised at a random time.
>   * If the user is not prevented from sending new Updates:
>       o With TreeKEM, you must wait until everyone sends an Update. We're secure
>         again after 24h at most, per policy. The average would trend toward 12h
>         if everybody's Updates are uniformly distributed.
>       o With RTreeKEM, you must wait until the compromised user sends an Update.
>         The user could be compromised immediately after sending an Update, so
>         we're secure again after 12h max. On average, you could say that it's
>         more like 6h.
> 

You're right in this particular example (although I think that eviction after
24h is pretty draconic). However, if you're looking at larger groups (>10.000
members) you might want to scale down the update frequency to avoid everyone
having to process 10.000 updates of a 10.000-member group every 12h. I'm not an
implementer, but I could imagine that this is pretty costly on battery powered
devices (please feel free to correct me if I'm wrong). In those cases, getting
FS for everyone just by processing a single update of any member is pretty
significant. I guess my expectation is that in large groups, other constraints
that also exist with "simple" TreeKEM will dictate a lower update frequency and
thus PCS guarantees will be rather weak, but that doesn't mean that FS
guarantees have to be.

Also keep in mind that even if it's not very beneficial in the example, we
generally get substantially better FS guarantees at a relatively small price in
bandwidth and local computation. Throwing that away because the upside is not
very big in some cases seems unnecessary to me.

If I understand you correctly, then your concern is that implementers could
think that due to the guarantees provided by RTreeKEM, they can get away with a
lower update frequency while maintaining the same security guarantees. That
seems to be a problem that can be solved by providing clear information on what
guarantees are provided upon an update and/or emphasizing the difference between
FS and PCS.

Cheers,
Konrad