Re: [MLS] Unpredictable epochs?

+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