Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security

Cullen Jennings <fluffy@iii.ca> Fri, 07 October 2016 18:23 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB07128B44 for <mmusic@ietfa.amsl.com>; Fri, 7 Oct 2016 11:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sFmNWE6s-GNs for <mmusic@ietfa.amsl.com>; Fri, 7 Oct 2016 11:23:41 -0700 (PDT)
Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A439B129498 for <mmusic@ietf.org>; Fri, 7 Oct 2016 11:23:41 -0700 (PDT)
Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E518DC054E; Fri, 7 Oct 2016 14:23:40 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 44A9AC050F; Fri, 7 Oct 2016 14:23:40 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.24.90.15] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 07 Oct 2016 14:23:40 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <243c777f-46f9-4053-1588-7e6b58a06c8c@ericsson.com>
Date: Fri, 07 Oct 2016 11:23:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0D4078A-3B33-4A17-A82B-BACC0FACF8BE@iii.ca>
References: <D41C238A.1095B%christer.holmberg@ericsson.com> <71419d1f-af1d-46e9-401d-81c5df73fc49@ericsson.com> <58510E68-A045-4312-B3B3-3468E83C8EB7@iii.ca> <243c777f-46f9-4053-1588-7e6b58a06c8c@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/sakILzev-X5NFEFQ8flYJJxq9wc>
Cc: RTCWeb IETF <rtcweb@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32 - Magnus' comments - MID security
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 18:23:43 -0000

> On Oct 7, 2016, at 1:41 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> Den 2016-10-06 kl. 23:59, skrev Cullen Jennings:
>> 
>> I'm not getting the problem here and mandating 6904 is not an easy
>> thing to do.
> 
> So, lets be clear on what I have proposed. For bundle in general it is RECOMMENDED to encrypt MIDs in RTP header extensions. I have also proposed that for RTCWeb implementation and use should be mandated. I was not clear in what applies when an WebRTC endpoint talks to a legacy endpoint what is expected here. I guess this is the thorny issue.
> 
>> 
>> I'm not getting what the issue is here. If mid are random, or are
>> just a count of n'th m-line in the sdp, what is the problem with
>> exposing them to people are getting the media?
> 
> The issue is that these identifiers are going from having only been visiable in the signalling messages to be visible also on the RTP media plane. And without RFC6904 even if one uses SRTP, these values are exposed. This have several different effects as I see it. So if the generation algorithm are not strictly defined, the implementation gets possible to fingerprint. In addition the device gets to be fingerprinted based on the number of streams offered and their identifiers. Thus, it is not only what is actually used that is exposed, but what was originally offered, i.e. the full offer leaks into unencrypted domain on the media plane. Note, this later can't be dealt with any mid id creation rules, it will still leak. Thus devices that have more exotic configurations when it comes to media streams, i.e. number of cameras etc this can still be fingerprinted by passive attacks from third parties.
> 
> It is the passive attack from third parties that has me worried here. A peer in the signalling has massively more powerful fingerprinting, but that requires one to be in the signalling context, not passively observe traffic that goes past.
> 

I'm still not getting the fingerprint problem. How is this different than PT and SSRC. Yes, I agree the MID and RID - which were always intended to go in the RTP packet need to be generated not to have sensitive information in them.