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.