Re: [MLS] Unpredictable epochs?

[Benjamin Beurdouche <[e-mail]>]

> On Apr 26, 2019, at 2:28 PM, Richard Barnes <[e-mail]> wrote:
> 
> 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 :)

I will do a round of review next week but *from what I remember* about the proposal,
I don’t think you can do that. The transcript hash contains strictly more information than
the tree hash anyway, especially for authentication. I’ll check when reviewing but if the tree hash
doesn’t cover the signatures, for example, then you can’t replace one by the other.

B.