Subject: [rtcweb] CNAMEs and multiple peer connections

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 10:04:31 +0000

I haven't thought about this in detail yet, but I wanted to ensure
that this issue is tracked.  I think that our chairs might be able to
create an issue in some tracker.  Can I request that they do that for
this issue?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Mar 2014 12:44:16 +0000

> create an issue in some tracker.  Can I request that they do that for

I will currently not stuff anything into our tracker.

However, I will give a bit of context from what the rtp-usage says about
this.

On the receiver side, we have a clear requirement on handling multiple
CNAMEs in Section 11.

   A WebRTC endpoint MUST support receiving multiple MediaStreamTracks,
   where each of different MediaStreamTracks (and their sets of
   associated packet streams) uses different CNAMEs.  However,
   MediaStreamTracks that are received with different CNAMEs have no
   defined synchronisation.

On the sending side the text says the following:

   The same MediaStreamTrack can also be included in multiple
   MediaStreams, thus multiple sets of MediaStreams can implicitly need
   to use the same synchronisation base.  To ensure that this works in
   all cases, and don't forces a endpoint to change synchronisation base
   and CNAME in the middle of a ongoing delivery of any packet streams,
   which would cause media disruption; all MediaStreamTracks and their
   associated SSRCs originating from the same endpoint MUST be sent
   using the same CNAME within one RTCPeerConnection as well as across
   all RTCPeerConnections part of the same communication session
   context, which for a browser are a single origin.

Martin, you talked about linking in this context. I wonder if there
really are an issue with linking as this is all in the same
communication context. Can you please make clear your concerns?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 13:37:39 +0000

> communication context. Can you please make clear your concerns?

I'm mostly concerned about being able to communicate with multiple
people from the same page without revealing a linkage between sessions
based on cert or CNAME.  It may be that we need API hooks to control
this.

As I said, I haven't thought it through fully.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 14:30:42 +0000

I think the key thing is that it's not clear when creating a new
PeerConnection whether it should make new CNAMEs or use existing ones.

Compare the two scenarios below:

#1: audio and video over 2 PCs to the same destination
pc1 = new RTCPeerConnection();
pc2 = new RTCPeerConnection();
pc1.addStream(audioStream);
pc2.addStream(videoStream);
doCall(pc1);
doCall(pc2);
// cnames in pc1 and pc2 should be the same

#2: audio call over PC1 to destination 1, followed by audio call over PC2
to destination 2
pc1 = new RTCPeerConnection();
pc1.addStream(audioStream);
doCall(pc1);
pc2 = new RTCPeerConnection();
pc2.addStream(audioStream);
doCall(pc2);
// cnames in pc1 and pc2 should be different

I am inclined to make CNAMEs per-PeerConnection (i.e. enforce scenario #2
behavior) for 1.0, as it has a smaller downside.

On Wed, Mar 5, 2014 at 1:37 PM, Martin Thomson <[email-masked]>wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 16:07:18 +0000

> behavior) for 1.0, as it has a smaller downside.

I think that I am OK with this.  It might still be possible to
synchronize in the first scenario, but it would require that the
playback protect itself against drift, because CNAME wouldn't be
providing a positive indication that synchronization is safe.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Mar 2014 16:43:01 +0100

> create an issue in some tracker.  Can I request that they do that for

This is the issue of whether one should (MUST/SHOULD/MAY/MUST NOT) use
the same CNAME for RTP media streams created in different PeerConnections?

In particular, if one does

  pc1.addStream(s)
  pc2.addStream(s)
  pc1.<connect procedure to X>
  pc2.<connect procedure to Y>

will the same CNAME be shown to both X and Y, or not?
And does the answer change if X and Y are the same (for some value of
"same")?

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 07:01:41 +0000

> the same CNAME for RTP media streams created in different PeerConnections?

I think that, as Justin has pointed out, we should say 'MUST be different'.
That way, we are able to protect against linkability trivially.

The synchronization case I raised isn't important enough, or difficult
enough to address without CNAME that we would need to risk the greater
exposure that re-use would bring.

---

From: Dan Wing <[email-masked]>
Date: Fri, 7 Mar 2014 20:14:13 +0000

> create an issue in some tracker.  Can I request that they do that for

