Code change:
extra cost. Adding a digital signature to each encrypted frame will be an <del> overkill, instead we propose adding signature over N frames. Because some frames could be lost and never delivered, when the signature is sent, it will also send all the hashes it used to calculate the signature, and the recipient client will only use these hashes if they didn't receive the matching frame.  For example Client A sends a signature every 5 frames, so it sends the signature and Hash(Frame1), ...,Hash(Frame5), client B received only frames 1,2,4 and 5.  When B receives the signature and the hashes, it will compute the hashes of frames 1,2,4 and 5 locally and use the received Hash(Frame3) to verify the signature.  It is up to the application to decide what to do when signature verification fails. The signature keys are exchanged out of band along the secret keys. </del> <ins> overkill, instead we propose adding signature over multiple frames. The signature is calculated by contatenating the authentication tags of the frames that the sender wants to authenticate (in reverse sent order) and signing it with the signature key.  Signature keys are exchanged out of band along the secret keys. The authentication tags for the previous frames covered by the signature and the signature itself will be appended at end of the frame, after the current frame authentication tag, in the same order that the signature was calculated, and the SFrame header metadata signature bit (S) will be set to 1. Note that the authentication tag for the current frame will only authenticate the SFrame header and the encrypted payload, ant not the signature nor the previous frames's authentication tags (N-1 to N-M) used to calculate the signature. The last byte (NUM) after the authentication tag list and before the signature indicates the number of the authentication tags from previous frames present in the current frame.  All the authentications tags MUST have the same size, which MUST be equal to the authentication tag size of the current frame.  The signature is fixed size depending on the signature algorithm used (for example, 64 bytes for Ed25519). The receiver has to keep track of all the frames received but yet not verified, by storing the authentication tags of each received frame. When a signature is received, the reciever will verify it with the signature key associated to the key id of the frame the singature was sent in.  If the verification is sucessful, the received will mark the frames as authenticated and remove them from the list of the not verified frames.  It is up to the application to decide what to do when signature verification fails. When using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. If the signature is sent on a frame which layer that is dropped by the SFU, the receiver will not receive it and will not be able to perform the signature of the other received layers. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the frame dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph). In case of simulcast or K-SVC, each spatial layer sould be authenticated with different signatures to prevent the SFU to discard frames with the signature info. In any case, it is possible that the frame with the signature is lost or the SFU drops it, so the receiver MUST be prepared to not receive a signature for a frame and remove it from the pending to be verified list after a timeout. </ins> 4.

Related discussion:
text: A they can be off different size, each HMAC block will have 1 byte header with HNUM (4 bits) indicating the number of HMACs present and HLEN(4 bits) to indicate the size in bytes of each HMAC. To indicate the end of the HMACS blocks an HMAC header block with HNUM=0 and HLEN=0 will be inserted.
One question, what are the sizes of the HMACs? I have considered the ones for AES which are 4 and 8, but in GCM are bigger, right? Are they required to be even or a power of 2? we could do either length=2^(HLEN+1) or LEN=2(HLEN+2) in that case.
I don't think they have to be 2*n. SHA-256 is, of course, but SHA-384 isn't
Currently it says that: However, if using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. In that case, the receiver will never get a full frame and be able to check the signature. Which will render it a kind of useless feature. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph).
This is a good point and suggests 'frame' really refers to each independently decodable unit.
I think I mixed two things on this issue and my original comment is not totally accurate. The signature will contain the HMAC of all the frames it contains, so if any of them is dropped, the receiver can still compute the signature of the received ones. However, if the signature is not sent on the base layer, then it can be dropped by the SFU. I think it still makes sense to send different signatures over different layers to avoid having to send data on the wire that will be dropped by the SFU.