Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage

[Magnus Westerlund <[e-mail]>]

On 2014-04-15 19:33, Martin Thomson wrote:
> The text looks fine, with one comment.
> 
> On 15 April 2014 05:10, Magnus Westerlund
> <[e-mail]> wrote:
>>       Note: It is important that the same CNAME is not used in different
>>       communication session contexts or origins, as that could enable
>>       tracking of a user and its device usage of different services.
>>       See Section 4.4.1 of Security Considerations for WebRTC
>>       [I-D.ietf-rtcweb-security] for further discussion.
> 
> I'd rather not have this hidden in a "Note", and I'd prefer if it were
> more concrete.  I think that we need to say something like:
> 
> A different CNAME MUST be used for different RTCPeerConnection
> instances.  Having two communication sessions with the same CNAME
> could enable tracking of a user or device across different services
> (see Section 4.4.1 of [security] for details).  A web application MAY
> override the CNAME that is selected using the process in [RFC7022] to
> allow for synchronization of disjoint sessions; [[this doesn't result
> in a tracking issue, since the creation of matching CNAMEs depends on
> existing tracking]].
> 
> 

The first part is already said in Section 4.9 text:

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022].

Thus, I don't want in two places to use Normative RFC 2119 text for the
same purpose.

For the second half, I have to ask what the scope of this overriding is
intended to be. Is it that within the same origin, a web application
creating multiple PeerConnections can request them to use the same (by
browser) selected random CNAME value? Or is it that the web application
can set the CNAME to be used at PeerConnection creation time. The first
I am fine with, as it appear to have very little downsides, and can
really help application that tries to do advanced things where multiple
PCs are used across multiple endpoints and middleboxes.

Thus, I would propose to modify your proposal to result in a change in
Section 4.9:

Old:
   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022].

NEW:

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a
   single exception; if explicitly requested at creation an
   RTCPeerConnection MAY use the same CNAME as as an existing
   RTCPeerConnection within their common same-origin context.


Section 11:

OLD:

   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 end-point 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 end-point needs
   to be sent using the same CNAME within one RTCPeerConnection.  This
   is motivating the strong recommendation in Section 4.9 to only use a
   single CNAME.

      Note: It is important that the same CNAME is not used in different
      communication session contexts or origins, as that could enable
      tracking of a user and its device usage of different services.
      See Section 4.4.1 of Security Considerations for WebRTC
      [I-D.ietf-rtcweb-security] for further discussion.

      The requirement on using the same CNAME for all SSRCs that
      originates from the same end-point, does not require middleboxes
      that forwards traffic from multiple end-points to only use a
      single CNAME.

NEW:

   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 end-point 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 end-point needs
   to be sent using the same CNAME within one RTCPeerConnection.  This
   is motivating the strong recommendation in Section 4.9 to only use a
   single CNAME.

      The requirement on using the same CNAME for all SSRCs that
      originates from the same end-point, does not require middleboxes
      that forwards traffic from multiple end-points to only use a
      single CNAME.

   Different CNAMEs are normally required to be used for different
   RTCPeerConnection instances, as specified in Section 4.9.  Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).  A web application can
   request that the CNAMEs used in different RTCPeerConnection within a
   same-orign context to be the same, this allow for synchronization of
   the endpoint's RTP packet streams across the different
   RTCPeerConnections.

      Note: this doesn't result in a tracking issue, since the creation
      of matching CNAMEs depends on existing tracking.


Is this better/acceptable?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------