Re: [MLS] Unpredictable epochs?

Michael Rosenberg <micro@fastmail.com> Fri, 26 April 2019 06:23 UTC

Return-Path: <micro@fastmail.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 D10E212017E for <mls@ietfa.amsl.com>; Thu, 25 Apr 2019 23:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.com header.b=m6g0JS5m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UV1+Gynl
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 SDMD-c8sacns for <mls@ietfa.amsl.com>; Thu, 25 Apr 2019 23:22:59 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032A71200BA for <mls@ietf.org>; Thu, 25 Apr 2019 23:22:59 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E85A020963; Fri, 26 Apr 2019 02:22:57 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Apr 2019 02:22:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=c Yfr6jM6F0MP7+ekkQEaWZi+FA8RZcww202OHcx1MCo=; b=m6g0JS5maxPp7Eh0I vLDSIFn/DgUKS5aJN8Gaz3iXrrOnd4ZjsvgJKjkglhXneCRVcG6JTbxRDoQDx5Cc 0zx7aUgKz2vpnLa1PALLnBsI/fATsXxFNL10VkiXHFkaczffXGFS7krDKBrnq0rX +U64L3REtWyTAIOm0edCYfstv5emuqTLIgbGOxMrrm3Q69hq+qTQs3p9gUy2Oaol KIXhWx9Qp9JG62UCYh+SKy9op1O7dBfmLa/m5SSam23TOOJ/XZIgvpKUetLHWwp0 8a6yTiRZ1W36052tSGb272IKOtRy4YeLZL5aw5nZUnt6KBydzClZ7ZpW7WXqeCjb Mrvng==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cYfr6jM6F0MP7+ekkQEaWZi+FA8RZcww202OHcx1M Co=; b=UV1+Gynlgnr+3bPqHaAoq0K5Ko3XWTLFJBlF015CU7eYiIAJ3YpIXuyJF jiUK/B2tUyLKZu/vRXbOm9yTXyqp77aDfDBzXrmWC5cmbmqoIDhj0C8+QJBD44Oq 1Cs3NKFigOHsEgQ2Ni0N0KvdngCe27PlcSxYghRrcyrSLPwbfRo0WvN/50T29Kxn r1ja9Ue7zYHwcMGBYfcZ7Xx/jXuj02wleRZFXfllzMHMsSuuPksec/xHt72ap48i 6SLdGv2Vb9bHjY4D8I6gy67fcsc9Uk1Z1jUa4IolqkcGiOlWnRacLaTbyQboBdGG wVUqJ7NwiOmjbdIhtbxqG5WuCVqQQ==
X-ME-Sender: <xms:waPCXIIqiwJLKMM2O-5w4Kaa4a7O4jpUc0MDLhfXIxbhD_s5Jy81xg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheehgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpefoihgthhgrvghlucftohhsvghnsggvrhhguceomhhitghr ohesfhgrshhtmhgrihhlrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpd hivghtfhdrohhrghdpmhihtghouhhrshdrvghsnecukfhppeejgedrjedurdektddrledt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmihgtrhhosehfrghsthhmrghilhdrtghomh enucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:waPCXHHqdJ0bPYMSIJRWlrLFRcg7sqFr7KTn1oqNCqUrthjTOhKC2Q> <xmx:waPCXEzLP2dgve4oWUppK-92-tfg9j7RKXz0yVpDOjI1D793GsEx9Q> <xmx:waPCXI5Hw_mbHdTJ-igT_aOToRVnYsquzj4r3WYwmB1JZ4EubC4k4g> <xmx:waPCXF_DZ2IMt6yRdzUzo4i46D2FHD_jc4K34LU6HEHExejQJniCgQ>
Received: from [192.168.1.157] (cpe-74-71-80-90.nyc.res.rr.com [74.71.80.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 1629AE4122; Fri, 26 Apr 2019 02:22:57 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Michael Rosenberg <micro@fastmail.com>
In-Reply-To: <CAL02cgQ7-JMQsG6sq6YBB3G-5tmCVQoo07nvW63tzBzHPQ0ZWw@mail.gmail.com>
Date: Fri, 26 Apr 2019 02:22:56 -0400
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC74CACD-541B-49CD-9CC9-63343307A53D@fastmail.com>
References: <CAL02cgSE1xTF2Wsq-u=BCu2Z_4UzMzqMPi=D_H7_7hbRpUMVVA@mail.gmail.com> <2D195D14-9F9A-4D64-92EF-35C601C52C01@inria.fr> <CAL02cgR8gQ6cH_QXd_9v46aJ5aeo=b=1GiYu9YxCNYzJb0tOFQ@mail.gmail.com> <B36BF8F5-EAE9-4C96-A867-82CDFBF830C0@inria.fr> <CAL02cgQ7-JMQsG6sq6YBB3G-5tmCVQoo07nvW63tzBzHPQ0ZWw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/V9374hVJGP-SYChPadyiNE-tXIY>
Subject: Re: [MLS] Unpredictable epochs?
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, 26 Apr 2019 06:23:02 -0000

I like this idea, especially because it allows for partial ordering of GroupStates. One question: could the tree_hash be used instead of an epoch? The tree_hash...
  * ...is not "predictable" in that it would require the DS to maintain state in order to establish an ordering on GroupStates
  * ...necessarily changes after any GroupOperation is applied to a GroupState
  * ...is already built into the GroupState

So why not remove epoch entirely?

Also, side note: given that the tree hash necessarily changes upon each update of the transcript, why is transcript_hash necessary anymore?

-Michael

> On Apr 23, 2019, at 11:03 AM, Richard Barnes <rlb@ipv.sx> wrote:
> 
> Here's a PR:
> 
> https://github.com/mlswg/mls-protocol/pull/152/files
> 
> On Mon, Apr 22, 2019 at 6:52 PM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
> +1
> 
> On Apr 23, 2019, at 12:49 AM, Richard Barnes <rlb@ipv.sx> wrote:
> 
>> True, you could have one unpredictable identifier that identifies both the group ID and the epoch.  I like how that looks on the wire, but would require a bit more bookkeeping in clients.  I might be inclined to go ahead and land an unpredictable-epoch PR in -05 (since that's a pretty small change), then look at folding in the group ID later.
>> --RLB
>> 
>> 
>> On Mon, Apr 22, 2019 at 6:42 PM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
>> Side note before I forget. After merging the common framing, the only two things potentially remaining in the clear will be the group identifier and the epoch number (because we need those to pick the group key necessary to decrypt the sender info). Raphael and I talked about adopting a similar approach but generating an ephemeral Group Id at the same time. That could help a bit on the meta data protection side by making it harder for an adversarial DS to be able to correlate messages in delivery queues across groups and across epochs. The fact that this might be useful or not depends a lot on architecture assumptions though....
>> 
>> B.
>> 
>> On Apr 23, 2019, at 12:11 AM, Richard Barnes <rlb@ipv.sx> wrote:
>> 
>>> Hey all,
>>> 
>>> As I've been working with Benjamin on updating and landing the common framing PR, I noticed that the epoch is still exposing more information to the DS than it needs to.  
>>> 
>>> Right now, the epoch just increments by one every time the epoch changes.  This lets the DS track epochs statelessly -- it can take any two messages and see which was before the other, without the need for any ongoing tracking.
>>> 
>>> However, the epoch only needs to be intelligible to members of the group, so we could generate epoch values in a way that would only be intelligible to members.  For example [1]:
>>> 
>>> epoch_[n] = HKDF-Expand-Label(some_secret_for_epoch_[n], epoch_[n-1], "epoch", 4)
>>> 
>>> That way, the DS could observe epoch changes, and observe how many messages were sent within each epoch.  But it wouldn't be able to understand the sequence unless it tracked things all along.
>>> 
>>> A side benefit of this is that it allows the group to have forks in its history more cleanly, since different forks will have different epoch numbers.  That could allow some softness in the ordering requirement, as long as the group can eventually figure out which branch is the right one [2].
>>> 
>>> Does this seem worthwhile to people?  The cost is a few extra hashes.  To me, the completeness/consistency seems like a marginal benefit, but the clean forking seems pretty convincing.  If folks think this worthwhile, I'm happy to write up a PR.
>>> 
>>> Thanks,
>>> --Richard
>>> 
>>> 
>>> [1] I would probably keep epochs at 4 bytes, because any more seems wasteful.
>>> [2] http://mycours.es/gamedesign2012/files/2012/08/The-Garden-of-Forking-Paths-Jorge-Luis-Borges-1941.pdf
>>> _______________________________________________
>>> 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