Re: [rtcweb] CNAMEs and multiple peer connections
Watson Ladd <watsonbladd@gmail.com> Fri, 14 March 2014 18:33 UTC
Return-Path: <watsonbladd@gmail.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 ACF2B1A019E for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 11:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FN3A_XUtkylY for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 11:33:46 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28C1A019C for <rtcweb@ietf.org>; Fri, 14 Mar 2014 11:33:46 -0700 (PDT)
Received: by mail-yk0-f176.google.com with SMTP id 19so7676224ykq.7 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 11:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y97rGfyhSbdeveAwwC2/plKEY1xF3qqAYRrfavLrcIo=; b=ZkEWXxsiqpcxmqAKqKyCHlBp0hYjYZXZgAPjhOwMPeg654W6x0rM0a1eQvuwilZ2qh SyyDlvur9irCTX2C9/2++vJ5GOo5kciJMV/UFtEEk2WxYaPA9RaINyavLOOPw09TPKcu aQMnCnDabTEJr2rXmsaW+JsYMOJA0EBFWgsilMhyjoQ77pgvInAArzHrLp+7H/RTUM8+ AszSzKw6VfSHS1mq4ZaazDB63rP4XvSS7PxkERKRqekd9v9356OkteEh4XtaH+e9e4v/ i4JgPzGZcwNONtu2n5f1rAwxjZTssSYGxSFTRG65Mwp5UU72QipYVyrWsEtfQU0ojBrv DezA==
MIME-Version: 1.0
X-Received: by 10.236.191.67 with SMTP id f43mr12728433yhn.60.1394822019384; Fri, 14 Mar 2014 11:33:39 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 11:33:39 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Fri, 14 Mar 2014 11:33:39 -0700 (PDT)
In-Reply-To: <CAOJ7v-08P6X112-Tc45iAcW=c-q-_RGT4tX9Ej9i0aYDLHiwGg@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> <CAOJ7v-1xFHJgkyPwwDOdRGmQp9-MYL=yZADS7OqWya5t6NtpTg@mail.gmail.com> <CAOJ7v-08P6X112-Tc45iAcW=c-q-_RGT4tX9Ej9i0aYDLHiwGg@mail.gmail.com>
Date: Fri, 14 Mar 2014 11:33:39 -0700
Message-ID: <CACsn0cmVkA0vDBZBjS6xd9TUJmwwm2vUupFsEk7nWHfwKAWa9Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="20cf3040e42efd8ecd04f4954e09"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u4P82myWMcBFxU0KYmILru_A4zs
Cc: 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 18:33:49 -0000
On Mar 14, 2014 11:29 AM, "Justin Uberti" <juberti@google.com> wrote: > > > > > On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti <juberti@google.com> wrote: >> >> >> >> >> 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. > > > As to the choice of RSA as the algorithm... we just mandated use of TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09. > That's ridiculous. It should be changed. I'll email the list to explain why.
- [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