Remove encryption section as it's glossing over details

Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>

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