Re: [rtcweb] CNAMEs and multiple peer connections

Justin Uberti <juberti@google.com> Fri, 14 March 2014 18:29 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 5ED5F1A017C for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 11:29:17 -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 FAKHtWyqtZQV for <rtcweb@ietfa.amsl.com>; Fri, 14 Mar 2014 11:29:14 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D63DB1A016F for <rtcweb@ietf.org>; Fri, 14 Mar 2014 11:29:13 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id il7so3130421vcb.4 for <rtcweb@ietf.org>; Fri, 14 Mar 2014 11:29:06 -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=/EjIuFXpJWGgFZgtWkAFlW53BZMJAVK0ZEDYU/mEiYw=; b=NqXXvgT8aMELMVaFCFn7QCX7NRA3XtCP+YiNZO3OvjIVmZvJsPNmbOJ7AoStXecSWw qmETpoJyJLgXZkYaSl+oscqLJRSD7a55wqfjunL9RRd/aQF3GTr3xnmLIkIHCLBMFcFB yX23Uzuw/BD1tG3196u+gz626xx8dAB7Es1/PbeT/j23IY+Sp/cBj7LMoQk5ElrLplIR +xoTnvmUztWYbaYlE6reWHiPizrjNU7Rm/uYZkGFHuVsUv8yWDb/mEuRAzavWwqyDVDq fn0kwntJkx+4Y9V4XkDTRrL8a8VWhpDhBRPCmFvPYHBAR6E5HHJdmp9ueHpiJLCFGdIQ cJnQ==
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=/EjIuFXpJWGgFZgtWkAFlW53BZMJAVK0ZEDYU/mEiYw=; b=P2NLyBRz/gi8k8w6N5ZWELKNjjoUFS4BkBfetJ3JyyuSPkohG5VgIMDTt9thRuGljK o1y4ye9pcoOpSA7bfBVVozw1tE/aNMalk3YqVEXHEPlrknDV6Hp0lWd0dMQynfN5aAn7 J5GdUgNw4jSDvrH6R/ektduRJxyuoSAfltmKTydXjDDr6S1yu1z4k5CAIXC35weovaGz U9RV59TmJ9XjtTOPhVegBBhjpUurTmgdlQ/wpzjV/l65WMHCi6mGmfO4dA2BhHH85vSm L8ijxy1KRJPlRbowBpgAHkaiOIEM3i4YaPwHUQqh9BLbOXWaQoFcHklWoRLC9nEyKq1E mgqQ==
X-Gm-Message-State: ALoCoQlGwTZFulXnq5AkkojAeWQuX7fNxyKg/kHaI4V+j1nAsPchSF3Yp9w7p0L0Y21lkTCn2elnRZ+XEr0ERNK5PFvEOLKBS+kfV90+XoFcvV4esPn2UntENfwu06hK90DeM14l8BJPoBRJ3oceVv4H2fAxTBqseD0Tzq9EA7KUOV04eCSAt8r9zsoTXcSLtWopDgvVqpHG
X-Received: by 10.58.57.42 with SMTP id f10mr7605830veq.1.1394821746743; Fri, 14 Mar 2014 11:29:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Fri, 14 Mar 2014 11:28:46 -0700 (PDT)
In-Reply-To: <CAOJ7v-1xFHJgkyPwwDOdRGmQp9-MYL=yZADS7OqWya5t6NtpTg@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>
From: Justin Uberti <juberti@google.com>
Date: Fri, 14 Mar 2014 11:28:46 -0700
Message-ID: <CAOJ7v-08P6X112-Tc45iAcW=c-q-_RGT4tX9Ej9i0aYDLHiwGg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a1136ac66bd753a04f4953e5c
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pc03hQS7Zml9h48qwxSEWNGuWzc
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 18:29:17 -0000

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;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.