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

Lorenzo Miniero <lorenzo@meetecho.com> Mon, 19 March 2012 19:58 UTC

Return-Path: <lorenzo@meetecho.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 3D1FC21F86E0 for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 12:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.569
X-Spam-Level:
X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 NrFSugoZksRC for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 12:58:47 -0700 (PDT)
Received: from smtplq02.aruba.it (smtplqs-out23.aruba.it [62.149.158.63]) by ietfa.amsl.com (Postfix) with SMTP id 88FA721F86D8 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 12:58:46 -0700 (PDT)
Received: (qmail 23783 invoked by uid 89); 19 Mar 2012 19:58:45 -0000
Received: from unknown (HELO smtp5.aruba.it) (62.149.158.225) by smtplq02.aruba.it with SMTP; 19 Mar 2012 19:58:45 -0000
Received: (qmail 10066 invoked by uid 89); 19 Mar 2012 19:58:45 -0000
Received: from unknown (HELO rainpc) (lorenzo@meetecho.com@79.52.20.203) by smtp5.ad.aruba.it with SMTP; 19 Mar 2012 19:58:45 -0000
Date: Mon, 19 Mar 2012 20:55:20 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Lorenzo Miniero <lorenzo@meetecho.com>
Message-ID: <20120319205520.491ed951@rainpc>
In-Reply-To: <20120319205207.1133e5b0@rainpc>
References: <4F4759DC.7060303@ericsson.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> <CAD5OKxvuEV8Vbq3h7=ZgcKmREjmguvz5n-SpXr2n-EY7a_ddxg@mail.gmail.com> <CALiegfk1ozOKPcDjbd3H_z2Edzh4RcZpYyJSWdw_1DJ04muQXA@mail.gmail.com> <CAD5OKxu8-+0O0=eE7mD1hi=nPUpEXczGj=bRNQCQL1BW8c-c-Q@mail.gmail.com> <52789D17-F7C7-401B-B2E8-6FE3BC5D7CB7@phonefromhere.com> <CAD5OKxtVtzahgk5xniXNvt-WvwNXZwcLau3PuKi1jnHrq4aZAA@mail.gmail.com> <CALiegf=xt1wAx8eid1M=wY0-wetmi9FOX+PoRF3iFd5UXmRgSA@mail.gmail.com> <20120319205207.1133e5b0@rainpc>
Organization: Meetecho
X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Rating: smtp5.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N
Cc: rtcweb@ietf.org
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 19:58:48 -0000

On Mon, 19 Mar 2012 20:52:07 +0100
Lorenzo Miniero <lorenzo@meetecho.com> wrote:

> On Mon, 19 Mar 2012 20:47:41 +0100
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> > 2012/3/19 Roman Shpount <roman@telurix.com>:
> > > Once again, my point was that application developer would need to properly
> > > develop signaling application (ie deliver it over HTTPS; don't put
> > > encryption keys into something that can be easily accessable, etc). Unless a
> > > lot of care is taken, SDES-SRTP is not secure.
> > 
> > Again in the airport with open WiFi:
> > 
> > - If you use SDES-SRTP and HTTPS (or secure WebSocket), so SDES keys
> > are not interceptable in the WiFi network, you can be sure that no one
> > in the airport can monitor your media (I assume the server is not
> > hacked by a person in the same airport!).
> > 
> > - If you use plain RTP you know that every one in the airport can
> > monitor your media (regardless there is TLS in the signaling path or
> > not).
> > 
> > 
> > 
> > > Why do we need to support SDES-SRTP at all?
> > 
> > In conjunction with a secure signaling path (HTTPS or secure
> > WebSocket) IMHO it provides a reasonable security level for avoiding
> > media interception.
> > 
> > 
> > 
> > > I do not understand the
> > > arguments that say RTP is bad, but SDES-SRTP is ok.
> > 
> > Replied above.
> > 
> > 
> > 
> > > If you need interop, RTP
> > > is your best option. If you need security DTLS-SRTP is your answer.
> > > SDES-SRTP does not serve either purpose well.
> > 
> > I'm not a fan of SDES-SRTP, I just say that IMHO it can provide a good
> > security level.
> > 
> > The only I say is that there is no reason for allowing plain RTP other
> > than interop with old/legacy SIP devices (those whose vendors have
> > decided not to implement SRTP, a spec from 2004). Is there any other
> > case in which using plain RTP within WebRTC context is better than
> > using SRTP?
> > 
> 
> 
> Large scale public events come to mind.
> 
> L.
> 


(even though, thinking about it, they're probably out of scope in here)

L.

> > 
> > Regards.
> > 
> > 
> > -- 
> > Iñaki Baz Castillo
> > <ibc@aliax.net>
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> -- 
> Lorenzo Miniero, COB
> 
> Meetecho s.r.l.
> Web Conferencing and Collaboration Tools
> http://www.meetecho.com
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com