Re: [irsg] Meetecho for interims?

[Toerless Eckert <[e-mail]>]

On Sun, Aug 02, 2020 at 09:28:20PM +0200, Carsten Bormann wrote:
> Hi Toerless,
> 
> I really didn???t want to further extend this part of the thread.

I actually find it quite important that we had more of this type of discussion about actually
system-level security considerations instead of just the end-to-end transport channel crypto.
Of course, this may not be the right thread, and its also unclear what type of draft document
couldn/should be created from this, but it would be a pity of this wasn't something that
ended up in a place where it could be educational to more IETF'ler'. Especially with all
the interesting references you've collected already.

> > What specifically are the technical risks for which you would not have joined
> > a ZVC meeting, such as one of the IETF108 side meetings that used zoom ?
> > (or for that matter of course future interims, which this thread is about)
> 
> The technical risks, and ZVC???s moves to appear getting them covered, are well documented.  I cited Steven Bellovin???s piece that came to the conclusion that these are manageable for the kinds of communication that are similar to what we do in open meetings. (I don???t agree with respect to system security.)

I saw a range of discuss worthy aspects in Steven's document:

a) unless i overlooked something, he just said that he mistrusts browsers more...because of they multi-application/CORS atack surface (i guess). Sounds to me like a reasonable argument, but one that might be possible to overcome if we had a model by which you could start instances of browser (such as in a container model) constrained to a specific (set of) URLs it can access. Many Android Apps AFAIK are just those type of shims on top of browser rendering too. Just no well established model on desktops AFAIK.

b) He rightfully points out that malicious client code is the weakest link, especially when it is written by entities that could be extorted by governments. Unfortunately he then still goes on to claim Zoom is less to be trusted than Cisco given how Zoom has Chinese based development. The same of course is true for Webex. And the extend to which USA lawful intercept can be applied not only to SP but also to software vendors seem to be quite unclear and unknown. Especially given how few such vendors even have warrant canaries to indicate when they had a run in with the US security agencies. 

> However, the reason I???m not going to join conferences based on ZVC products is mainly Ethical, with the technical issues playing second fiddle.

> > If the reason is fear of unknown undetected security risk due to lack of
> > trust into the security diligence of ZVC, would using the RTCweb browser
> > client instead of the native client resolve this issue ?
> 
> Certainly not the Ethical issues.  On the technical side, I do believe that I should prefer browser access over installing vendor-supplied apps with wide access to my system.  But, again, see Steve???s counterpoint on this specific issue.

I am wondering how a javascript client is not also easier decoded and analyzed.
But ideally, the javascript browser clients could/should be open source.

> As a general observation, it is enlightening to which level of criminal energy (technical term here, not the legal one) the ZVC developers have risen to circumvent CORS for their backdoor; it does not seem far-fetched to assume there will be other attacks on browser security when the browser security features happen to get in the way of ZVC corporate policy.

I wonder if there are good written standards for security development
from which the judgements ("criminal energy") that you are making could be
drawn. E.g.: I would not be surprised to hear competely differently
worded judgement calls from other evaluations and i therefore think
there are no good "community" ? "industry" ? standard for such judgmenets.
Or are there ?

> > If we want future interims like past interims to be publically announced
> > without participant auhentication, i think zoombombing would be a risk
> > for any platform we choose: meetecho, webex, zoom, BBB, whatever.
> 
> Even discussing Zooombombing as a security issue makes me question whether you have started to consider the real issues.  However, let me point out that conferencing systems based on authorization, such as meetecho or BBB (if correctly configured) only have the problem as far as the authorization can be gamed.

I didn't say security. Just a list of issues to consider.

I think we are in full agreement that user authentication is probably the easiest
way to avoid zoomboming (whatever tool we use). However, the current datatracker
account (manually created) and paywall, single-instance participation only are
too limited to widen the use of meetecho to all the cases we would want to support IMHO.

> > Leaves as the biggest risk AFAIK the problem of clients creating backdoors,
> > and i would hope that w3c/ietf work on browser client platform security
> > would be sufficient.
> 
> (See above.)
> 
> Fool me once, shame on you; fool me twice, shame on me.

Cheers
    Toerless

> Grüße, Carsten

-- 
---
[e-mail]