Re: [Sframe] SFrame signatures

Cullen Jennings <fluffy@iii.ca> Fri, 19 March 2021 03:28 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C8F3A0D93 for <sframe@ietfa.amsl.com>; Thu, 18 Mar 2021 20:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSPzaq0Jmu1p for <sframe@ietfa.amsl.com>; Thu, 18 Mar 2021 20:28:23 -0700 (PDT)
Received: from smtp87.ord1c.emailsrvr.com (smtp87.ord1c.emailsrvr.com [108.166.43.87]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F9E3A0D95 for <Sframe@ietf.org>; Thu, 18 Mar 2021 20:28:23 -0700 (PDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 12D98A00D1; Thu, 18 Mar 2021 23:28:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAOJ7v-03Jt4w1PuSA-cTyM_GpD6rDFkz4US_Yw35YRHbikr3iA@mail.gmail.com>
Date: Thu, 18 Mar 2021 21:28:20 -0600
Cc: Sframe@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFA69D2C-7FBB-485E-8F3E-C021CB1F971D@iii.ca>
References: <CAOJ7v-03Jt4w1PuSA-cTyM_GpD6rDFkz4US_Yw35YRHbikr3iA@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Classification-ID: 3850e70b-5b0d-4322-b233-5f634c8a7f28-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/zOvZulAvsVTqaz22KKrUbViV81Q>
Subject: Re: [Sframe] SFrame signatures
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, 19 Mar 2021 03:28:27 -0000

Could you say a bit more about the issue is with signing?  I wonder how much the issue is the complexity of trying to get teh bandwidth savings of signing across multiple frames vs just doing a single frame. 

There are a few uses  that is think is fairly common which drive the need for something like signing. Imagine you have a bot listening to the call to do real time transcription and translation of the call. It would be nice to give that bot read access to the media but not write access to contribute media. If the media is signed, this is fairly easy to do by blocking the bots ability to contribute to the mix but it is not clear how to do this without something like signing. 


> On Mar 18, 2021, at 4:15 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org> wrote:
> 
> In recent discussions regarding signatures for SFrame we have questioned the usefulness of this feature and considered removing it. Upon looking closer into the details here, we have also determined more work would be required to properly specify it.
> 
> Given this, the authoring team would like to officially propose removing the signature feature from the specification. If you are using SFrame signatures in your application and disagree with this direction, please let us know by the end of next week (Friday, March 26).
> 
> Justin
> -- 
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe