Re: [rtcweb] CNAMEs and multiple peer connections

[Justin Uberti <[e-mail]>]

On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd <[e-mail]> wrote:

>
> On Mar 14, 2014 9:44 AM, "Justin Uberti" <[e-mail]> wrote:
> >
> >
> >
> >
> > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund <
> [e-mail]> wrote:
> >>
> >> On 2014-03-13 17:53, Martin Thomson wrote:
> >> > On 12 March 2014 01:29, Magnus Westerlund
> >> > <[e-mail]> wrote:
> >> >> I like to point out that the agreement and what is documented in
> >> >> rtp-usage is that WebRTC endpoint will have to make forwarded streams
> >> >> appear as locally originated. However, this as currently written does
> >> >> not apply to RTP middleboxes that interconnects multiple
> PeerConnections
> >> >> to form a multi-party session. This is deliberate to ensure that RTP
> >> >> topologies like RTP mixer and SFM do work on the RTP/RTCP level.
> >> >
> >> > I'm still not clear on whether a middlebox interoperating with a
> >> > WebRTC endpoint is obligated to respect these rules or not.  I had
> >> > assumed that WebRTC is such a bully that they would be forced to.
> >>
> >> Well, I know Colin and I did put in quite some thought to make the
> >> WebRTC RTP usage rules such that you can use the common RTP middleboxes
> >> as long as you have the right front-end, i.e. DTLS-SRTP and signalling
> >> translation.
> >>
> >> >
> >> >> I am especially interested to know how you will "easy to apply
> manually"
> >> >> the synchronization. Can you please describe that. Because, that
> either
> >> >> requires an API call to tell the media framework, please consider the
> >> >> following CNAMES as equivalent, or some other method of telling the
> >> >> media framework that these different MST are actually originating
> from a
> >> >> common clock base.
> >> > In WebRTC, this would be:
> >> >
> >> > var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0];
> >> > var video = pc2.getRemoteStreams()[0].getVideoTracks()[0];
> >> > var synchronizedStream = new MediaStream(audio, video);
> >> >
> >> > We'd have to say that this implies a statement about the clock base of
> >> > the tracks being the same.  ... and that this statement could be
> >> > wrong.
> >>
> >> I think this looks dangerous. If you default the assumption that
> >> different CNAMEs of the MST you add are actually sharing clock base,
> >> then a lot of basic programs that may group MST from different PCs into
> >> one MS for convenience are going to cause serious issue in the media
> >> frameworks, when they attempt to synchronize things.
> >>
> >> >
> >> > As far as it goes, I'm sure that other systems could build a similar
> >> > function, but none of those are standardized.
> >> >
> >> >> I protested about this, not to lower the users privacy, but over the
> >> >> concern that this was raised without providing a case where it was
> >> >> obvious that the user's privacy was impacted. Martin, you said that
> you
> >> >> would think about it, and the next statement was lets change it,
> without
> >> >> providing any motivation why the concern was significant.
> >> >
> >> > I'm sorry about that, I thought about it, but didn't want to waste
> >> > everyone's time (mine included) with an essay on the subject.
> >> >
> >>
> >> Having considered this a bit more, I do think the risk to privacy out
> >> weighs the other concerns, as long as the API and its handling can be
> >> sorted out, I don't think the above is sufficient to get good
> >> functionality.
> >>
> >> My understanding is that the risk to privacy exist when one have one JS
> >> application enabling communication in different contexts during the same
> >> application session. In cases where there might be participants in the
> >>
> >> different contexts that could link the same end-point and thus human
> >> user to different participant IDs (that otherwise are anonymous). Thus
> >> revealing privacy concerns. As it would take the application designer to
> >> take this risk into consideration to avoid it, I feel safer if the
> >> application designer would need to take active measurements to perform
> >> linkage.
> >>
> >>
> >> I will wait an see if there are other inputs on this within the next
> >> week. If nothing arises I will propose a text change to the rtp-usage to
> >> address this.
> >>
> >
> > At an implementation level, one could imagine at least 3 policies for
> generating CNAMEs:
> > a) per-session (i.e. per-PeerConnection)
> > b) per-page (i.e. shared between all PCs on a page)
> > c) per-page, persistent (i.e. shared between all PCs on a page,
> including across page loads)
> >
> > While we seem to agree that a) is the right solution for CNAMEs, it is
> worth pointing out that we (Chrome) are currently doing c) for DTLS
> certificates, to avoid performance problems with cert generation at page
> load. Ergo, this linkability concern already exists, and I don't think it
> is easy to solve it in the default case. There have been some proposals to
> allow generation/storage of unique certs to prevent this linkability, but
> this will require app input.
> >
>
> One exponentiation, fixed base, per certificate. Use an addition
> multichain. Cert generation is cheap with ECDSA.
>
You're going to have to explain a bit more for me to grok this.

Also, define 'cheap', especially on ARM CPUs. Currently RSA generation on
best-in-class ARM CPUs is 500 ms for 1024-bit, 2 seconds for 2048-bit. That
is a problem.