Subject: [Sframe] Request session at IETF 108 dispatch

From: Emad Omara <[email-masked]>
Date: Mon, 15 Jun 2020 10:32:29 -0700

Hi,

We would like to have a session in the next IETF to discuss the SFrame draft
<https://tools.ietf.org/html/draft-omara-sframe-00> Can you please help
scheduling this?

Thanks
Emad

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Jun 2020 13:02:31 -0500

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.

Thanks!

Ben.

> On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=[email-masked]> wrote:
> 
> Hi,
> 
> We would like to have a session in the next IETF to discuss the SFrame draft <https://tools.ietf.org/html/draft-omara-sframe-00> Can you please help scheduling this?
> 
> Thanks
> Emad
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Emad Omara <[email-masked]>
Date: Mon, 15 Jun 2020 11:33:07 -0700

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.

Thanks
Emad

On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <[email-masked]> 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.
>
> Thanks!
>
> Ben.
>
> On Jun 15, 2020, at 12:32 PM, Emad Omara <
> emadomara=[email-masked]> wrote:
>
> Hi,
>
> We would like to have a session in the next IETF to discuss the SFrame
> draft <https://tools.ietf.org/html/draft-omara-sframe-00> Can you please
> help scheduling this?
>
> Thanks
> Emad

---

From: Patrick McManus <[email-masked]>
Date: Mon, 15 Jun 2020 14:42:58 -0400

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 15 Jun 2020 15:05:47 -0400

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
https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it).

There's also a github and mailing list referenced:
https://github.com/eomara/sframe
https://mailarchive.ietf.org/arch/browse/sframe/?

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

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <[email-masked]>
wrote:

>>> draft <https://tools.ietf.org/html/draft-omara-sframe-00> Can you
>>> please help scheduling this?
>>>
>>> Thanks
>>> Emad

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Jun 2020 14:13:02 -0500

Thanks, Patrick.

Authors: It would be helpful to get a little more background: 

- How does this work relate to PERC? What problem does it solve that PERC doesn’t?
- Do you expect this to become an IETF standard available to anyone to implement? Who do you think would implement it? 
- Is anyone outside of Google working on the spec or implementing the protocol? Has anyone outside of Google expressed interest in doing so?
- Anything else you think would help motivate people to read the draft and give feedback :-)

Thanks!

Ben.

