From 1896fc7cdab7cbf5e653f84b650772e894e26485 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Mon, 12 Dec 2022 13:28:27 +0100 Subject: [PATCH] Remove encryption section as it's glossing over details MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Šimon Brandner --- proposals/3898-sfu.md | 28 +++------------------------- 1 file changed, 3 insertions(+), 25 deletions(-) diff --git a/proposals/3898-sfu.md b/proposals/3898-sfu.md index 2a63d3bb..4755f103 100644 --- a/proposals/3898-sfu.md +++ b/proposals/3898-sfu.md @@ -37,7 +37,7 @@ other participants are connected. If more users then join from London, however, will all make the same decision and connect to the New York focus rather than the optimal configuration of the London users connected to the London focus. With active and preferred foci, the second user that joins from London will know that although -Alice's active focus is Newe York, her preferred is London, and can therefore choose +Alice's active focus is New York, her preferred is London, and can therefore choose the London focus instead. For instance: @@ -307,6 +307,7 @@ implementation. Either send should hang up once deeming the other side unresponsive. focus -> client: + ```json { "type": "m.call.ping", @@ -315,6 +316,7 @@ focus -> client: ``` client -> focus: + ```json { "type": "m.call.pong", @@ -338,30 +340,6 @@ any). The client is responsible for doing this using the } ``` -### Encryption - -When SFUs are on the media path, they will necessarily terminate the SRTP -traffic from the peer, breaking E2EE. To address this, we apply an additional -end-to-end layer of encryption to the media using [WebRTC Encoded -Transform](https://github.com/w3c/webrtc-encoded-transform/blob/main/explainer.md) -(formerly Insertable Streams) via -[SFrame](https://datatracker.ietf.org/doc/draft-omara-sframe/). - -In order to provide PFS, The symmetric key used for these streams from a given -participating device is a megolm key. Unlike a normal megolm key, this is shared -via `m.room_key` over Olm to the devices participating in the conference -including an `m.call_id` and `m.room_id` field on the key to correlate it to the -conference traffic, rather than using the `session_id` event field to correlate -(given the encrypted traffic is SRTP rather than events, and we don't want to -have to send fake events from all senders every time the megolm session is -replaced). - -The megolm key is ratcheted forward for every SFrame, and shared with new -participants at the current index via `m.room_key` over Olm as per above. When -participants leave, a new megolm session is created and shared with all -participants over Olm. The new session is only used once all participants have -received it. - ### Notes #### Hiding behind foci