Draft: draft-omara-sframe

Commentary: Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Signature flag (S): 1 bit This field indicates the payload contains a
signature of set.  Counter Length (LEN): 3 bits This field indicates
the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1
bit
Indicates if the key field contains the key id or the key length.
Key or Key Length: 3 bits This field containts the key id (KID) if
the X flag is set to 0, or the key length (KLEN) if set to 1.
Signature flag (S): 1 bit This field indicates the payload contains a
signature of set.  Counter Length (LEN): 3 bits This field indicates
the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1
bit
Indicates if the key field contains the key id or the key length.
Key or Key Length: 3 bits This field contains the key id (KID) if the
X flag is set to 0, or the key length (KLEN) if set to 1.
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 signature is calculated by concatenating 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 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.
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 receiver will verify it with the
signature key associated to the key id of the frame the signature was
sent in.  If the verification is successful, 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.
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 case of simulcast or K-SVC, each spatial layer should be
authenticated with different signatures to prevent the SFU to discard
frames with the signature info.
o A hash function This is used for the Key derivation and frame
hashes for signture.  We recommend using SHA256 hash function.
o A hash function This is used for the Key derivation and frame
hashes for signature.  We recommend using SHA256 hash function.
SFrame must be integrated with an E2EE key management framework to
exchange and rotate the encryption keys such as MLSPROTO which scales
to very large groups.  Call members will create a MLS group to
exchange the encryption keys for all further calls for that group.
When a client joins the call, they create a random key material and
encrypt it to every other client on the call using their MLS
application secret.  This key material is passed to SFrame to derive
SFrame keys for that client.  When group membership changes, the
active clients in the call must update their keys for "Forward
Secrecy" and "Post Compromise Security".  Key ratcheting can be used
when a new member joins the group but for member leave events, a
fresh key material will be generated by each client endpoint in the
call and encrypt it using their MLS application secret.
If authentication is enabled, every client will also generate public-
private key pair for signing and exchange the public part with the
secret key material.
SFrame must be integrated with an E2EE key management framework to
exchange and rotate the encryption keys.  This framework will
maintain a group of participant endpoints who are in the call.  At
call setup time, each endpoint will create a fresh key material and
optionally signing key pair for that call and encrypt them to every
other endpoints.  They encrypted keys are delivered by the messaging
delivery server using a reliable channel.
The key management framework will monitor the group changes, and
exchange new keys when necessary.  It is up to the application to
define this group, for example one application could have ephemeral
group for every call and keep rotating key when end points joins or
leave the call, while another app could have a persisted group that
can be used for multiple calls and exchange keys with all group
endpoints for every call.
When a new key material is created during the call, we recommend not
to start using it immediately in SFrame to give time for the new keys
to be delivered.  If the application supports delivery receipts, it
can be used to track if the key is delivered to all other endpoints
on the call before using it.
Keys must have a sequential id starting from 0 and incremented eery
time a new key is generated for this endpoint.  The key id will be
added in the SFrame header during encryption, so the recipient know
which key to use for the decryption.
While any other E2EE key management framework can be used with
SFrame, there is a big advantage if it is used with MLSARCH which
supports group natively and can support very large groups an
efficiently.  When MLSPROTO is used, the endpoints keys (AKA
Application secret) can be used directly for SFrame without the need
to exchange separate key material.  The application secret is rotated
automatically by MLSPROTO when group membership changes.
When using simulcast, the same input image will produce N different
encoded frames (one per simulcat layer) which would be processed
inpependently by the frame encryptor and assigned an unique counter
for each.
When using simulcast, the same input image will produce N different
encoded frames (one per simulcast layer) which would be processed
independently by the frame encryptor and assigned an unique counter
for each.