[MLS] Unpredictable epochs?

Richard Barnes <rlb@ipv.sx> Mon, 22 April 2019 22:11 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3B85B120151 for <mls@ietfa.amsl.com>; Mon, 22 Apr 2019 15:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t1H5kB33IsrG for <mls@ietfa.amsl.com>; Mon, 22 Apr 2019 15:11:21 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC1812013F for <mls@ietf.org>; Mon, 22 Apr 2019 15:11:21 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id l7so113111oil.11 for <mls@ietf.org>; Mon, 22 Apr 2019 15:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=TrtSQLhT+6XvCthkvay0OMmoy9jdPCeMI8Gq9aH/9eY=; b=BPr6PKvvzexWTOUwDa6Nq4G9d+7pAB21Ql+NJsI23RdHC8w3uGodPBna1qQy77Yk/2 PbsGMzUTPiD16LB6g3eeN8nBJsB7m0L+S6tS/xXpU9Xme+ZNnOJEUn1/SorYlkL+C+/i ns6A+6VMY9Fu3vwsdUFFt9wh1FtP6Evb3Vnt7t1tcsTmcwrAXMB2KDIIJCHTU7/4M2Tu 6RSYLh6VbsFj4U9lAkJuKFaRHrp1+qp+O+3JEMzK4J4h/q/UlPCSlZ9dYme20U1uPudA lPpJzQkU+c/Eht16fQcY2G+WgeBgrMzp2sNKLgAMdrvpGRZxfw0xRZhBLVayxPbvwtVy +s0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TrtSQLhT+6XvCthkvay0OMmoy9jdPCeMI8Gq9aH/9eY=; b=FsEMFsHgKs+fpXgp1hNDq/bJyl/Z3f31DxuM+sQPIqdRXYENqv8Kac//PcvCq5IhLb 7aGVz9OZDSC7qTe0TcCumEENmnniI8S8kAi/Y2Anw6nkCKC8UNwFiLsDZOIIRAVL3xbD QoHfRpbzXXQb9F1w4rEG4sP7qCz0WbSbz64hOlQxhN28LrHEkH3bIdfH+YPLsmwWTswl /Suxrx8vw9PLjNObTDpf85OdgICwP8A75OJOKI5VWS4V0wttcBCDwDjdSemkgiDUyu9U /FLQVXdSZ5i/dz0mSRp9Dc9yMtQ0/yt47gvPw1qpdl/QVGHILW9sOsQmpBkslWg0OR4V pSPQ==
X-Gm-Message-State: APjAAAW2LS5brrpeoS5h4naI47SopO9yPi+qhJX9MB++OgteTcIbXSJS pe7bwlJbKq/TF+pPfiDg7gBPa9DMFhVziYIqXCTttuSI2cZbSQ==
X-Google-Smtp-Source: APXvYqz0s3Z1kcm90l+mGm2ocgju1bWTNJ2/yTOAaW2Z64fe0vzomNIPAlTrzvrq0qVUl0SO3RisKz3TWCWxeBFQR1A=
X-Received: by 2002:aca:b886:: with SMTP id i128mr265398oif.169.1555971080396; Mon, 22 Apr 2019 15:11:20 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 22 Apr 2019 18:11:00 -0400
Message-ID: <CAL02cgSE1xTF2Wsq-u=BCu2Z_4UzMzqMPi=D_H7_7hbRpUMVVA@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000873420058725bf63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0ff3PS5hdm9Zjbzrfhz1bO2ISUs>
Subject: [MLS] Unpredictable epochs?
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2019 22:11:24 -0000

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

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

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.


[1] I would probably keep epochs at 4 bytes, because any more seems