Subject: Re: [dispatch] [Sframe] Dispatch of SFrame

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Jun 2020 21:48:09 -0700

Dr. Alexandre Gouailard said:

"With respect to PERC, SFrame is media transport agnostic, and would work
with QUIC, while PERC is RTP-based only.  Conferencing only, and assumes
SRTP."

[BA] Compared with PERC, SFrame is more efficient and transport agnostic,
more compatible with existing codec-independent SFUs, and more flexible in
terms of the scenarios it can potentially support.

The efficiency point is important for large scale deployments where even a
few percent savings in overhead or CPU consumption can translate to savings
of millions of dollars in bandwidth, hardware, etc.

Transport independence is inherent to the Web architecture, which via Media
Source Extensions (MSE) enables media to be transported and rendered via
any transport. This includes the WebRTC data channel (used by game
streaming services such as parsec) and QuicTransport (now in Origin Trial)
as well as today's more common http/https-based streaming mechanisms.
While MSE requires the media to be containerized, the WebCodecs API aims to
remove this restriction. Since only RTP utilizes SRTP, a transport
independent solution cannot be tied to SRTP as PERC double is.

Seamless integration with SFUs is also a major advantage. Assuming that the
SFU is already codec agnostic (e.g. uses framemarking or the dependency
descriptor to forward), very little code (or none) needs to be changed
within the SFU, which can continue to do things such as SSRC translation
that are prohibited in PERC.  In addition, SFrame does not require that the
SFU make any modifications to its robustness code (RTX, FEC or RED).
Incompatibility with existing SFUs (and RTP implementations in general) was
one of the major objections to PERC pointed out in IETF last call.  For
this reason alone, PERC will never be widely deployed.

Finally, SFrame is not tied to a key management scheme, which allows it to
be potentially adapted for use in scenarios which may have quite different
threat models.  This may include 1-1 calls, conference calls, partially or
fully anonymous meetings (where some media streams may not be available to
some participants), and "protected meetings" (where the recordings are
protected from modification).  Several commenters in IETF last call pointed
out scenarios in which the PERC threat model was insufficient (e.g. PERC
allows participants to impersonate each other).

In addition, the lack of a key management tie-in in SFrame allows for
multiple deployment models, where components of the system may be
integrated within the client, or deployed in an on-premise or cloud server,
or some hybrid of these.

In short, SFrame is simultaneously more efficient, more flexible, more
compatible and more deployable than PERC.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jun 2020 06:01:33 -0700

> allows participants to impersonate each other).

Note that this is also true of SFrame. It's a property of using MACs rather
than signatures. Yes, I know one could add signatures to SFrame, but then
one could have added that to PERC as well.

-Ekr

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 16 Jun 2020 15:44:45 +0200

Hi Eric,

 Sframe already support signatures as well. It is also implemented on my js
library.

Best regards
Sergio

El mar., 16 jun. 2020 15:03, Eric Rescorla <[email-masked]> escribió:

>
>
> On Mon, Jun 15, 2020 at 9:48 PM Bernard Aboba <bernard.aboba@gmail..com
> <[email-masked]>> wrote:
>
>>
>> Finally, SFrame is not tied to a key management scheme, which allows it
>> to be potentially adapted for use in scenarios which may have quite
>> different threat models.  This may include 1-1 calls, conference calls,
>> partially or fully anonymous meetings (where some media streams may not be
>> available to some participants), and "protected meetings" (where the
>> recordings are protected from modification).  Several commenters in IETF
>> last call pointed out scenarios in which the PERC threat model was
>> insufficient (e.g. PERC allows participants to impersonate each other).
>>
>
> Note that this is also true of SFrame. It's a property of using MACs
> rather than signatures. Yes, I know one could add signatures to SFrame, but
> then one could have added that to PERC as well.
>
> -Ekr
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jun 2020 06:53:08 -0700

On Tue, Jun 16, 2020 at 6:44 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> Hi Eric,
>
>  Sframe already support signatures as well. It is also implemented on my
> js library.
>

Yes, I understand that the wire encoding supports signatures, but in the
discussions I've had (including with Emac) I don't think that people
believe that the latency/bandwidth/computation tradeoff is viable.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jun 2020 07:27:23 -0700

On Jun 16, 2020, at 6:53 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Yes, I understand that the wire encoding supports signatures, but in the discussions I've had (including with Emac) I don't think that people believe that the latency/bandwidth/computation tradeoff is viable.

