[Sframe] To tree or not to tree?

Richard Barnes <rlb@ipv.sx> Fri, 20 November 2020 15:17 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A21C3A0C63 for <sframe@ietfa.amsl.com>; Fri, 20 Nov 2020 07:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 wRbTnzuFnj27 for <sframe@ietfa.amsl.com>; Fri, 20 Nov 2020 07:17:27 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 D60C73A0C62 for <sframe@ietf.org>; Fri, 20 Nov 2020 07:17:26 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id 7so7327163qtp.1 for <sframe@ietf.org>; Fri, 20 Nov 2020 07:17:26 -0800 (PST)
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=qXvz8x6sxfSGTq3t8TlGeYF5nWzCZg2XCNOHq6BAUlg=; b=B7s/lSZRrSep2ftsY05fhgW5PrswGfYEk1YwoCKxSymx6EMsm9fPtRZychCaf8muFL oaFC5z3dirg8M0gmc7Y+SbsZagGFZ4ByFa+y1b173ehwXwcJpEN7QTZwVuTwo8j8r/Em /H9kZc5hO1AVtB2FjKbbbhNUlohYJEkRHvZzo85bPj/5YULt/3y9vyKzKit+IzH1Zk3h KEYBLrtcTFUJl0wC58l/Oazpr+6x9YAxct+2vIaBpuaWUW8+4pgkDS0u/jWvk/hZ9CSQ AaNr/ct7+C31OsG98AOAkoh3Ylgz1dHY5zR2k8hBvthNht2DEN5KL2tz2VdpFPJbpX60 4zfg==
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=qXvz8x6sxfSGTq3t8TlGeYF5nWzCZg2XCNOHq6BAUlg=; b=ACEzSqFvey+Kjs68YNkBdyO44mF85b0wJ/6IXutL8h023QE5/19VniqaIgeJHCeJeb xsTXsX7v5ZATX1dwjNqEGHxtbKeVH8IEnWbJKSiKtvOZtFSMu3j9/13uXSxR7N4R5COY 9RhBW5PVObQRHvfsOUMob8Kfbj/lkguOwatt668VAwXHm94+mO6h0H+kE2YH4kFpHNJX K3nTuTWo1BJ7gVlhwjI2pyZNXjkdcgdR4CqA8aYHRJwo7WXXi/fVOr8uOLiKCUEJpFgL lqX3AS6ZjgBmYLjQO0l/TdmVC5D0DMjxdffe1/IEGfIAwIHglokKH+Ervv3YaiGxZE3X QlbQ==
X-Gm-Message-State: AOAM5333aN+J7A0PTrvuzhVHxXaD/hMmTZ6AQ7Z94bP/i2AC2tb+uiHZ 1BgmPZ0+RaZOaoIdJoiy+f4APiTtW0RUgAonWfiVlBfAFTEmUA==
X-Google-Smtp-Source: ABdhPJxQpamClVs5jyZm6qg6TbDgmZ1S7PmeO56ZWc8UepOR0JosuGAxdVmyj87kuQa75L25qJYMh79eTU+/VK7+88A=
X-Received: by 2002:aed:2661:: with SMTP id z88mr12651565qtc.265.1605885445050; Fri, 20 Nov 2020 07:17:25 -0800 (PST)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 20 Nov 2020 10:17:11 -0500
Message-ID: <CAL02cgSXhEdZPozPaq26QHFeHEcTcvEbUqYvo58S=DfC3uYsew@mail.gmail.com>
To: sframe@ietf.org
Content-Type: multipart/alternative; boundary="00000000000080add205b48b57fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/vuP9uD1llmEUTx7R0Y58SJXnXZw>
Subject: [Sframe] To tree or not to tree?
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2020 15:17:28 -0000

Hi all,

One point that was raised during the SFrame meeting at IETF 109 was whether
the MLS-SFrame integration should re-use the MLS "secret tree" structure.

For those who might not be deep in MLS, the secret tree provides forward
secrecy for MLS messages sent within an epoch, without the need to generate
base keys for all participants [1].  In other words, if you have a group
where (a) only a few participants are speaking and (b) they ratchet their
key after each message, then the secret tree assures that compromise of any
group member with current state won't leak the keys for messages that have
already been sent/received.

Let's consider three possible integrations:

1. SFrame uses the same secret tree as MLS (export at the leaves)
2. SFrame exports a single secret, then makes its own secret tree
3. SFrame exports a single secret, then uses a simpler scheme (like the
current one)

I would posit that (1) is not workable.  That requires a tight coupling
between the MLS and SFrame stacks, which will often not be tractable, e.g.,
in situations where the media logic is in a separate thread or process from
the MLS logic.

(2) only adds value over (3) if SFrame senders ratchet their keys.
Otherwise, there's no forward secrecy boundary; criterion (b) above doesn't
apply.  The current MLS-SFrame document has no provision for ratcheting
within an epoch.  We could do it, but it would require more bits of header
to send a "generation" as MLS does, to indicate how many times you've
ratcheted.  It also seems like situations where you have mostly silent
participants are more rare in real-time cases than in messaging cases.

So my preference would still be for (3), largely because intra-epoch
forward secrecy seems like a pretty secondary consideration here.  If
intra-epoch forward secrecy is a problem people want to solve, then we
should do ratcheting, and we should do the secret tree.