Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls

Roni Even <> Fri, 26 June 2020 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36EE33A11E7; Fri, 26 Jun 2020 01:18:00 -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 oDSyfv5eM7IR; Fri, 26 Jun 2020 01:17:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D2E53A11E5; Fri, 26 Jun 2020 01:17:58 -0700 (PDT)
Received: by with SMTP id 22so7986239wmg.1; Fri, 26 Jun 2020 01:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=rSbkZMN2q+6xCKLSAm5APx6fQvhwkvqcUyio578CjQbZM3MKJTpCzuwYHF4aLyIqhz qicuxD/Trfy9DD4f9U915Vg9UuKPJywuoI/CaqWAh8tr+0hsbWmlnLQ3Ut6lBOxjiQvK hMDqgXCwZ8fJkzf6AO4Ewcq6SLlYTbh4TNWbsenrwMNVabBux+ViboZcbMqQJ9Uu4Yg6 q7nGCMsEsxIWR3dLgZX7ZN108UyGWreJD4ix6/CkP8DVS5/g7j8KLfZ/8fwj49m4gwoI NoPxnyIeUPZA2H74V+hh6mAljL7BA9K9KL6f5A7vwhogpm1bj0LM7vaal3KAXj4TgJpV 7bUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=ejA36kwyyKDA5CQeNHVvIwfcfNCHK2A3qlZGlH62xuE=; b=Fqp/6ZwOM89ysxhH3K81gKdt25NQHLUOrQVXT55J1h2RTbaVrSX8v2FquQSEXrikTp JBIfnyoku+vQz0UJOqVG80mRqPt8qZHL9CQfQP2qNiQ3hF84ElYDS0pRyi6QvWzBAoah 4UiVfaETVG3/YWoqCfxXB491wCYUHIZcozF1Y1x/jNh/t/FqWL5TFcJUdMUOWVDLDCVO QM/0i5jc+hfANQC4ImgsAoK/IjHDwKr/pDDdyehm9IHYTLH4csSKAR5jlIF3O9eWwpEw 5upLHBOKf27HCfiqSED7FFvn7OUrLZ9lXIeyKzE4t99HqLt8uC/EBDGUEUibMfmqPx0N bBDw==
X-Gm-Message-State: AOAM530sKRY57t2xAyH7Axp3qNU/FGnl/qYfR9uy7xN1j9nLk8VLWdQD Vv1AYCneoF6MNJHO2oB6QEoAZGbz
X-Google-Smtp-Source: ABdhPJxm0Y3jGON/FnVmDe/GNXdK4/d4BN2hobAlspfTOrjIudjyQfkIzelEk2v527f+cJr3ZLoOqQ==
X-Received: by 2002:a1c:7d54:: with SMTP id y81mr2206571wmc.110.1593159476459; Fri, 26 Jun 2020 01:17:56 -0700 (PDT)
Received: from RoniPC ( []) by with ESMTPSA id h12sm15522218wmm.42.2020. (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 26 Jun 2020 01:17:55 -0700 (PDT)
From: "Roni Even" <>
To: "'Patrick McManus'" <>, "'Emad Omara'" <>
Cc: "'Ben Campbell'" <>, "'Dispatch WG'" <>, <>
References: <> <> <> <> <>
In-Reply-To: <>
Date: Fri, 26 Jun 2020 11:17:51 +0300
Message-ID: <0e4d01d64b92$49cf5040$dd6df0c0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E4E_01D64BAB.6F1DC0C0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: he
Thread-Index: AQH9xWGrhZcH8B5JF584hFypOrcytwNgTgg2AiD2rEYCDEUinwIlhVpuqE4AxRA=
Archived-At: <>
Subject: Re: [Sframe] [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls
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, 26 Jun 2020 08:18:00 -0000



I find this proposal interesting since the issue of key distribution in multipoint conferences is a problem even if the media mixer (any topology) is a trusted entity and wants to distribute the encrypted media without doing decrypt/encrypt cycle.  One point to look at is that in the past when we designed RFC5764 (DTLS/SRTP) the consensus was that key exchange must be done in-band. 

As far as I remember one of the motivation point for EKT in AVT was to address the key distribution for multipoint conferences. 


As for the work, if there is a consensus to accept this work, it will require support for RTP. How to signal that this is such a payload and what should be the RTP PT in the RTP header. (how to negotiate what is the secure payload inside the SFRAME)

On one hand it may look like a new RTP payload (similar to MPEG2 RTP payload (RFC2250)) and as such is in scope for AVTCore but as for the framework I think this is not AVTCore work.


Roni Even

AVTCore co-chair




From: dispatch [] On Behalf Of Patrick McManus
Sent: Monday, June 15, 2020 10:06 PM
To: Emad Omara
Cc: Ben Campbell; Dispatch WG;
Subject: [dispatch] Dispatch of SFrame for End-To-End Encrypted Conference Calls


Hi All -

I failed to note the link highlighting in Emad's mail to the list which already contained the draft. Sorry about that. (It's if you too missed it).

There's also a github and mailing list referenced:


[I've also forked the Subject Line to help interested readers]


On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <> wrote:

Sounds really interesting Emad and there's obviously related work going on (at least perc, maybe even mls..).


Sending that email Ben mentions to the dispatch list to raise awareness with a link to the draft would be helpful in getting the process started..


On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <> wrote:

Hi Ben,


This draft proposes a solution for end-to-end encrypted conference calls. We implemented this in Google a couple of years ago in Duo, but the draft was only published last month given the current interest in the topic.


The goal of the session is to go through the proposal and see if there is interest to continue working on this, and if so what will be the best WG to host this work. 





On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <> wrote:

Hi Emad,


We prioritize DISPATCH meeting time to focus on topics that have had DISPATCH list discussion and need high-bandwidth time to resolve. Unless I’ve missed something, this topic has not previously come up in DISPATCH. I suggest sending a note to this list with some background about the draft and how you would like to see it progress.





On Jun 15, 2020, at 12:32 PM, Emad Omara <> wrote:




We would like to have a session in the next IETF to discuss the SFrame draft <>  Can you please help scheduling this?




dispatch mailing list