Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration

Magnus Westerlund <> Fri, 03 March 2017 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1DCB1298AD; Fri, 3 Mar 2017 07:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sq_5IsgzFrqM; Fri, 3 Mar 2017 07:06:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D829B1298AA; Fri, 3 Mar 2017 07:06:25 -0800 (PST)
X-AuditID: c1b4fb3a-6f7ff70000007c1e-27-58b9866e3d67
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 7A.F6.31774.E6689B85; Fri, 3 Mar 2017 16:06:23 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Fri, 3 Mar 2017 16:06:21 +0100
To: Eric Rescorla <>
References: <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Fri, 3 Mar 2017 16:06:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7k25+284Ig+Vb9CxWvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bkyy+YC9ZLV/z9+YOlgfG/SBcj J4eEgInExLYjbF2MXBxCAusYJRYd/MEM4SxjlDhyaxEbSJWwgJdE27aJzCC2iICCxK8/J1gg itoYJW7uugRUxMHBLOAjsfBZIkgNm4CFxM0fjWBhXgF7ia9zM0DCLAIqEiePtICNERWIkdjb f58JxOYVEJQ4OfMJC4jNKRAo8fZTL1gNM9CYmfPPM0LY8hLNW2eDxYUEtCUamjpYJzAKzELS PgtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbowS2/rXYwHnzueIhRgINR iYd3Q/aOCCHWxLLiytxDjBIczEoivK2VOyOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8u JJCeWJKanZpakFoEk2Xi4JRqYJxof0cpTWP/pjknvsp1Lc1bl8Fq+1n/YsC8ScyrD66+tzfc o2zrgz9vdy/edtb0eNT0y49y9Ocof08vb7XWmZ53uO78j2/HfeN+c10viRMQaPyf+GTjr+tb 87/uUJvm91KqXnlShkJdwN3SJW52JdX3XmbfT9rpU+CcUP3rHt960ZJ175X+8c1XYinOSDTU Yi4qTgQA1cCpd0wCAAA=
Archived-At: <>
Cc: "" <>, "mmusic \(E-mail\)" <>
Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Mar 2017 15:06:28 -0000

Den 2017-03-03 kl. 14:49, skrev Eric Rescorla:
> On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund
> < <>>
> wrote:
>     Hi,
>     Last IETF meeting we had discussions regarding the security
>     considerations for the MID RTP header extensions regarding the need
>     for encrypting the RTP header. On Christer's request I have
>     attempted to capture what I believed was the outcome of this
>     discussion into a text proposal.
>     So the intention of the text is to capture the security
>     considerations, i.e. known risks and what we believe is necessary to
>     mitigate these risks. The conclusion of the discussion was that
>     encrypting the MID in RTP header extensions is not necessary, and
>     thus we have a conflict with the requirements in RFC 7941. I have
>     attempted to motivate and on that basis wavier this requirement for
>     this particular RTP SDES header extension. This is captured in last
>     paragraph of section 16.
>     The risk of implementation tracking lead us into a discussion around
>     a algorithm for generating MID Values. I have drafted a proposal for
>     such an algorithm in a new Section 14.1 inserted prior to the
>     existing one.
>     I note that in RTCWeb WG we did discuss that the encryption wavier
>     would be done in the security architecture. However, I believe in
>     retrospect that not covering this in BUNDLE in a common fashion
>     would be confusing and likely cause questions in regards to the
>     requirements of RFC 7941 when BUNDLE is used in other context than
>     WebRTC.
>     So please review and provide feedback. I know Christer wants to
>     close this issue.
>     14.1.  Generating Identification-tags
>        The identification-tag is exposed on the network layer due to the
>        SDES item and RTP header extension defined below.  As this exposes
>        the identification-tag beyond contexts where it is normally exposed,
>        i.e.  signalling layer additional potential for implementation
>        identification exists.  To avoid such risks a RECOMMENDED to be used
>        algorithm for how the identification-tag value is generated is
>        specified below.  Using this one will ensure that one can't identify
>        which of the implementations using this algorithm it is.
> If you mean which stack, I do not believe that this is actually that
> useful a design
> consideration. There are going to be a very large number of ways to
> fingerprint
> stacks. As the rest of the text seems predicated on that design
> objective, I do
> not think we should make this change.

Okay, what is your view on Section 16, if we remove the first sentence 
of the last paragraph that references 14.1?

We need to get the security considerations in BUNDLE into reasonable 
shape so that we actually can get BUNDLE published.


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: