Re: [Sframe] SFrame signatures

Martin Thomson <mt@lowentropy.net> Sun, 21 March 2021 23:24 UTC

Return-Path: <mt@lowentropy.net>
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 BE33B3A09E8 for <sframe@ietfa.amsl.com>; Sun, 21 Mar 2021 16:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=IuH91Wmf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ia7VAzs9
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 cb-XypnGbqP7 for <sframe@ietfa.amsl.com>; Sun, 21 Mar 2021 16:24:30 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664A83A09E7 for <sframe@ietf.org>; Sun, 21 Mar 2021 16:24:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5CE255C0094 for <sframe@ietf.org>; Sun, 21 Mar 2021 19:24:29 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 21 Mar 2021 19:24:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=LPb13 VGbRoA3ZF7giZDa+VKWD3AhAUWtz6ycgcgVqHQ=; b=IuH91Wmft7tIue8941OnC 2G+KOjY1Q4ojx8yNYBjpiPxzJ+AtHsy3knqnyHu6JDGdfGpz6hQmQyeZAKi/2By8 GZY/LRrH3A1oKhc3el+9sQAy7gIdW/9F/W/3Lzsp75Im1bR+uLJ4gdQt+JwCgIGo dPwMPmQ6ldgZnPH60cXybzV+/WAaj2IVnandQgPlj6Og3yqZEsZCsj9WGrEzT3KZ PD+ZVp5MdJCLL5r7h/SfMshRswCIfKBxhtTpt8TUUi7AzLKLhTub+aS57DPpPdHm LlzFgAO9kheXCP30knfaHhic1s2KSalJDX3p8+brqZ8b3cOrkGLDkQXWpR1FEqGy A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LPb13VGbRoA3ZF7giZDa+VKWD3AhAUWtz6ycgcgVq HQ=; b=Ia7VAzs96dNrzVQbsZR0QfcA4vowDmtcw1e/cmYXOEyQ7f8AUFI2tUejQ 1BbqzyY2xv4dHLWTWTu7P+EEww4JvSwCeJ17hQygTdfNeS8f2wpoXxcE+k9l8SJx EMjy05vI8vVkaa6VvtAkcv0t5HK9v8PjxfWtILfx4OOGnWwbByF+njS7Jdl9WhgH CcRKITIuK5OddnwkjpAA8s1a1NXFhP18pZoCo1doU1rip+zM4axWjAHT+W5nt1Dm mRsEJJ+4nrbSWdBHN9mEPo28223T2Aa89PLNmCv6cdFMJcj2nbm/DrC2BNr+f1UX SFOXwwGlYrCtRGAyaQzC9Efc3nNRw==
X-ME-Sender: <xms:rNVXYOxRSpWZ3MhZ7Lz8DuyJXkiAKIDqeT2T7B1a4I8SYpOkkEzyAg> <xme:rNVXYKQFxctXpq9UUTa1sYpPECspZsj8-Mkn8e-SLzCpMCwO41W9oGBQZB3LMRM5F 8fPJGy-txqPb1_nRCs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegfedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffetgfevvdfhtdffhe ejudefhffhveehudefhffgleelteeifeegfefggfelhefgnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:rNVXYAUXhSj4A_Y9wSa3PCDg6ReHfVNFwq1-XMp1gRXo-7VaU8q_NQ> <xmx:rNVXYEi32KbHYa-LWPDkiozOnKgSWRsVw2yCNXLNe1HVSNWcb-JAXg> <xmx:rNVXYAB-lGEAr3v8fK3jYyvBGUMntz2RMkURdzdef9uDlpn8hxVn6w> <xmx:rdVXYDOO4l5dW0HqZzHYZhFUGY_X-2cTFJtGL2yLSpzyoLz3QJTM0w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9DB4B4E05F8; Sun, 21 Mar 2021 19:24:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <38afa7f3-b94f-465d-8614-bf03f5584566@www.fastmail.com>
In-Reply-To: <46D405D0-F143-4C2F-A629-F87DFB6D33D6@wire.com>
References: <CAOJ7v-03Jt4w1PuSA-cTyM_GpD6rDFkz4US_Yw35YRHbikr3iA@mail.gmail.com> <CFA69D2C-7FBB-485E-8F3E-C021CB1F971D@iii.ca> <46D405D0-F143-4C2F-A629-F87DFB6D33D6@wire.com>
Date: Mon, 22 Mar 2021 10:24:11 +1100
From: Martin Thomson <mt@lowentropy.net>
To: sframe@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/4FZALqkG3yNz81usSe--cD5Wjbc>
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: Sun, 21 Mar 2021 23:24:36 -0000

This was one of the issues that came up when we first met.

One virtue of the draft not being adopted is that the team working on it is free to make the choice without our permission.  It is just a proposal.

I read the charter here as being flexible on this point.  We can decide whether signing is in scope or not.  Clearly there are advantages to signing.  Would those who want signing be OK with the answer being that it can be added later?

On Sat, Mar 20, 2021, at 00:41, Raphael Robert wrote:
> I for one disagree with just dropping the only mechanism that can 
> provide sender authentication without further discussion or an adequate 
> substitute. I’d also be interested to learn more about the specifics 
> here.
> 
> I am well aware of the complexity of the topic, given that a) 
> signatures and verifications are somewhat expensive and b) packets 
> might get dropped. Nevertheless — like Cullen said — there are 
> scenarios where signatures are important.
> 
> Raphael
> 
> 
> > On 19. Mar 2021, at 04:28, Cullen Jennings <fluffy@iii.ca> wrote:
> > 
> > 
> > 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
> > 
> > -- 
> > Sframe mailing list
> > Sframe@ietf.org
> > https://www.ietf.org/mailman/listinfo/sframe
> 
> -- 
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>