Re: [MLS] Unpredictable epochs?

[Richard Barnes <[e-mail]>]

On Fri, Apr 26, 2019 at 9:08 AM Benjamin Beurdouche <
[e-mail]> wrote:

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

We might have a problem in any case, then, since the transcript hash
doesn't cover the signatures either.

--Richard


>
> B.