IETF Logo Mail Archive

Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Emil Ivov <emcho@jitsi.org> Mon, 29 April 2013 11:38 UTC

Return-Path: <emil@sip-communicator.org>
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 BCBAC21F997A for <rtcweb@ietfa.amsl.com>; Mon, 29 Apr 2013 04:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 z6KoG2t0lUKp for <rtcweb@ietfa.amsl.com>; Mon, 29 Apr 2013 04:38:23 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4E24E21F9814 for <rtcweb@ietf.org>; Mon, 29 Apr 2013 04:38:21 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id s10so5107907wey.7 for <rtcweb@ietf.org>; Mon, 29 Apr 2013 04:38:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=YqDvzfvCPmcbrM/JeOvOBhblL98SCVjeqSP+V3LUCPo=; b=WMpRYC3XUquC4rsZxE7KG1SWW12XRsfHYxh2tbdjNigchPb42EpnCLhMzjDxOS8M2j YuI782Ezkn/HuifuzeAny3OvWB2ykIWHGsb8Qx/7QP+aeZTq5i2RkHAS7TfLduSo2C1M xdxkEq5mmoeLPe1p7RlP5AQNhiWPG1CgNHFhnS0zTj4K193mm9NxwUpDXR7aoftbFyFe sdHsJmkhp62/Ka2EovFo6o4e5F44Q8Vo8HubUJ7x4mnirJZ2/mKpq51PYPWQmRvXoJPC TWsPaWkKUjJePfDixeF9Rt7tgwZ1Gq9eym8PKWt1lLDbzkJ5hakwO4dgJl67teRotsUe VTEw==
X-Received: by 10.180.187.206 with SMTP id fu14mr16993363wic.11.1367235487414; Mon, 29 Apr 2013 04:38:07 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPSA id o3sm21710409wia.2.2013.04.29.04.38.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 04:38:06 -0700 (PDT)
Message-ID: <517E5B9D.50001@jitsi.org>
Date: Mon, 29 Apr 2013 13:38:05 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Tim Panton <tim@phonefromhere.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <517E0322.2060303@oracle.com> <53B9C161-C492-4F07-A9BD-75E17AE79AC9@phonefromhere.com>
In-Reply-To: <53B9C161-C492-4F07-A9BD-75E17AE79AC9@phonefromhere.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm0Gw+lgBwu8C9bUT7Pp3SSoX3Ky0qxw3IjJL51EtA6mCj3sL3h4dIXvzOc06cNBgutyQVG
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
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, 29 Apr 2013 11:38:24 -0000

On 29.04.13, 12:30, Tim Panton wrote:
> 
> On 29 Apr 2013, at 06:20, Binod wrote:
> 
>> I have been reading the discussion on this topic and I prefer
>> supporting SDES as a keying method for WebRTC.
>>
>> Not having SDES will have non trivial impact on interop. With
>> EKT, there is a signalling complexity of sending re-INVITEs, which
>> make the gateway complex. Without EKT, you need per-packet
>> crypto  for media exchange, which is CPU intensive.
> 
> I've seen this asserted more than once, but I'd love to see a _current_ example where 
> you really have an existing network of SRTP/ICE/BUNDLE/RTCP-MUX capable
> legacy endpoints

Well, in all fairness it would only have to be SRTP/ICE, bundle and
rtcp-mux being optional, wouldn't it?

The above is already a more common combination.

Besides, ICE is easily handled by a light-weight gateway that would only
add a relayed candidate and that doesn't need to understand any sort of
encryption.

Emil

-- 
https://jitsi.org

v2.23.0 | Report a Bug | By Email