Requirements for Secure Web Conferencing (Revised)

[aboba]

Revised based on feedback from June Interim of the WEBRTC WG.

Potential fix for Issue #37

Based on PR #21 submitted by Cullen Jennings

[eomara]

Could mention MLS in the browser here as potential solution. I have wrote this scenario down in the federation draft

[aboba]

The use case doesn't get into much detail on security requirements. For example, properties such as non-repudiation, perfect forward secrecy (PFS) or post-compromise security (PCS) are not mentioned. And of course, the use case currently doesn't list any requirements.

The MLS architecture draft does a much better job of articulating the desired security properties. For example, draft-ietf-mls-architecture Section 3.2.25 discusses Non-Repudiation vs Deniability:

As described in Section 4.4, MLS provides strong authentication
within a group, such that a group member cannot send a message that
appears to be from another group member. Additionally, some services
require that a recipient be able to prove to the messaging service
that a message was sent by a given client, in order to report abuse.
MLS supports both of these use cases. In some deployments, these
services are provided by mechanisms which allow the receiver to prove
a message's origin to a third party (this if often called "non-
repudiation"), but it should also be possible to operate MLS in a
"deniable" mode where such proof is not possible.

[aboba]

Filed Issue #37 relating to security requirements.

[alvestrand]

I think the requirements list should be split between the "trusted JS" and "untrusted JS" cases, and filled in before merge.

[aboba]

Added requirements list to both use cases.