fix(e2ee) update docs after dropping signatures

doc/e2ee.md

@@ -3,6 +3,7 @@
 ## Overview
 
 **NOTE** e2ee is work in progress.
+
 This document describes some of the high-level concepts and outlines the design.
 Please refer to the source code for details.
 
@@ -56,7 +57,7 @@ At a high level the encrypted frame format looks like this:
    +^+-------------------------------------------------------+ +
    | |                 Authentication Tag                    | |
    | +---------------------------------------+-+-+-+-+-+-+-+-+ |
-   | |    CTR... (length=LEN + 1)            |S|LEN  |KID    | |
+   | |    CTR... (length=LEN + 1)            |R|LEN  |KID    | |
    | +---------------------------------------+-+-+-+-+-+-+-+-+^|
    |                                                           |
    +----+Encrypted Portion            Authenticated Portion+---+
@@ -64,52 +65,12 @@ At a high level the encrypted frame format looks like this:
 
 We do not encrypt the first few bytes of the packet that form the
 [VP8 payload](https://tools.ietf.org/html/rfc6386#section-9.1) (10 bytes for key frames, 3 bytes for interframes) nor
-the [Opus TOC byte](https://tools.ietf.org/html/rfc6716#section-3.1)
+the [Opus TOC byte](https://tools.ietf.org/html/rfc6716#section-3.1).
+
 This allows the decoder to understand the frame a bit more and makes it decode the fun looking garbage we see in the
 video. This also means the SFU does not know (ideally) that the content is end-to-end encrypted and there are no
 changes in the SFU required at all.
 
-If the signature bit is set on the frame trailer, there is an additional fixed-length signature that is located
-between the counter and the trailing bit:
-```
-     +------------+------------------------------------------+^+
-     |unencrypted payload header (variable length)           | |
-   +^+------------+------------------------------------------+ |
-   | |                                                       | |
-   | |                                                       | |
-   | |                                                       | |
-   | |                                                       | |
-   | |                  Encrypted Frame                      | |
-   | |                                                       | |
-   | |                                                       | |
-   | |                                                       | |
-   | |                                                       | |
-   +^+-------------------------------------------------------+ +
-   | |                 Authentication Tag                    | |
-   | +---------------------------------------+-+-+-+-+-+-+-+-+ |
-   | |    CTR... (length=LEN + 1)            |  SIGNATURE    | |
-   | +---------------------------------------+-+-+-+-+-+-+-+-+ |
-   | |    SIGNATURE (fixed length)           |1|LEN  |KID    | |
-   | +---------------------------------------+-+-+-+-+-+-+-+-+^|
-   |                                                           |
-   +----+Encrypted Portion            Authenticated Portion+---+
-```
-
-The signature is generated as
-  Signature = Sign(signatureKey, Authentication Tag)
-and covers the current frame. Not every frame is signed but there will be periodic
-signatures on all SSRCs and streams. This prevents the impersonation attacks described in
-  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.4
-We currently sign every frame, despite the overhead this incurs.
-
-We currently use ECDSA with curve P-521 as described on
-  https://developer.mozilla.org/en-US/docs/Web/API/EcKeyGenParams
-and sign/verify with SHA-256:
-  https://developer.mozilla.org/en-US/docs/Web/API/EcdsaParams
-This results in a fixed length signature of 132 bytes.
-We plan to make these options negotiable by exchanging them along with the key as a JWK:
-  https://tools.ietf.org/html/rfc7517
-
 ### Using Web Workers
 
 Insertable Streams are transferable and can be sent from the main JavaScript context to a