Re: [rtcweb] Consensus call regarding media security

Roman Shpount <roman@telurix.com> Thu, 29 March 2012 14:20 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 AEFF521E8194 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 07:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 5qqa-X4D+H90 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 07:20:47 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A68DF21E8187 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 07:20:47 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so1622163yhk.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 07:20:30 -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=virvy2+AAi3j0jlyIi7xK4A813IT46aqdVPx+qsu/Vo=; b=lJbP94KYL+MxiTiDFMHmrjszGcq0oqPFZ7I4OdTnIZrlsts2i/okryWSFHkX+VqGTH TIIcDZgopR2sADX2XTljU8zzRpPF6G6PjSPB2i9MAH666IMpr3vU3bqGTSM5g4PhDxly yMwXTiOoFSJsr9iMmuXcSwNYv/dTbQ7wtuePX98FFmqkL9VpTT6lRe6tGBu4AqLYqxZv UZCc9GmJDAyS4TYtsMgZN7IRxSMrLxat8W9AjE6EGYYjttdu94EI/8H8cwZ5T/sMbaCG +QLyLl5HJ4AG7q8kOc+3kko6crCSVYLsT4ZUnCtES/Z027N9Q43TiJCjJjMLPgPXqv/x Bo4w==
Received: by 10.236.200.197 with SMTP id z45mr34152762yhn.99.1333030830707; Thu, 29 Mar 2012 07:20:30 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id 2sm8077854ane.12.2012.03.29.07.20.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:20:30 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so1622143yhk.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 07:20:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.230.99 with SMTP id sx3mr388371pbc.55.1333030829042; Thu, 29 Mar 2012 07:20:29 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Thu, 29 Mar 2012 07:20:28 -0700 (PDT)
In-Reply-To: <CALiegf=gZs_h4SqvQgwrb1Nec7TZZ6rpHRHgyKGVYtvED78jpw@mail.gmail.com>
References: <4F732531.2030208@ericsson.com> <CAD5OKxs6NHha2egNSTumEaHYJ0bB6qu_nfshmBM6dntx2n49HQ@mail.gmail.com> <CALiegfn4MZYb-qCnM62T7w4EgWqrC5baN+pAYBZF84kEA7Ko6A@mail.gmail.com> <CAD5OKxtDED1vSFrw4V9TKkUzdSSXNg+S_WBrxmnFo21hjJvqMA@mail.gmail.com> <CALiegfkmckSar175LDYouvPkp0Vm1QCKhmTuiGNnD62QTDhamg@mail.gmail.com> <CAD5OKxur4FKAw8PprjfxLQVekmOWGuQegqN02mHsP+Hr-k_UNg@mail.gmail.com> <CALiegf=gZs_h4SqvQgwrb1Nec7TZZ6rpHRHgyKGVYtvED78jpw@mail.gmail.com>
Date: Thu, 29 Mar 2012 10:20:28 -0400
Message-ID: <CAD5OKxv=AFdAxcvo7T39SJ5+hC6MaQ3ZEkfDDRpsk1T35Eeb_Q@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=047d7b2edf030a2c5704bc626dec
X-Gm-Message-State: ALoCoQmEYyzhSuinN8wUVLucXttv5KZRY5U0mH8dKf1s55iHtCc8rV7uDtbhu5qYHAZ4XOLbe9zD
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consensus call regarding media security
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: Thu, 29 Mar 2012 14:20:49 -0000

On Thu, Mar 29, 2012 at 8:14 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> Roman, you still don't want to see my simple example. Could you please
> reply to the following two questions rather than avoiding them?:
>
> 1) Why is better to use plain RTP in an open WiFi network (airport)
> rather than using SDES-SRTP?
>

I did not say that use of plain RTP is better in an open WiFi. what  am
saying that if I am communicating with a large number of applications it is
no worse. For me, anything that can cause protocol not to work or to be
used for some sort of an attack goes under MUST. Anything that is nice to
have should be under SHOULD. From my point of view security is a SHOULD.


