[rtcweb] 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

邓灵莉/denglingli <denglingli@chinamobile.com> Mon, 21 May 2012 09:55 UTC

Return-Path: <denglingli@chinamobile.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FAA21F8592 for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 02:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.966
X-Spam-Level: ****
X-Spam-Status: No, score=4.966 tagged_above=-999 required=5 tests=[AWL=4.891, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp90LGDt66q2 for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 02:55:12 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8421F8573 for <rtcweb@ietf.org>; Mon, 21 May 2012 02:55:12 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 13C61E5FD; Mon, 21 May 2012 17:55:10 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id E64D6E5EE; Mon, 21 May 2012 17:55:10 +0800 (CST)
Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052117400872-19054 ; Mon, 21 May 2012 17:40:08 +0800
From: 邓灵莉/denglingli <denglingli@chinamobile.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com>
In-Reply-To: <4FB9E79C.1050300@ericsson.com>
Date: Mon, 21 May 2012 17:37:01 +0800
Message-ID: <00da01cd3735$467b6a20$d3723e60$@chinamobile.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHJe2ybuQ
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-21 17:40:08, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-21 17:55:10, Serialize complete at 2012-05-21 17:55:10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Content-Language: zh-cn
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18918.006
X-TM-AS-Result: No--29.301-7.0-31-10
X-imss-scan-details: No--29.301-7.0-31-10;No--29.301-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: rtcweb@ietf.org
Subject: [rtcweb] 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2012 09:55:13 -0000

Agreed.

-----邮件原件-----
发件人: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] 
发送时间: 2012年5月21日 14:59
收件人: 邓灵莉/denglingli
抄送: rtcweb@ietf.org
主题: Re: 答复: [rtcweb] Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

On 2012-05-21 03:44, 邓灵莉/denglingli wrote:
> Hi, Magnus
> 
> It seems to me that there may be another security threat in 
> multi-party applications of COP, where an entity needs to combine 
> multiple sets of requested parameters, than the one discussed in the draft.
> That the initial downgrading of the combined potential ceiling for 
> collected parameters for media quality (codec capabilities plus COP 
> parameters as stated in Section 5) through SDP transaction by a malicious participant.
> Unlike the one stated in Section 8, the latter behavior only happens 
> once and could neither been distinguished afterwards as "actively 
> harmful" nor to be ignored in order to serve actually poorly-equipped users.
> Would that be an issue?
> 

Yes, this is clearly a security threat to the complete solution. Not that it is specific to codec control. It is a threat to all things expressed in the SDP, like which codecs being used, security mechanism is negotiated etc.

In the WebRTC security architecture my undestanding is that it so far are a deliberate choice of allowing the JavaScript and the web browser to be allowed to modify the SDP if desired by them. Thus a security model based on hop by hop security for the JSEP/SDP messages has been selected. For example the usage of HTTPS / Websocket over TLS can provide the security to prevent third parties not directly addressed from seeing and affecting the JSEP/SDP messages.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


__________ Information from ESET NOD32 Antivirus, version of virus signature database 7138 (20120515) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com