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

Roman Shpount <roman@telurix.com> Mon, 19 March 2012 04:21 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 80C6A21F8510 for <rtcweb@ietfa.amsl.com>; Sun, 18 Mar 2012 21:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Level:
X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.245, 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 fybI-JlAkroV for <rtcweb@ietfa.amsl.com>; Sun, 18 Mar 2012 21:21:32 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 77DEC21F850D for <rtcweb@ietf.org>; Sun, 18 Mar 2012 21:21:32 -0700 (PDT)
Received: by dald2 with SMTP id d2so12413582dal.27 for <rtcweb@ietf.org>; Sun, 18 Mar 2012 21:21:32 -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=UdDKcej1BccMIrPLTyzjWhOkDVxXX3RUaIdGzzSdau0=; b=ZkmsEQkyzVDz+b/Gy44OCzqxZM1nOyCyDhi2nZ2sI2J8S30NdUQPLjmo/OU1kPwgFa Y+tQowNOKASCbcAB2gQOptieI9lWaB93c41uNl4WjfhuOf0cVEivxqc8RJpZ6GDSRIO3 RvYlRRpjWuIcVxfEpVnDWwQ0OJ78K8Pzeo2jXAj3EY6H1Y0dHZlvjgLk9u5jdgI5fo5l 0B8K2w+F2CchIeGvmSn7lUXTAu7WFkOatKa9SAVDlZDWX1Mk9XHe/h6Jy5pG2MbCVj6u JAMbdFI63+Y1eaBYgQ4VnNRoe9tcEjqmllKC3GHWoIfekcNCNYoj2L2xGM+i8L69p5zd doNA==
Received: by 10.68.130.67 with SMTP id oc3mr36004216pbb.147.1332130892060; Sun, 18 Mar 2012 21:21:32 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx.google.com with ESMTPS id x1sm10355336pbp.50.2012.03.18.21.21.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 21:21:30 -0700 (PDT)
Received: by dald2 with SMTP id d2so12413478dal.27 for <rtcweb@ietf.org>; Sun, 18 Mar 2012 21:21:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.132.99 with SMTP id ot3mr5301876pbb.160.1332130888556; Sun, 18 Mar 2012 21:21:28 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Sun, 18 Mar 2012 21:21:28 -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>
Date: Mon, 19 Mar 2012 00:21:28 -0400
Message-ID: <CAD5OKxuhiF9nasBsNpKH05d-Xt9LoD+ySHUvcxm3w=3rb8Oerw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="047d7b15a68b68219304bb90e4d8"
X-Gm-Message-State: ALoCoQkSuWJep192bowoHESv1vcftIsVHOzezC7W4fNwzSqrdkMRYEKalyrXCBhW9qboGZUeO5n2
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 04:21:33 -0000

+1
_____________
Roman Shpount


On Mon, Mar 19, 2012 at 12:10 AM, Ejzak, Richard P (Richard) <
richard.ejzak@alcatel-lucent.com> wrote:

> ** **
>
> I would like to argue two points: 1) DTLS-SRTP with IdP is the only media
> security scheme that rtcweb should support; and 2) rtcweb should also
> support RTP (no media security) with a clear requirement on the browser UI
> to warn the user of the complete lack of media security.****
>
> ** **
>
> DTLS-SRTP****
>
> ** **
>
> Some of the arguments made against DTLS-SRTP in recent emails are valid
> unless it is integrated with trusted IdP that is sufficient to verify the
> identity of the remote party.  With this one caveat, DTLS-SRTP is equal to
> or (mostly) better than SDES-SRTP in almost all respects (not to be
> repeated here).  Even if the identity is suspect, the IdP can at least
> provide some degree of assurance and accountability when an issue arises.
>  Without that, a user has no recourse when a problem develops.  ****
>
> ** **
>
> The key is that the browser UI must make clear to the user the identity of
> the remote party with whom media security has been established (even when
> it is a network gateway, in which case the identify of the gateway
> operator).  It should also be possible for the end user to mandate that a
> remote party identity is always verified before communication is allowed
> (perhaps even make this a requirement when media security is selected).
>  This is not too burdensome a requirement if established up front to help
> manage SPIT.  ****
>
> ** **
>
> When end-to-end security is possible, then ****Alice**** knows that she’s
> talking to Bob and vice versa.  ****
>
> ** **
>
> Even when ****Alice**** is talking to someone reached via the PSTN, she
> can know that she has a secure media connection to a gateway owned by a
> particular (the identified) operator, thus establishing a significant part
> of the chain of accountability.  We can’t improve on the security available
> through the PSTN, but we can improve on the security available to the point
> of interconnection with the identified operator (which may be different
> from the owner of the rtcweb application).  With DTLS-SRTP the user can
> have some basis for deciding whether to trust the identified operator; else
> (even with SDES-SRTP) you must completely trust the owner of the rtcweb
> application and there is no way to identify or verify any security
> attributes associated with the media.  ****
>
> ** **
>
> Finally, there are multiple reasons to avoid supporting multiple media
> security schemes.  It is difficult enough to expect the end user to make
> sure they are comfortable with the identity of the remote party of a secure
> media connection, but to ask if they are comfortable with an alternative
> media security scheme is simply too much to expect.  Bid-down attacks are
> just too easy and it is impossible to verify any remote party identity with
> SDES-SRTP.****
>
> ** **
>
> RTP****
>
> ** **
>
> There are too many reasonable use cases for unsecured media for us to
> ignore them.  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.****
>
> ** **
>
> Richard Ejzak****
>
> ** **
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>