About half a year ago, AVTCORE published an updated recommendation for CNAME as RFC7022.  Is its guidance insufficient?

-d

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 06:48:22 +0000

> About half a year ago, AVTCORE published an updated recommendation for CNAME as RFC7022.  Is its guidance insufficient?

Necessary, but not sufficient.  Unfortunately, the definition of a
"session", while sufficient for the description in 7022, is not quite
precise enough for this use case.  The implication there is that it
means "RTP session", which is both not at the right level of
granularity, and not directly actionable.

I also note this little gem:

   A longer-term persistent RTCP CNAME is sometimes useful to facilitate
   third-party monitoring, consistent with [RFC3550].

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 15:42:12 +0100

On 2014-03-08 07:48, Martin Thomson wrote:
>> About half a year ago, AVTCORE published an updated recommendation
>> for CNAME as RFC7022.  Is its guidance insufficient?
> 
> "session", while sufficient for the description in 7022, is not
> quite precise enough for this use case.  The implication there is
> that it means "RTP session", which is both not at the right level of 

So, within a PeerConnection one have one or more RTP sessions, depending
on how one configures it. That RTP session MAY be interconnected with
other PeerConnection's RTP sessions by a middlebox.

As long as this is different end-points PCs there is little issues. The
interesting case here is if one end-point connects multiple PCs to the
same middlebox and starts seeing its own traffic due to the middlebox
not being built for this usage and the JS programmer thinks this is okay
to do.

The end-point can always detect this, as it knows all its used CNAMEs,
and can note that they are looped back to itself if this check is
implemented. If one have the same CNAME is both PC's RTP session
instances the RTP stack is more likely to detect this without code
changes as a loop.

The only reason I can see for having multiple PCs being connected to the
same middlebox would be if that makes the setup of QoS simpler, but I
think MST individual RTP sessions within the context of one PC is more
straight forward to ensure that one have unique 5-tuples per media stream.

> A longer-term persistent RTCP CNAME is sometimes useful to
> facilitate third-party monitoring, consistent with [RFC3550].

Yes, but that is clearly not suitable for WebRTC.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 15:44:13 +0100

> Yes, but that is clearly not suitable for WebRTC.

I'm sure that's not the only thing it's unsuitable for.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 16:04:00 +0100

> I'm sure that's not the only thing it's unsuitable for.

No, but there are cases where this can be a desired property in someone
building an application. For example an astronomy sensory network that
deliver sensor data over RTP. In that case you are not talking about
human user's endpoints, and you also may have a private network and want
to make monitoring at key points simple. Thus having the sensors being
provided a persistent name is simple and straight forward.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 16:19:35 +0100

> providing a positive indication that synchronization is safe.

Please slow down here,

Can you please think through the linkage issue a bit first before
changing this property. I know that it might appear simple to mandate
different CNAMES on a Per PC basis, but I do think it has downsides.

One has to do with loop detection between the PCs, i.e. determine if one
receives one self's MSTs. The next one is that it will prevent someone
to easily determine if the MST in two different PCs are actually sharing
the same synchronization context. As the default really needs to not
synchronize RTP media with different SSRCs, having the JS app direct the
browser to please consider some set of CNAMEs as being equal will be a
problematic one, and require API surface.

I want to understand what issue with linkages that we have here before
determining what to do. So, different application contexts, i.e.
different browser TABs on an end-point will have different CNAMEs, thus
different applications will not allow linking between them. The linkage
we have is between PCs originating in the same JS application instance.
In cases where a set of end-points participate in a conference, they
will see only one CNAME from this endpoint.

I guess the linkage issue appears when one application have the endpoint
participate in two or more conferences either simultaneous or in
sequence (assuming that CNAME will be persistent as long as some PC
exists or during the JS application lifetime). In that case an external
endpoint participating in more than one of these conferences can see the
same CNAME appears in both conferences. And thus link any input
provided, if the applications doesn't otherwise reveal the user identity
etc. anyway.

I have a hard time determine the impact of this linkage issue, as it
will depend on the application context, and also the CNAMEs persistence
over time within a JS APP context.

Cheers

Magnus Westerlund

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 16:49:04 +0100

On 10 March 2014 16:19, Magnus Westerlund
<[email-masked]> wrote:
> changing this property.

