Re: [MLS] Unpredictable epochs?

Benjamin Beurdouche <> Mon, 22 April 2019 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D377120199 for <>; Mon, 22 Apr 2019 15:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QOq4HOqN7dh4 for <>; Mon, 22 Apr 2019 15:42:06 -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 292A7120168 for <>; Mon, 22 Apr 2019 15:42:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,383,1549926000"; d="scan'208,217";a="379704174"
Received: from unknown (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2019 00:42:03 +0200
Content-Type: multipart/alternative; boundary=Apple-Mail-223F77F6-BB08-45CE-886C-6300CBBF8F15
Mime-Version: 1.0 (1.0)
From: Benjamin Beurdouche <>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <>
Date: Tue, 23 Apr 2019 00:42:03 +0200
Cc: Messaging Layer Security WG <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <>
To: Richard Barnes <>
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: Mon, 22 Apr 2019 22:42:09 -0000

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


> On Apr 23, 2019, at 12:11 AM, Richard Barnes <> 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]
> _______________________________________________
> MLS mailing list