> 2) Why is plain RTP better than SDES-SRTP in any other case?
>

In case of an enterprise network, their security concerns are not about
user privacy (it is not end user equipment in a first place) but adherence
to corporate standards or ability to monitor. In such cases SRTP is a
liability, not an asset. In Flash, in HTTP, in email, encryption is
optional. If you have anything where encryption is mandatory while
communicating with an external party, it is not acceptable in a lot of
enterprise or government environments. My goal is to have WebRTC
functionality available in as many places as possible, even if it means
giving up encryption in some cases.

Developing new applications is harder. If you are building a speech
recognition engine, you often need to add media support. Adding encrypted
media support is much harder. I want people to build new things with the
minimal effort, even just to educate themselves or to try new things. This
is what makes progress possible. The more things we pile up in front of
this, the harder it would be for people to do new things.


> > No encryption often means better security.
>
> Sorry, I don't agree. Encryption is not enough, of course, but it's
> better than nothing (and again: the open WiFi network in the airport).
>
> > Bot nets use encryption to
> > communicate, it does not mean they enable user security.
>
> 1) User identity authentication/validation and confidentiality
> (encryption).
>
> 2) Just confidentiality (encryption).
>
> 3) Nothing.
>
>
> 1 is better than 2 and 2 is better than 3.
>
>
>
> > In a lot of cases
> > ability for the user to check what exactly they are communicating and to
> > whom is security. As a security conscious person I do not want encrypted
> > communication from my computer or my network unless I know exactly who
> it is
> > going to. If I do not have to I would prefer my communications to be
> > unencrypted.
>
> Sure, but you are advanced user and I hope you are not talking in
> behalf of the 500 millions of Facebook users in the world.
> So you will be able to enter into your browser about://config and set
> a null crypto key for SRTP (so you get plain RTP and can debug it or
> whatever). This is confirmed to be the expectation of two browser
> vendors.
>
> And you are missing a point completely. If I am operating a corporate
network with 50,000 computers, do I need to go into about://config for all
of them? If I am put into this situation, I would just disable WebRTC
completely and call it security. This is exactly what I am trying to avoid.


>
> >> RFC 3711 was created in 2004, 8 years ago!
> >>
> >> Which "new" application you mean if it's not capable of implementing a
> >> simple specification from 2004? how "new" is it? is it really new? or
> >> is it a "SIP voicemail server" made in 2002?
> >>
> > Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those
> use
> > libsrtp. For all of them SRTP is broken. Not a single one of them
> bothered
> > to check or only recently detected problems
> > (https://issues.asterisk.org/jira/browse/ASTERISK-16665).
>
> I expect that, once SRTP becomes widely extended (thanks to WebRTC),
> developers will really want to fix their SRTP support, including
> libsrtp. But we cannot make a *new spec less secure than it can be
> just due a to a bug in a opensource library.
>

The issue is most of the developers would just look at this as a hurdle to
interop with WebRTC, instead of the enabling the security. If security
implementation is not taken seriously, you often end up with something that
can communicate but not really secure. For instance you can use a bad
algorithm to generate encryption keys and end up with keys that are easily
predictable. Result -- encrypted but unsecured traffic. Encryption should
be something that application developers can turn on or off, but unless
they want it, forcing support for it is a fulls quest.


>
> >> Sorry but I still see *no* argument at all in favour of allowing plain
> >> RTP in WebRTC. And AFAIK there is already consensus about it: plain
> >> RTP is not allowed.
> >>
> > I do not see an argument why RTP should not be allowed. I think you are
> > arguing we should require a feature (SRTP) for the sake of requiring a
> > feature.
>
> I still don't understand why everyone in an airport should be able to
> intercept my audio/video communication with a simple RTP sniffer.
>

There are enough cases where I or other users do not care if this happens,
so I think that encryption should be a SHOULD.
_____________
Roman Shpount