Re: [MLS] Unpredictable epochs?

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