Re: [MLS] Unpredictable epochs?

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
>
>