[MLS] Unpredictable epochs?

[Richard Barnes <[e-mail]>]

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