Re: [MLS] Unpredictable epochs?

Benjamin Beurdouche <> Fri, 26 April 2019 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5556512051D for <>; Fri, 26 Apr 2019 13:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XQz4qEfQIMs0 for <>; Fri, 26 Apr 2019 13:18:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C3B51205D4 for <>; Fri, 26 Apr 2019 13:18:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,398,1549926000"; d="scan'208";a="304131690"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 22:18:11 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Benjamin Beurdouche <>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <>
Date: Fri, 26 Apr 2019 22:18:10 +0200
Cc: Michael Rosenberg <>, Richard Barnes <>, Messaging Layer Security WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Jon Callas <>
Archived-At: <>
Subject: Re: [MLS] Unpredictable epochs?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Apr 2019 20:18:17 -0000

> On Apr 26, 2019, at 9:26 PM, Jon Callas <> wrote:
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <> wrote:
>> So why not remove epoch entirely?
> An epoch lets you deal with things happening neither too often nor not often enough. Presume there is a client that is either malicious or just stupid. You want to keep it from forcing a rekey every 100µs. You want to force a rekey every so often. Hence epochs. Yeah, picking the right epoch size is an exercise left to the reader.

You can’t use the epoch number for that as it is just global counter for group operations, we will have to keep track of the latest group operation “timestamp” for each member within the group state to check “update frequency” and handle some of the situations you described.

Btw in the TreeKEM formal spec I use a 64 bit unsigned integer, and I feel like having more than 2^32 group operations over the lifetime of a group is not unrealistic in certain extreme use cases, especially with large groups forcing PCS for application messages by triggering an update after each app message...

We could remove the epoch number if we really want but it is necessary to give the Delivery Service some ordering information (unpredictable or not is an interesting question) to handle concurrent handshake messages which is, I believe, the main current goal of that information.