Re: [rtcweb] RTP-IPSec vs SRTP-DTLS [was RE: Resolving RTP/SDES question in Paris]

Roman Shpount <roman@telurix.com> Tue, 20 March 2012 02:29 UTC

Return-Path: <roman@telurix.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 8777121F87D6 for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 19:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level:
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 l6BqDhi+jaw4 for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 19:29:18 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACAD21F87D3 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 19:29:18 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1541654pbb.31 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 19:29:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=CRyZg2BxvTnTO1n6Puew3XGQHhL+vktGqs+dYGW9cq8=; b=cnrqa2ntZTRzOIBjzVJdx6wjNp0TrODB32EsPLAgFkxa5eY9uAX8a2uFfmsoeXwRBm OUrgJDopV9IHy5ajO/4UiVMHKuKD+JYcBFLjJaYcgNUH9kJtHvKLADggBb6LQN1Zes8V X46R2s36UKbSQrhBsJmN/zxsysLaiSISeMXx5nK6ccspzK4CqxD3ck48Aljyc1C8joJl vUrtSdYR85kTxYsyNjEvY1fL5scWUvALZRnfzYau43QtSo1KLo8Yg13wdISJsNn3fFK/ 9k3MvmYe/5Y55mzjqLAovlHr4D+lZpKfdKAiDEVsRqJ0jKyfVp4VF8FHviSAQVNpAqmH roRg==
Received: by 10.68.125.168 with SMTP id mr8mr27727976pbb.21.1332210557992; Mon, 19 Mar 2012 19:29:17 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id 6sm132709pbh.65.2012.03.19.19.29.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 19:29:17 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1541639pbb.31 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 19:29:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.132.40 with SMTP id or8mr45013220pbb.34.1332210555703; Mon, 19 Mar 2012 19:29:15 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Mon, 19 Mar 2012 19:29:15 -0700 (PDT)
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE49@inba-mail01.sonusnet.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@phonefromhere.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> <D75A384B-0F38-4E30-8C03-12E903A69B64@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FFE49@inba-mail01.sonusnet.com>
Date: Mon, 19 Mar 2012 22:29:15 -0400
Message-ID: <CAD5OKxtabYKwSeM587HxDOdjfOX=AX9WawnT5UxSb5370FdjTA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="047d7b10cde3f052bd04bba370f9"
X-Gm-Message-State: ALoCoQnvl/loJmn+LvLb/mYpR1lamHfldP0OpIMzskJfxfvRonRpSF8YJzouPishQOUstZxEKUOT
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTP-IPSec vs SRTP-DTLS [was RE: 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: Tue, 20 Mar 2012 02:29:19 -0000

The reason is quite simple actually -- it is quite difficult to confirm
that IPSec is actually present. So browser has no way to determine that it
communicating over IPSec or plain IP.

On the other hand, I actually agree that if we are dealing with an
application on a private IP (like 10.X.X.X) you should be allowed to do
whatever you want. This is why I am proposing to support RTP for
applications delivered over HTTP. If you are in completely secure
environment and you do not want to do encryption, there is no reason why
the application should be delivered over HTTPS. If application is delivered
over HTTP, you either do no care about security (you are calling a public
radio) or security is provided by something else (you are sitting in the
bunker on the network not connected to the internet).

The large contingent of people on this list are convinced that upsides
(security) of requiring encryption outweigh downsides. The mentioned
downsides are:
1. Extra resource requirements. This is not really important as far as I am
concerned. New Xeon server can encrypt 39.7 GB/sec (
http://www.theregister.co.uk/2012/03/06/intel_xeon_e5_launch_event/)
2. Support for legacy devices. Also not as important since most legacy
devices will require a media proxy to support ICE anyway
3. Barrier to entry to develop new services. It is harder to debug and
develop new products if you need to develop larger number of protocols at
once. The understanding is that web browser will include some sort of
hidden setting that will allow plain RTP for debugging and development.
4. Encryption can be illegal or not allowed in some places, such as
military or prisons. Proposal is to enable some sort of configuration in
the web browser that will force it to send all the media through some sort
of recording/monitoring proxy.

While, as far as I am concerned, all of those arguments are addressed, my
main argument against requiring encryption is that there are scenarios when
it is not needed and not actually provided, primarily when application is
delivered over HTTP. All I am saying that if application developer does not
care about security, the application most likely would not be secure,
regardless of what we do. So why force it? Unless developer takes an effort
to buy an SSL certificate and deploy an app on a secure server, or gets the
certificate and sets up an identity provider, communication is not going to
be secure. If I am a high school kid trying to play with real time
communications using a free web hosting provider, I do not care about
security. All I care is that I can write something that makes a call. What
we are effectively doing is making this much more difficult. Innovation
does not have to come from serious projects created for serious purposes.
It often comes from things that are cobbled together and I want us to
enable this, unless it actually breaks something. I want to make WebRTC
easier to play with and hope that new exciting things will come out of this.
_____________
Roman Shpount


On Mon, Mar 19, 2012 at 9:53 PM, Ravindran, Parthasarathi <
pravindran@sonusnet.com> wrote:

> Hi all,
>
> Could you please let me know the reason why SRTP-DTLS alone MUST be
> supported by WebRTC web-browser and why not RTP-IPSec. In case my device
> support IPSec for all application, why web-browser has to mandated for
> double encryption. Another assumption here is that web-browser is endpoint
> (commercial browsers like chrome) which is not required as access entity
> (like Enterprise access router, SBC) shall acts as web-browser. So,
> web-browser point-to-point connection may be between employee browser to
> Enterprise access entity which is not required to be mandated as SRTP-DTLS.
> Hadriel mentioned large set of call centre solution wherein web-browser is
> just the endpoint, one way to access call centre and there is no need to
> change whole call centre architecture for the same WebRTC technology in
> case RTP-IPSec is supported by WebRTC browser running in IPSec mobile
> phone. I disagree with security advocates that all call centre using RTP
> will be broken as this security story does not sell well in the industry so
> far.
>
> Also, It is impossible to have the common UI by all web-browser and IETF
> specification should not try to find the way to solve that issue.
>
> My problem is not mandatory to implement SRTP-DTLS but the issue is at
> mandatory to use. IMO, RTP-IPSec should be allowed with user-consent in
> web-browser and don't argue that all web user in the world are dumb. In
> case the usecase is missing for RTP-IPSec as Randell mentioned, let us
> discuss in IETF-83 RTCWeb meeting.
>
> Thanks
> Partha
>