Re: [MLS] Unpredictable epochs?

Richard Barnes <> Mon, 22 April 2019 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0EF6120177 for <>; Mon, 22 Apr 2019 15:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id APrJl1UnrzDS for <>; Mon, 22 Apr 2019 15:50:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5042120168 for <>; Mon, 22 Apr 2019 15:50:06 -0700 (PDT)
Received: by with SMTP id 64so11060966otb.8 for <>; Mon, 22 Apr 2019 15:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XSdy/Ssoymxp5+GJ8rAQy+exF9AZi+jm4o4OoZC39NM=; b=cWOQy2DJPpy8NJD+vjmYRs3ULbkifZo1WJQDbSy3/9UI06sF51Bmb5Xr9BmrbZpnz6 Negsua13KvDhB/VQ9n1DVrHh3HeKYPhgmpeMntqDgdjtXBVInxjTfNas+noiOnQrJuol K3RLA6gqMr6ZV8zJbGlxn2g5HqNLYIoDbiyxTNZS+YVFiEwEQyvTx4g54KHDNThJSbMZ ZwdsDZ//Jwd779FxHJa8MKagNEuSCPOjFfec0Ybutfsf7vno/i17o+48NPspaEp5Vcl1 6tHfwtUOhMUaWfGb+1zNNxnijZZU+D08ClWBc0NHQ1ur4tBoXTwekDRtVZQMeDOL0b8+ pRtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XSdy/Ssoymxp5+GJ8rAQy+exF9AZi+jm4o4OoZC39NM=; b=gaOelS/Cusaif/VCbjHnY9N9IoUJJi4cpqrevWwf961mAxMB8+yyxQCEz2gVX45X9N oT9r/DPcl7ksvr7RSyC+RBvK0+GoF71JxTVVINRJQlkMk0WdmyYHdiMEJKrOd4Dw3rOV qy4k++S+4Tgovf6kkWdXKiUZFhO5i+ecQLDpU3+H7Tx73d7HMIzegjFAkXBUDCXnv/4Y BDlG3esUfKFffoQlGWzoXZh7LvHJhwS6sRudjqToJLtkx/Opw+i+Bzw+qSVyuaD93QUx TgMo2OBY7SaD57wUeI3FMaTOGtcP5FoAM5Mg9h3GU0XE4O5mQo97CAo1HiWoCkayLMTa X7IA==
X-Gm-Message-State: APjAAAWc48AcTSQ47V2tLJ8Ja9fcovh263CRL+2akLLQnrsTCFOUqw4n gMXJmYgqObZE/jHAic3I5sIipqtmowJ4BmKXBgn7qQ==
X-Google-Smtp-Source: APXvYqyZdhw/HI8BeZgfEVEKZU72pCsf0FQ0XK9rISQVoIzCnSrQnvz5sNaoGL2B7yCECAIkBfnB45ra85Zw3RL8LXY=
X-Received: by 2002:a9d:518e:: with SMTP id y14mr12943742otg.23.1555973405925; Mon, 22 Apr 2019 15:50:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Mon, 22 Apr 2019 18:49:46 -0400
Message-ID: <>
To: Benjamin Beurdouche <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000023f5290587264a37"
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:50:09 -0000

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.

On Mon, Apr 22, 2019 at 6:42 PM Benjamin Beurdouche <> 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 <> 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