Re: [MLS] Unpredictable epochs?

Benjamin Beurdouche <> Fri, 26 April 2019 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BFAF1201D9 for <>; Fri, 26 Apr 2019 06:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 69OjkzKjeI-v for <>; Fri, 26 Apr 2019 06:08:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE1741201D8 for <>; Fri, 26 Apr 2019 06:08:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,397,1549926000"; d="scan'208";a="304094947"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2019 15:08:15 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Benjamin Beurdouche <>
In-Reply-To: <>
Date: Fri, 26 Apr 2019 15:08:14 +0200
Cc: Michael Rosenberg <>, ML Messaging Layer Security <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Richard Barnes <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [MLS] Unpredictable epochs?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Apr 2019 13:08:21 -0000

> On Apr 26, 2019, at 2:28 PM, Richard Barnes <> 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.