Re: [MLS] Removing redundant ciphertexts in commits

Richard Barnes <rlb@ipv.sx> Fri, 25 September 2020 15:05 UTC

Return-Path: <rlb@ipv.sx>
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 A54963A0E3E for <mls@ietfa.amsl.com>; Fri, 25 Sep 2020 08:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.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 fikxqL5nI-n1 for <mls@ietfa.amsl.com>; Fri, 25 Sep 2020 08:05:53 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 ADBEE3A0D3C for <mls@ietf.org>; Fri, 25 Sep 2020 08:05:53 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id y11so2119206qtn.9 for <mls@ietf.org>; Fri, 25 Sep 2020 08:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q1fGiUv9VBCwJECXLUttQ72UxOK4HNf/n1EzZslQ1Us=; b=08nFxh6pOfz2u58gYrmfbNC1U7avPSzPLlSviqCwBo4Nhki/0c40LRDi4P9MWP5goP dQGh5nBfMPzhvCdcC8q09SPxcxbjVbJHbjexWQDa0kA40391MKfyA7K2dZwHehLPpVNF YyyyZQXMLPSe0k5d2pFcvKhEIfm8+VFHMGBxB2QzWe06St+Qlp7RI0W/UivgWvIwjZse ClKNmcvnWT2ywaZYHbmc8cV9NMQwUuEvQOetUjxGpevcOU4mJyqkeLnsvPa7Xytak1Hl X7ylR1ko3iEwQMfg++ZNggkX4dt7RPZWE7USPqGbArITa6OSjoIHUcrQctiScumLcYkv qt/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q1fGiUv9VBCwJECXLUttQ72UxOK4HNf/n1EzZslQ1Us=; b=gZX6fZr+UylhZmlH4KZVkLjPPFmUZJfYvW9pbB1VKv+alYsSyZptyYNuc6K3aL4roe 5kR15BBJdE2k9Pa8eaS2v4B88vnQPYAdZkvD3k8Fyb98vH0MmEcoUzbAdJv/x6P+SImc xVdHSXrV2DrJ/9P6dIFYGeQHxO/T+bZ2Ztzxno249Tqq3mGaeOH75zGTeHcd8iy9V5yG ElizoRJx6XfplIwy4k1XNfK/AQlEG+uJO21pUPs+FST68zmDwNYqMI7b0vewzANkQpDJ Vjr+mhD9I4exQWwVjD3jswu9Llh1Pzwi/gOtdgmssEeEu1QwPf1ISn3WmCcyGraQwhC3 VXsQ==
X-Gm-Message-State: AOAM533FZEWEMrkvPkwGL9NPaQH1EohpqVxMh2J4hBAkHqDIMnXqLM2O QxVQjVcekCNLcjYh1cGNL4w732jGTcR8DHZj1hqScA==
X-Google-Smtp-Source: ABdhPJwFXYAV5HCOQJp+eFJdqNMSgWVM4iYd1S/Wb2zY7Wrsid2ItRkljr25mmtFRYTd/EQ01AuG58elo23SwKtm9JM=
X-Received: by 2002:ac8:142:: with SMTP id f2mr4665318qtg.191.1601046352189; Fri, 25 Sep 2020 08:05:52 -0700 (PDT)
MIME-Version: 1.0
References: <eb52dca7acba43d288ecf60a233b7e29@inf.ethz.ch> <fede2390-6f5d-ab4e-eaca-176bff7bafdc@wickr.com>
In-Reply-To: <fede2390-6f5d-ab4e-eaca-176bff7bafdc@wickr.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 25 Sep 2020 11:05:11 -0400
Message-ID: <CAL02cgSC28394195iwUy-APqWSjWWn7AhL2ci3=C7bd1ne5Xsg@mail.gmail.com>
To: Joel Alwen <jalwen@wickr.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000176dbb05b024a757"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/jDZ2fizVbH42v-p86cMcofIsfMU>
Subject: Re: [MLS] Removing redundant ciphertexts in commits
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: Fri, 25 Sep 2020 15:05:56 -0000

No, this makes sense.  I think things are the way they are because the
Commit used to be processed by the joiner, but that's no longer the case.

Thinking through how this works in practice... Right now, the order of
operations is as follows:

- Apply Update/Remove/Add proposals
- TreeKEM.encap()

I think you still want to do things in this order.  For example, you don't
want to process Add after encap(), since this will cause the new joiners to
be marked as unmerged leaves when they're really merged by the Commit.  The
better solution here seems to be to update the encap()/decap() algorithms
so that they have an additional "exclude list" argument, which lists leaves
that MUST be excluded from the computed resolution.  This has to be done on
encap() and decap() since the structure of the resolution defines the
structure of the UpdatePath.

Looking forward to the PR :)

--Richard

On Fri, Sep 25, 2020 at 10:26 AM Joel Alwen <jalwen@wickr.com> wrote:

> So does anyone else see any reason for those ciphertexts? If not we can
> draft a
> PR to get rid of them...
>
> - Joël
>
> On 21/09/2020 09:37, Jost Daniel wrote:
> > Hi all,
> >
> >
> >
> > When working on our analysis of the standard with Joël Alwen and Marta
> > Mularczyk, we noted some inefficiencies around commit messages.
> >
> >
> >
> > According to our understanding of the draft, UpdatePath contains
> encryptions for
> > newly added group members. More concretely, the draft states "If
> populating the
> > path field: Create a UpdatePath using the new tree (which includes any
> new
> > members)" and in Section 7.7 "The number of ciphertexts in the
> > encrypted_path_secret vector MUST be equal to the length of the
> resolution of
> > the corresponding copath node." However, at this point, the resolution
> will
> > already contain the freshly added leaves via the unmerged_leaves list.
> >
> >
> >
> > First, this wastes bandwidth and computation as the commit message is not
> > intended to be received by parties being welcomed. Second, this poses
> an, albeit
> > small, additional attack scenario where an attacker gets hold of the
> freshly
> > added party’s decryption key but not the welcome message (that may have
> been
> > communicated over a secure out-of-band channel).
> >
> >
> >
> > One potential solution would be to explicitly exclude freshly added
> parties from
> > the resolution in that step, at the cost of some additional
> book-keeping. Of
> > course we are open to suggestions if anybody has a better idea. If not,
> we are
> > obviously happy to draft a PR.
> >
> >
> >
> > Best,
> >
> > Daniel
> >
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
> >
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>