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

Iñaki Baz Castillo <ibc@aliax.net> Mon, 19 March 2012 11:38 UTC

Return-Path: <ibc@aliax.net>
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 8AACC21F85DA for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 04:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level:
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 FYixil-vs9VW for <rtcweb@ietfa.amsl.com>; Mon, 19 Mar 2012 04:38:22 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC1BE21F85D8 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 04:38:21 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so7492803vcb.31 for <rtcweb@ietf.org>; Mon, 19 Mar 2012 04:38:21 -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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VT/UkjgulMWpB/IznOICOFtnYVQZGJv/ddpr/06HS44=; b=Zgt4Kgt1bnUWJn05OGo3A3g6NWnJ+NkDmDgPXl6HHqO/EGKF3nY63+Fr0Tv0PseA7z gidPUft5S/dFGmDkCs2w4U/drgQyMfBHV+LEmHc5wodGU0qmslqYAullv125r7xFH/92 bGz9KywE9YzvnsmcigaXlSkYm5f91LnWvO8ZYpSr51W514JUaSvZ5oA1JfwzoVdR/EMb Un/fDmC37yOWvs2oeEtKFUjXdbXOaLlymg7ibdZS0fFYdA6ksLaj/G4711qFdm05y/fX xfWOV1R7AEeGv8yILQy3PGPqxqGn0nUoKGfaZnXWhULMBYGbMe2/mPLgYGamRMrIF5Y2 6SkQ==
Received: by 10.52.90.111 with SMTP id bv15mr5606669vdb.34.1332157101351; Mon, 19 Mar 2012 04:38:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 19 Mar 2012 04:38:01 -0700 (PDT)
In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C113563C5A92@USNAVSXCHMBSA1.ndc.alcatel-lucent.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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 19 Mar 2012 12:38:01 +0100
Message-ID: <CALiegf=jtkDCS_D0ZFe9UpbiadQ0vsJ+4MppQSbLr-wbaXNrfQ@mail.gmail.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlFRX3FOrCJEC+yv3uJZp0FDheh1UYK5GoPD7o5BQAmXamAYf28e81h52y5sh2Wxtz1K/3c
Cc: "rtcweb@ietf.org" <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 11:38:22 -0000

2012/3/19 Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com>:
> RTP
>
> There are too many reasonable use cases for unsecured media for us to ignore
> them.

Which ones? I just see one: interoperability with legacy SIP devices.
The question is: does it make sense to create a new specification
(WebRTC) less secure that it can be instead of forcing SIP vendors to
implement SRTP in their devices? If SIP vendors assumed that their
devices would just work in trusted networks (or wallen gardens) that
should not affect the security aspects of a new specification made for
*Internet*. That's their problem (SRTP was initially defined for SIP,
so they must do their homeworks).

Is plain RTP an advantage for WebRTC? Not at all since WebRTC
implementations will support SRTP by design so downgrading to plain
RTP is never better than using SRTP. Even if you use an VPN for your
enterprise WebRTC application there is NO problem at all in using SRTP
over the VPN.

So instead of anecdotal usecases in which plain RTP is "good enough" I
would prefer to read the truth: "I am a telco/vendor and I want WebRTC
(a specification originally designed for Internet) to support plain
RTP so I can make business with my legacy and not secure SIP devices,
those that don't implement SRTP regardless SRTP was designed for SIP".



> The browser should be very clear when media security is unavailable
> and make it easy to prevent communication without media security (perhaps as
> a default setting), but there are legitimate use cases in various private
> environments (e.g., enterprise, jail) where media security may not be
> allowed (or must somehow be compromised), or is just not available, that we
> should just support straight RTP.  As long as the user can control the
> conditions under which media security is disabled, I do not see a problem.

I assume that finally plain RTP will be allowed in WebRTC, too much
interest in interoperability with legacy and non secure SIP devices.
However, adding more and more "security approvals" for end users in
their web browsers is much worse than mandating security by design.


Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>