Re: [Sframe] charter feedback

Franziskus Kiefer <> Fri, 04 September 2020 12:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67B163A074B for <>; Fri, 4 Sep 2020 05:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 k54i2gWK6-X5 for <>; Fri, 4 Sep 2020 05:15:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58DB63A05DE for <>; Fri, 4 Sep 2020 05:15:50 -0700 (PDT)
Received: by with SMTP id a12so5830886eds.13 for <>; Fri, 04 Sep 2020 05:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O7O80SleAm1KWzRcTmF3bqD9AsLlHYofHv+XUe6P/z8=; b=uzfbqLG3fe0DlI97uDz8gd9HGLEEGhlVIqWPVMiKvJASzjVAHXA/Pr58PvnxAHtis6 54Etca/8hONnqkRWRHOxGmJL0kD01zA0NYHRYhCAHvJPRwwcNU/e515ICDM3lyyABXUt Bmg9IhjZWr92BYTO4K2n3gDf6ExHQ8mbsyL51FT0/VoAehiNN9bgIsLI3NuaCyeTWS2n wIGfgg5gDF05ap1Tyk58J2+j/k5fpl/LAhLFSAf6ZKjsmnIzzeK/tS3qeHl+6rLRKzt/ ueSQocIATI4SeQsfgOZqyzJLmY8e/8K8n3gqVN7jh2UE9HHxpUznzbb+hUYW3hj78bhr 60Ww==
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=O7O80SleAm1KWzRcTmF3bqD9AsLlHYofHv+XUe6P/z8=; b=AXl+SNP/7NI0Wmkja2MzTUunkP3ry0IwtL4dyzQzzhplweHaMxJWZtFj0JHr05CEOe R/bFP7KtdB7yKuCeYNXRMMphna4KoJYuv4ThS3YQjT5MsuqMgpt57HMhIw4+S4xfv/21 Mm+7D9kvuviCfOSgfJ0JUu1H8kCLNCOm2WdUCZFvB6aLUgWL3mnb0hD0O+nTVMsnkonA PXVItf+qClr8RBaj8f7EnLrO/IcccAfvtBENSYd3GzUYxX7RhqiYwzL7vDi5I1nl0Hi0 DIqcSvGapX5k37BRFAzbmFqu+DIMUhcAKzMZ5aLpmUiphZGx7MSo3rif7+sAm5o0x7Iz AxqQ==
X-Gm-Message-State: AOAM533wlaiKZ1qpb/lewW1iZIpcm+7WtBo7JjkOawh+c0l+hGwa8mIO a3leLOdJs9cNurRYO6PfvIc4w+PgBPs/2XFBXXZLsdXE5Fw=
X-Google-Smtp-Source: ABdhPJxKseflOl2ltJmQktyDaHrMfIkehh8ydJPj21S30ENMTfuUvj4RqWg+cVIT9VtaBoYyaxpE0HBofZ3vJt8MuQg=
X-Received: by 2002:a05:6402:184d:: with SMTP id v13mr8392674edy.240.1599221748735; Fri, 04 Sep 2020 05:15:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Franziskus Kiefer <>
Date: Fri, 4 Sep 2020 14:15:37 +0200
Message-ID: <>
To: Alexandre GOUAILLARD <>
Content-Type: multipart/alternative; boundary="0000000000004021a605ae7bd49c"
Archived-At: <>
Subject: Re: [Sframe] charter feedback
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Sep 2020 12:15:52 -0000

Hi Alexandre,

thanks for the response.
I totally agree that the charter shouldn't restrict the use cases here.
Conferencing was really meant as an example (bad phrasing on my side,
though it's of course an important use case for us).
But the charter can set out the process taken by the WG. And all use cases
here should profit from this (i.e. making sure that the threat modeling and
solution for each use case are vetted by other parties, in particular

> Right now, emad is working on the conferencing use case with sergio, and
you might want to liaise with them on that specific topic. One document
about how SFrame can be used with RTP, and, seprately, with MLS including
the corresponding threat model is in progress. I think this is what you are
looking for.

I currently only know about Is there any
other draft in progress?


On Fri, 4 Sep 2020 at 13:23, Alexandre GOUAILLARD <> wrote:

> Hi franz.,
> Thank you for your interest and the kind words.
> "Conferencing" is certainly a topic of interest, and i understand the
> focus of wire. SFrame can certainly be used in that context.
> However, there are other use cases than conferencing where media
> encryption is of interest, including but not limited to
> streaming/broadcasting and then of course all the hybrid use cases we start
> seeing emerging (watch parties, webinars, ....).
> We designed SFrame itself to refer ONLY to the media encryption part, and
> be as much as possible media transport agnostic, and use case/threat
> model/trust model agnostic, where the precedent attempt was extremely
> focussed on RTP-based conferencing.
> Eventually, each use case (e.g. conferencing) should have
> additional documents to come up to a full system whose properties could be
> verified, but we did not want to restrict the charter to a single use case.
> Right now, emad is working on the conferencing use case with sergio, and
> you might want to liaise with them on that specific topic. One document
> about how SFrame can be used with RTP, and, seprately, with MLS including
> the corresponding threat model is in progress. I think this is what you are
> looking for.
> In parallel, work is being done on application to SFrame for
> streaming/broadcasting and how it relates/overlaps with existing DRM
> solutions today in the bigger context. This will also hopefully have its
> own set of document. EVentually all would have the media encryption,
> SFrame, in common.
> Hope this helps.
> On Fri, Sep 4, 2020 at 6:23 PM Franziskus Kiefer <
>> wrote:
>> Hi all,
>> First, thanks for working on this.
>> Wire is currently considering sframe for some use cases.
>> Looking at the charter I noticed two things:
>> The charter currently doesn't talk about authentication and to which
>> extent the WG wants to look at it. While authenticity might be implicit
>> through the used keys the sframe draft currently also uses signatures.
>> I'm missing a statement about the process followed by the WG. End-to-end
>> encrypted conferencing is a relatively new topic without much research
>> around threat models. I therefore think that a process that validates the
>> threat model and the proposed solution is warranted. This might not have
>> the same extent as for TLS or MLS, but would still be good to have.
>> Cheers,
>> Franziskus
>> --
>> Sframe mailing list