> On Jun 15, 2020, at 2:05 PM, Patrick McManus <[email-masked]> wrote:
> 
> 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 https://tools.ietf.org/html/draft-omara-sframe-00 <https://tools.ietf.org/html/draft-omara-sframe-00> if you too missed it).
> 
> https://github.com/eomara/sframe <https://github.com/eomara/sframe>
> https://mailarchive.ietf.org/arch/browse/sframe/? <https://mailarchive.ietf.org/arch/browse/sframe/?>
> 
> On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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. 
> 
> Thanks
> Emad
> 
> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Emad,
> 
>> On Jun 15, 2020, at 12:32 PM, Emad Omara <emadomara=[email-masked] <mailto:emadomara=[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>

---

From: Emad Omara <[email-masked]>
Date: Mon, 15 Jun 2020 12:20:29 -0700

Thanks.

Some responses inline. Other authors please feel free to add more.

Emad

> - How does this work relate to PERC? What problem does it solve that PERC
This is a completely different approach than PERC. THis draft aims for
simplicity and efficiency. The sdrame draft itself has some benchmarks
against the PERC approach.  That being said the sframe draft focuses mainly
on the media encryption part and touches slightly other parts in the system
like key management and integration with WebRTC. If this became a standard
we will have to write a separate draft for each of these two topics.

> - Do you expect this to become an IETF standard available to anyone to
> implement? Who do you think would implement it?
>
Yes. This will be implemented by the  video conference providers. The core
protocol implementation is on the client side.

> - Is anyone outside of Google working on the spec or implementing the
> protocol? Has anyone outside of Google expressed interest in doing so?
>
Yes, the document is co-authored by +Sergio murillo
<[email-masked]> & +Alexandre GOUAILLARD
<[email-masked]> from Cosmos Software.

> On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <
> [email-masked]> wrote:
>
>>> 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.
>>>
>>> Thanks
>>> Emad
>>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 15 Jun 2020 15:29:11 -0400

To address the related work point:

You're correct that PERC is the main touch point, MLS less so; also RTCWeb
if that were still going on.  Very directly, this work is doing basically
the same thing as PERC double encryption (RFC 8723).  The key difference is
decoupling between the hop-by-hop and end-to-end security contexts.  In
PERC, the E2E context uses some information from the HBH SRTP packet.  So
the fields used by the E2E context have to be unmodified, well, end to end,
so that a clean media path is a prerequisite for E2E.  (Where "clean" means
"don't modify" or "modify in accordance with PERC")  This dependency makes
it much harder to deploy E2E in practices.  In addition, once the E2E layer
is decoupled from the HBH layer, it is much easier to transmit it over
alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or
RIPT.

FWIW, if I were to suggest a DISPATCH outcome, a focused WG seems like the
right level of attention to me.  The topic is worth working on and would
benefit from an IETF-consensus specification, but the document isn't yet
mature enough for AD sponsorship.

--Richard

On Mon, Jun 15, 2020 at 2:43 PM Patrick McManus <[email-masked]>
wrote:

> with a link to the draft would be helpful in getting the process started...
>
>>> --
> Sframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sframe
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 15 Jun 2020 15:30:12 -0400

> <[email-masked]> from Cosmos Software.

On this last point: We are considering this for some projects at Cisco.

--Richard

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 15 Jun 2020 22:10:03 +0200

> protocol? Has anyone outside of Google expressed interest in doing so?

Cosmo has co-authored the spec and we have released an open source pure 
javascript implementation based on webcrypto 
(https://github.com/medooze/sframe) and using with w3c insertable 
streams (https://github.com/w3c/webrtc-insertable-streams)

It is already integrated in Medooze products:

https://medium.com/@medooze/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d

And in Janus:

https://www.meetecho.com/blog/janus-e2ee-sframe/

Best regards

Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 15 Jun 2020 22:13:00 +0200

And in Janus:

Best regards

Sergio

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Mon, 15 Jun 2020 22:21:22 +0200

With respect to PERC,
SFrame is media transport agnostic, and would work with QUIC, while PERC is
Rtp-Based only.Conferencing only, and assume e.g. SRTP.

On Mon, Jun 15, 2020 at 10:13 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> javascript implementation based on webcrypto (
> https://github.com/medooze/sframe) and using with w3c insertable streams (
> https://github.com/w3c/webrtc-insertable-streams)
>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 26 Jun 2020 11:17:51 +0300

Hi,

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 [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Monday, June 15, 2020 10:06 PM
To: Emad Omara
Cc: Ben Campbell; Dispatch WG; [email-masked]
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 https://tools.ietf.org/html/draft-omara-sframe-00 if you too missed it).

On Mon, Jun 15, 2020 at 2:42 PM Patrick McManus <[email-masked]> wrote:

Hi Ben,

Thanks

Emad

Hi Emad,

Thanks!

Ben.

Hi,

Thanks

Emad

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Fri, 26 Jun 2020 13:05:19 +0200

Hi roni,

Those are great points.

With respect to EKT, we believe that just like double and EKT were two
separate matters even though there were both needed to get a complete
system to work, media encryption (SFrame) and key distribution should be
separated. One of the argument in favor of separation is that while media
encryption will likely be the same in nature whether you do video
conferencing, or streaming, or other media use cases, the trust /
threat model can be vastly different, and thus require different key
exchange mechanisms.

With respect to RTP, and I believe emad is working on writing a draft as we
speak.

regards,

On Fri, Jun 26, 2020 at 10:18 AM Roni Even <[email-masked]> wrote:

> Hi,
>
>
>
> 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 [mailto:[email-masked]] *On Behalf Of *Patrick
> McManus
> *Sent:* Monday, June 15, 2020 10:06 PM
> *To:* Emad Omara
> *Cc:* Ben Campbell; Dispatch WG; [email-masked]
> *Subject:* [dispatch] Dispatch of SFrame for End-To-End Encrypted
> Conference Calls
>
>
>
> Hi All -
>