[BA] Depends on the scenario.  We are in a pandemic where conferences are being used for all kinds of things that we haven’t seen before. For example, consider a situation in which participants are answering a binding poll and the responses (voice or data) need to be authenticated. SFrame can handle that. PERC cannot.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 16 Jun 2020 16:34:56 +0200

El mar., 16 jun. 2020 16:27, Bernard Aboba <[email-masked]>
escribió:

> [BA] Depends on the scenario.  We are in a pandemic where conferences are
> being used for all kinds of things that we haven’t seen before. For
> example, consider a situation in which participants are answering a binding
> poll and the responses (voice or data) need to be authenticated. SFrame can
> handle that. PERC cannot.

The good thing is, as I said before, I have already implemented it in my js
lib. I will add some stats and run some tests with different policies and
provide feedback about added overhead and encryption times.

Anyway, as Bernard says, it is a trade off, and some people may be willing
to pay for it based on their use case.

Best regards
Sergio

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Jun 2020 07:52:27 -0700

> handle that. PERC cannot.

I don't really think framing this as "PERC vs. SFrame" is that helpful, but
there's no in principle reason PERC couldn't have signatures, though of
course one would need to define new algorithms.

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Jun 2020 12:10:54 +1000

On Tue, Jun 16, 2020, at 14:48, Bernard Aboba wrote:
> [BA] Compared with PERC, SFrame is more efficient and transport 
> agnostic, more compatible with existing codec-independent SFUs, and 
> more flexible in terms of the scenarios it can potentially support.

I think that a more relevant comparison point would be between giving someone an COSE (analogous to SFrame) vs. TLS (analogous to PERC).  Sure, COSE has the ability to do more than an AEAD, but it also does far less.

I'm not really sure why people feel the need to dump on PERC.  It's fairly clear that it hasn't been successful, but that's just what happens with these things sometimes.

I see SFrame as an attempt to approach this problem more incrementally. That's fine.  Maybe this effort will result in adoption, which is what I care about.

While I might be less than thrilled with yet another cryptographic protection scheme, especially one with a custom AEAD and 32-bit authentication tags, those are details that a working group - in the security area - seems pretty well equipped to handle.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 16 Jun 2020 22:25:17 -0400

I imagine that for high-bitrate traffic, the difference between encrypting
every packet and encrypting an entire frame at once is substantial enough
to make using asymmetric crypto feasible in practice.

On Tue, Jun 16, 2020 at 10:53 AM Eric Rescorla <[email-masked]> wrote:

>
>
> On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba <bernard.aboba@gmail..com
>> > Yes, I understand that the wire encoding supports signatures, but in
>> the discussions I've had (including with Emac) I don't think that people
> I don't really think framing this as "PERC vs. SFrame" is that helpful,
> but there's no in principle reason PERC couldn't have signatures, though of

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jun 2020 20:44:37 -0700

For a key frame, SFrame can reduce the overhead of non-repudiation by two orders of magnitude. 

> On Jun 16, 2020, at 19:25, Victor Vasiliev <[email-masked]> wrote:
> 
> I imagine that for high-bitrate traffic, the difference between encrypting every packet and encrypting an entire frame at once is substantial enough to make using asymmetric crypto feasible in practice.
> 
>>> On Tue, Jun 16, 2020 at 7:27 AM Bernard Aboba <bernard.aboba@gmail..com> wrote:
>> I don't really think framing this as "PERC vs. SFrame" is that helpful, but there's no in principle reason PERC couldn't have signatures, though of course one would need to define new algorithms.
>> 
>> -Ekr
>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jun 2020 06:19:50 -0700

> to make using asymmetric crypto feasible in practice.

A few points:

1. The current SFrame draft does not in fact sign every frame. Rather it
signs the past N frames (
https://tools.ietf.org/html/draft-omara-sframe-00#section-4.4) "Adding a
digital signature to each encrypted frame will be an overkill, instead we
propose adding signature over multiple frames."
2. This is maybe sorta true for video in which the frames are large (though
see below) but remember that audio frames are small and have to have low
latency.
3. For video, it's true that I-Frames are enormous but the bulk of the
frames are P-Frames and those would generally be on the order of 1 packet,
at which point you're not getting much improvement.

IOW, it's complicated, but if you're not a fan of the "sign every packet"
strategy, you probably are going to find that "sign every frame" doesn't
work super well either.

-Ekr

>>> [BA] Depends on the scenario.  We are in a pandemic where conferences
>>> are being used for all kinds of things that we haven’t seen before. For