Re: [clue] Comments on CaptureID and security

Magnus Westerlund <> Thu, 23 February 2017 08:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FE4C12A14C for <>; Thu, 23 Feb 2017 00:32:41 -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 Ynhx613yKt8m for <>; Thu, 23 Feb 2017 00:32:39 -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 7DBD4129C60 for <>; Thu, 23 Feb 2017 00:32:39 -0800 (PST)
X-AuditID: c1b4fb2d-18e0e98000005112-99-58ae9e25e8b7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 27.B6.20754.52E9EA85; Thu, 23 Feb 2017 09:32:37 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Thu, 23 Feb 2017 09:32:30 +0100
To: Roni Even <>, "" <>
References: <> <> <> <> <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Thu, 23 Feb 2017 09:32:30 +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+NgFtrLLMWRmVeSWpSXmKPExsUyM2J7lK7qvHURBh1LDC32n7rMbLF/8Xlm i0/HzrM4MHu0HHnL6rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4Mm5NyC6YIFRxZccD9gbG u3xdjBwcEgImEp3nk7sYuTiEBNYxSjycvpoRwlnOKPHs/gXmLkZODmEBfYnVy+awg9giAq4S RxbsY4couswkseXPS3aQScwCGhJNEyJAatgELCRu/mhkA7F5BewlZl58xwJiswioSky5uxLM FhWIkdjbf58JokZQ4uTMJ2BxToEQiQkXz7GC2MxAc2bOP88IYctLNG+dDXaPkIC2RENTB+sE RoFZSNpnIWmZhaRlASPzKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAQD245bfuDsbVrx0P MQpwMCrx8BYsXxshxJpYVlyZe4hRgoNZSYQ3a/a6CCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 ZivvhwsJpCeWpGanphakFsFkmTg4pRoYVxbs/lFzu7ngypYLN73z5+9VOBA3c//Nyhf7eVYn XnvrXyMvbTBbcvob3yts/w9yzZ61nWHRW+W5EzY+rGNNSLwYtHHHgrNtuxXmqKuoL2/cFbLs z5Ibtkv+/1v8NMcpL+CE8te693mrPFScPxua/AisfXhK4R3H//nKZ9JOeb6vuPaoibv0/kkl luKMREMt5qLiRAAYs/ehUAIAAA==
Archived-At: <>
Cc: Jonathan Lennox <>
Subject: Re: [clue] Comments on CaptureID and security
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 08:32:41 -0000

Hi Roni,

Den 2017-02-12 kl. 10:26, skrev Roni Even:
> Hi Magnus, About the requirement to encrypt the RTCP (do not use NULL
> security profile) I was wondering why it is not mention also on
> RTCPweb, is it because RTP/RTCP multiplexing? I think that it should
> be mentioned also there since there is option to support non
> multiplex RTP/RTCP

That is actually a shortcoming of RTCWeb Security architecture and there 
exists an tracked issue for it:

So, yes, I would really like to see the communication security section 
mandate encrypted RTCP. This due to the information included in RTCP 
about the application. The protection profile mandated does imply equal 
strength RTCP protection, but if one uses other profiles it might not be 
as clear cut. So a wording on protecting RTCP at same or similar 
protection strength to RTP I think is motivated.

What I also think is missing in the new text is discussion of RTP header 
extension encryption, i.e. RFC 6904. I thought the conclusion on the 
capture ID is that there is no strong generation requirements to ensure 
they don't contain privacy sensitive information. And it definitely 
reveals what is happening in the application context to third parties. 
Thus, I think encrypting the RTP header extensions would be good 
practice in clue situations.

I also reacted to the use of "untraceable" in this sentence:

CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as
    specified in [RFC7022], resulting in untraceable CNAME values.

The point of them is that they are not long term persistent and thus 
can't be used for long term tracking of the user. Writing "untraceable" 
I would interpret as indicating a stronger user protection then what is 
actually provided.

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: