IETF Logo Mail Archive

Re: [rtcweb] Resolving RTP/SDES question in Paris

Tim Panton <tim@phonefromhere.com> Mon, 19 March 2012 18:35 UTC

Return-Path: <tim@phonefromhere.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 6F57F21F8811 for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 11:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 KvLrk+WSro2L for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 11:35:21 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id A419F21F87FD for <rtcweb@ietf.org>; Mon, 19 Mar 2012 11:35:21 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 9E47237A902; Mon, 19 Mar 2012 18:47:54 +0000 (GMT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-45--459885433"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <CAD5OKxu8-+0O0=eE7mD1hi=nPUpEXczGj=bRNQCQL1BW8c-c-Q@mail.gmail.com>
Date: Mon, 19 Mar 2012 18:35:16 +0000
Message-Id: <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <CAD5OKxvZbEJ7sV4WPAYoQapzMR_QwAftj-oKg=ioMKHNT792wQ@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <CALiegf=jtkDCS_D0ZFe9UpbiadQ0vsJ+4MppQSbLr-wbaXNrfQ@mail.gmail.com> <BLU169-W29E5B86F9E2C6F3126961C93420@phx.gbl> <CALiegfk2aT+6Psr4nT-hG1G7eYRBfFCcT+25On2O4HfUXJ6-ng@mail.gmail.com> <CAD6AjGSmi9j+sdGWPts20-iwGvGij05ek0OKYEPULC6B=aFpQg@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C113564482A7@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <ADBB75F3-E20C-4EC4-B9C3-EF2E4BFF409C@phonefr omhere.com> <CAD5OKxvuEV8Vbq3h7=ZgcKmREjmguvz5n-SpXr2n-EY7a_ddxg@mail.gmail.com> <CALiegfk1ozOKPcDjbd3H_z2Edzh4RcZpYyJSWdw_1DJ04muQXA@mail.gmail.com> <CAD5OKxu8-+0O0=eE7mD1hi=nPUpEXczGj=bRNQCQL1BW8c-c-Q@mail.gmail.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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, 19 Mar 2012 18:35:22 -0000

On 19 Mar 2012, at 18:15, Roman Shpount wrote:

> I do not see the difference, as far as security is concerned, between SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons, we might as well allow plain RTP. It would be compatible with more devices and as insecure as SDES-SRTP. There is no requirement that WebRTC application must use HTTPS for signaling. If the application is using HTTP, all the "sitting in the airport" examples are as unsecured with SDES-SRTP as they are with plain RTP.


How many of these plain RTP only legacy devices support password verified ICE correctly? - I'd be shocked if you found _any_. 

With JSEP there is nothing to stop the application from encrypting the SDP blob in javascript before forwarding it to the far end 
over HTTP - not my preferred option, but technically possible, and it would definitely make a firesheep style attack a bit harder to 
pull off.

Tim.

v2.23.0 | Report a Bug | By Email