Re: [MLS] Unpredictable epochs?

[Benjamin Beurdouche <[e-mail]>]

> On Apr 26, 2019, at 9:26 PM, Jon Callas <[e-mail]> wrote:
> 
>> On Apr 26, 2019, at 2:22 AM, Michael Rosenberg <[e-mail]> 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.

Benjamin