Re: [MLS] Unpredictable epochs?

[Richard Barnes <[e-mail]>]

Well, I don't think we can get rid of the epoch entirely.  For handshake
messages, you could maybe get by with the theory that if a message doesn't
apply to the single most recent state, then it's no good, so you don't need
to explicitly say which state it applies to.  But that seems painful,
especially if you want to tolerate a degree of partial order / forking
history.  For application messages, you definitely need it, otherwise you
have an issue with application messages being out of order with handshake
messages.

That said, it does seem like we could maybe steal the epoch from elsewhere
and save a few hash invocations.  The question is what value we could
re-use that wouldn't be leaking information.  The tree hash seems bad from
that perspective, because it is never transmitted in the clear otherwise.
Another option I had pondered was re-using the confirmation MAC value.  In
any case, as a first effort, it seemed simpler to derive a value for the
purpose.

W.r.t. the transcript hash - I have the same suspicion you do, but I am
waiting for someone with a security proof in hand to tell me it's OK to
remove :)


On Fri, Apr 26, 2019 at 2:22 AM Michael Rosenberg <[e-mail]>
wrote:

> I like this idea, especially because it allows for partial ordering of
> GroupStates. One question: could the tree_hash be used instead of an epoch?
> The tree_hash...
>   * ...is not "predictable" in that it would require the DS to maintain
> state in order to establish an ordering on GroupStates
>   * ...necessarily changes after any GroupOperation is applied to a
> GroupState
>   * ...is already built into the GroupState
>
> So why not remove epoch entirely?
>
> Also, side note: given that the tree hash necessarily changes upon each
> update of the transcript, why is transcript_hash necessary anymore?
>
> -Michael
>
> > On Apr 23, 2019, at 11:03 AM, Richard Barnes <[e-mail]> wrote:
> >
> > Here's a PR:
> >
> > https://github.com/mlswg/mls-protocol/pull/152/files
> >
> > On Mon, Apr 22, 2019 at 6:52 PM Benjamin Beurdouche <
> [e-mail]> wrote:
> > +1
> >
> > On Apr 23, 2019, at 12:49 AM, Richard Barnes <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mls
> > _______________________________________________
> > MLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mls
>
>