Re: [rtcweb] No Interim on SDES at this juncture

Dan Wing <dwing@cisco.com> Thu, 13 June 2013 19:14 UTC

Return-Path: <dwing@cisco.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 89CCC21F9AC8 for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 12:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level:
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 hUCaRAVb0THh for <rtcweb@ietfa.amsl.com>; Thu, 13 Jun 2013 12:14:30 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7021F97CA for <rtcweb@ietf.org>; Thu, 13 Jun 2013 12:14:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2318; q=dns/txt; s=iport; t=1371150870; x=1372360470; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Zwr8FB4+RAHWiOpPgTyzjdvj4qr9e9ktaEXt23SyHgE=; b=aatyZm3ulkw4ky5/KmnNs8wL4cx+GtYYcldyzwr9LoO5PxxPTgkq9hdt 0QqUMjRyWXsQlPZOMnOiLPcoKGoWONs3bAMGVoownbnu/yPEDgLW1Gzjt fGzSOqRJOQr12vzHHi4C8M87dY6hECtzcSsb4Q0ANeYLNqJxzSFdePTt7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAKEZulGrRDoG/2dsb2JhbABbgwkwvwaBAhZ0giMBAQECAQEBAQE3LgYLBQsLGC4nMAYTCRKHbQUNu1COHnIzB4J/YQOJII4hkUKDLxyBLg
X-IronPort-AV: E=Sophos;i="4.87,860,1363132800"; d="scan'208";a="83461405"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Jun 2013 19:14:28 +0000
Received: from sjc-vpn2-277.cisco.com (sjc-vpn2-277.cisco.com [10.21.113.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5DJERr2011883; Thu, 13 Jun 2013 19:14:27 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <51B9C244.9050705@alvestrand.no>
Date: Thu, 13 Jun 2013 12:14:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4044A48-8EBC-4AF4-A235-47DEC1719D07@cisco.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <CA+9kkMDY2Z_5_1uYJ1K_ZmrJB2a1-RE7V3aPqNHQg82DyagjCg@mail.gmail.com> <2975A93F-44DA-4020-B4DE-42E7ED98C08F@oracle.com> <CABkgnnXr+zUW5mUn1nGwz9nxtY29JT5Cz=_84DB_ZxbZGa-kBA@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF115C8A0F@MCHP04MSX.global-ad.net> <B7D2D5A3-586A-4846-904D-D2D3E6882500@phonefromhere.com> <51B9C244.9050705@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1508)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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, 13 Jun 2013 19:14:34 -0000

On Jun 13, 2013, at 5:59 AM, Harald Alvestrand <harald@alvestrand.no>; wrote:

> On 06/13/2013 01:07 PM, Tim Panton wrote:
>> I fear it just _looks_like_ the primary interop issue.
>> 
>> As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without
>> the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)

It was my presentation at IETF83 in Paris.

>> Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES.
>> 
>> The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay.
>> 
>> I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway.
>> Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.
> 
> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.

Right -- EKT is what makes the flames go away.  Slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf shows the flames, and the flames go away when we add EKT on slide 33.


> 
> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.
> My impression from the performance numbers people have quoted is that the CPU cost of decrypt/encrypt doesn't cost enough to be the deal-breaker between "viable solution" and "not viable solution"; other things weigh far more on capex/opex.
> 
> The architectural/non-cost argument I see against decrypt/encrypt is "the gateway wants to be able to disclaim the ability to look at the bits".
> 
> Agree with Tim about the relative difficulty of adding the needed features.

-d



> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb