Subject: [Sframe] SFrame signatures

From: Justin Uberti <[email-masked]>
Date: Thu, 18 Mar 2021 15:15:46 -0700

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Mar 2021 21:28:20 -0600

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=[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe

---

From: Raphael Robert <[email-masked]>
Date: Fri, 19 Mar 2021 14:41:27 +0100

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 <[email-masked]> wrote:
> 
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 22 Mar 2021 10:24:11 +1100

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
> 
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 31 Mar 2021 11:28:37 +0200

On 18/03/2021 23:15, Justin Uberti wrote:
> signatures in your application and disagree with this direction, please 
> let us know by the end of next week (Friday, March 26).
> 
> Justin
> 

Sorry for the delay responding.

We do currently use signatures on Jitsi. We started by signing every 
frame and compromising on the overhead.

The next step (currently in PR) was to sign multiple frames. 
Specifically, all keyframes, first frame from a new SSRC, and frame on 
which we needed to racthet are signed.

I'll say I'm not happy with the complexity this introduces, and I agree 
the attack vector is weird (a user in a conference is using the key of 
another user in the conference).

FWIW, Zoom deems this attack vector out of scope:

"""
Second, there are certain classes of attack and threats that we deem out 
of scope, including:In-meeting  impersonation  attacks:A  malicious  but 
  otherwise  authorized  meetingparticipant colluding with a malicious 
server can masquerade as another authorizedmeeting participant.
"""

https://raw.githubusercontent.com/zoom/zoom-e2e-whitepaper/master/zoom_e2e.pdf 
- Section 1.3.

I find myself agreeing here.

I see the authentication section was removed in draft -02 and section 
8.1 was added, nice to see that's explicit now.

We'll most likely be removing signatures for the time being.

Cheers,

-- 
Saúl