Re: [rtcweb] CNAMEs and multiple peer connections
Justin Uberti <juberti@google.com> Fri, 14 March 2014 17:40 UTC
Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEB71A01A0 for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 10:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-1CGkOfP-4I for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 10:40:07 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED711A017C for <rtcweb@ietf.org>; Fri, 14 Mar 2014 10:40:07 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id cz12so3040784veb.16 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 10:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z92DMLz8JjKpEQi/YIzY8ipwnTazhSfuFwQgTWVB+Lk=; b=BA94M5YzVWE/QyJtsCs/3I7u4XtOjSyDLeTuDAs5FYStGANZex9daP4WL02bimuEZp 03xrgeyY4+uEiTsRUyuoCUaDUpX527DW0hhVGWvSR6VDfYMMEQ7vGIUYxWjl2XQqfXMn /Pu/8tPsGAzLX6nJcZpBRaetLoeh6S6pTWDZz+Swx8Hc86V0OKe/bEi0+fcr/iyikhff i1CaahggvUMODRu/Or/MOtzpsAARrNqm2KzDBj9pX1rYOYKtf8oAh5wV7qVxvnBMaYzi YFZdSfxr4dQSMHvP8Lndwjl+VOM9JY0RsNs/E+ORveWfzXc6lEitEwFykE7F1wX/RQsB GC4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Z92DMLz8JjKpEQi/YIzY8ipwnTazhSfuFwQgTWVB+Lk=; b=FoYouE5pUodcCtk1YWDq3Y3LmxZ5D+0RU+bymFiSuTNcKXiz44W/UFZ2JQTotrblmV qYIej0KiqtFJSm1325ECAVAj+EJVYXhocgcAC8jL831T8Rnfipx+nd2iXrLCYXfH6eHl L2mPP4oYVhPX3qmY4C2P9/jL16OojjPviqrMHOi/48+N7u0JOBILIoki8zAoPjelsgs/ kWgb93lI1EWKB1mH+jbH1kUkxOiNk7VycWU+B55K7K8Vp3rUKpi0x+8RvctDaZPIuxls rAgjcCETJls4xM6HLpRNyzzs4EhUgOdoiLL10N6Mn5Nab7xMPH8G2xiz8xhTx4cJn8SC 8Ieg==
X-Gm-Message-State: ALoCoQnlMsAbqmacWxsHW+OvbqrfqcjK0kc6IoS6wn0E45YeNAMHJKE7kphVhQf8j0Doz1PNR9iS9GEI8PI6uGsOQTtKaRKDO1WWNCc1yJMS1ynzp1OwQLQBSrqLJRC23haVjQ4fimhuSfPwIJd5mmh960L4KGfnQNaf24L9Qgts+rCBzskyPy7561cjK/nLBZLWhkbHMsXe
X-Received: by 10.52.124.66 with SMTP id mg2mr66387vdb.50.1394818800169; Fri, 14 Mar 2014 10:40:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 10:32:02 -0700 (PDT)
In-Reply-To: <CACsn0cnj8pkb2kLD+ysL0ws+zCL_-YZysr9MBVscu6u4sXvTSg@mail.gmail.com>
References: <CABkgnnWGQ7GtKd33iF-RNbkeAyqKYshaPDDB=sAh5o-izKichQ@mail.gmail.com> <53171C20.3020001@ericsson.com> <CABkgnnWWoCLKga7RDEmS1kDOuBPaiKaJ+_yj6-yPRSV8LVc=2A@mail.gmail.com> <CAOJ7v-1J=F-MNnBS96gt3_BXyoQB6jTCoHp0MTEBC-nWrF-BhA@mail.gmail.com> <CABkgnnWQbtKYTuvUyMiCaEijv3KVydR8sxGXZep08B4EQXArxA@mail.gmail.com> <531DD807.9090602@ericsson.com> <CABkgnnVscHB6_weLkxHunQxLue7g-WvBwO-P_CW6eEU_JYqVuw@mail.gmail.com> <53201AEF.6090501@ericsson.com> <CABkgnnX16mOUOCmQ3wgQ2AV8o5WNXpCjVi-Rhr+ASWQ2LPzA-w@mail.gmail.com> <5322BF2E.3060608@ericsson.com> <CAOJ7v-3NFiR4yXRoscWQ5Oh7ohiM+fD=YJBp2Q-rdA_Azu9gZA@mail.gmail.com> <CACsn0cnj8pkb2kLD+ysL0ws+zCL_-YZysr9MBVscu6u4sXvTSg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 14 Mar 2014 10:32:02 -0700
Message-ID: <CAOJ7v-1xFHJgkyPwwDOdRGmQp9-MYL=yZADS7OqWya5t6NtpTg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="bcaec52997451c4dbd04f4948f03"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tPtsVy4d47fxHs6_k-bKgiy76zE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] CNAMEs and multiple peer connections
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 17:40:10 -0000
On Fri, Mar 14, 2014 at 9:53 AM, Watson Ladd <watsonbladd@gmail.com> wrote: > > On Mar 14, 2014 9:44 AM, "Justin Uberti" <juberti@google.com> wrote: > > > > > > > > > > On Fri, Mar 14, 2014 at 1:34 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> > >> On 2014-03-13 17:53, Martin Thomson wrote: > >> > On 12 March 2014 01:29, Magnus Westerlund > >> > <magnus.westerlund@ericsson.com> 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.
- [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Harald Alvestrand
- Re: [rtcweb] CNAMEs and multiple peer connections Dan Wing
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Dan Wing
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti
- Re: [rtcweb] CNAMEs and multiple peer connections Watson Ladd
- Re: [rtcweb] CNAMEs and multiple peer connections Martin Thomson
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti
- Re: [rtcweb] CNAMEs and multiple peer connections Watson Ladd
- Re: [rtcweb] CNAMEs and multiple peer connections Magnus Westerlund
- Re: [rtcweb] CNAMEs and multiple peer connections Justin Uberti