We already came to the conclusion that if media was being forwarded by
a peer, then that is new media originated by that peer, not the same
media.  Thus, if looping occurs, it is at the application layer.  We
definitely already agreed that RTP forwarding is not a function that a
browser will support.

Obviously, if we add that feature, CNAMEs will be just one of the
manifold issues that will arise and we will have to reconsider.
Compromising the privacy of users doesn't seem like a good trade-off
against some minor advantages in terms of loop detection (unlikely)
and synchronization (easy to apply manually).

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 21:40:17 -0700

Future versions of the API should have the knobs needed to control the
CNAMEs more exactly. For WebRTC 1.0 though, scoping CNAMEs to a
PeerConnection feels like a prudent simplification.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 09:29:35 +0100

> definitely already agreed that RTP forwarding is not a function that a

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.

> and synchronization (easy to apply manually).

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.

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.

>From my perspective, if you can provide a good explanation how to
actually accomplish the synchronization, I think a change of scoping the
CNAME to a PeerConnection is okay. But, I would like to understand how
you believe it is accomplished.

Magnus Westerlund
(As RTP-usage author)

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Mar 2014 00:51:02 +0000

> granularity, and not directly actionable.

Perhaps AVTCORE can take on an update to use WebRTC terminology.

>   third-party monitoring, consistent with [RFC3550].

Yep, it's true.

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 16:32:03 +0100

> Perhaps AVTCORE can take on an update to use WebRTC terminology.

I disagree!

WebRTC is a particular usage of RTP/RTCP. The fact that RFC 7022's
terminology is not sufficiently narrow to describe the particulars of
WebRTC's usage is in my opinion not a bug. It is a feature. If the
AVTCORE document would be using the narrowed down case of WebRTC the
recommendations would no longer be applicable in a number of other
usages of RTP.

Deciding to apply RTP in a particular way to solve ones real-time
transport problems, also means that one have may have to be more
specific within that usage about things, this is such an example.

Cheers

Magnus Westerlund
(As Individual)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 09:53:46 -0700

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

> media framework that these different MST are actually originating from a
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.

As far as it goes, I'm sure that other systems could build a similar
function, but none of those are standardized.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Mar 2014 09:34:54 +0100

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

> the tracks being the same.  ... and that this statement could be

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.

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

Cheers

Magnus Westerlund
(As individual)

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 09:44:06 -0700

> week. If nothing arises I will propose a text change to the rtp-usage to
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.

Ergo, we might want to match the DTLS behavior (i.e. generate unique CNAMEs
only when the certs are unique), to ensure we treat linkability
consistently.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Mar 2014 09:53:24 -0700

across page loads)

One exponentiation, fixed base, per certificate. Use an addition
multichain. Cert generation is cheap with ECDSA.

Sincerely,
Watson Ladd
> Ergo, we might want to match the DTLS behavior (i.e. generate unique
CNAMEs only when the certs are unique), to ensure we treat linkability
consistently.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Mar 2014 10:16:33 -0700

On 14 March 2014 09:44, Justin Uberti <[email-masked]> wrote:
> 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.

Firefox does 1-per PC.  There are plans to allow more granular control
over this (following ekr's proposal), but that's currently low
priority.  There are plenty of other places where we can make
performance improvements.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 10:32:02 -0700

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

> > c) per-page, persistent (i.e. shared between all PCs on a page,
> including across page loads)
> >
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.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 11:28:46 -0700

On Fri, Mar 14, 2014 at 10:32 AM, Justin Uberti <[email-masked]> wrote:

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

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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Mar 2014 11:33:39 -0700

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2014 11:29:51 +0100

On 2014-03-14 17:44, Justin Uberti wrote:

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

Actually, the DTLS cert and the CNAME is actually not equivalent when it
comes to visibility scope. The DTLS is show only to the DTLS peer, i.e.
the address at the other end of a peer connection. The CNAME in cases of
SFM or RTP mixer based using CSRC lists type of RTP middleboxes, can
result in the CNAME being forward to all participants in the same
multi-party conference.

Cheers

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 17:23:09 -0700

Good point. So CNAME is perhaps the most important in terms of linkability,
but DTLS certificate and also IPv6 address may allow linkage by some
network elements.