Re: [rtcweb] New use-case proposed

"Dan Wing" <dwing@cisco.com> Sat, 12 May 2012 01:41 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 C1D1921F8627 for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 18:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.397
X-Spam-Level:
X-Spam-Status: No, score=-110.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 uxJnLcGXVtjg for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 18:41:15 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDB21F8624 for <rtcweb@ietf.org>; Fri, 11 May 2012 18:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2158; q=dns/txt; s=iport; t=1336786874; x=1337996474; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=tzeK4gP2QKzJFhEU3AX5wI8mm5WStvAg2nTHnJD781A=; b=Loecv5lWhm6P/8gjCgwmR3v4TknfQOEVq50jA1GoKLDoojNG7iqmo+YP vQ7p0ezUcfwKq7Fxf96Yq+MikLmhnOpAW1mUugFKpRwPSsHNZkkHUdVU5 cEoqg1qs35GVKR1QDPTD542FFusuw6/q0kx0yWaQ8dApABlZz3qbs5TgK I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikFADS/rU+rRDoI/2dsb2JhbAA7CaM8kDSBB4IVAQEBAgEBAQEBBQoBF0QLBQcBAwIJDwIEAQEBJwcZCAYVCgkIAQEEEwkCF4deAwYEDJshlgENiVOKKW4QCYVvBIgwNIUWk0CDGoFpgwmBPw
X-IronPort-AV: E=Sophos;i="4.75,574,1330905600"; d="scan'208";a="41384919"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 May 2012 01:41:14 +0000
Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4C1fEpx030078; Sat, 12 May 2012 01:41:14 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Marshall Eubanks'" <marshall.eubanks@gmail.com>
References: <4FAD0D8C.7020701@ericsson.com> <4FAD3C87.8080908@alvestrand.no> <27AFC26D-064F-4B33-92B3-2889170A88C1@ericsson.com> <4FAD7BFE.10905@alvestrand.no> <16EBFBCB-20CB-4E2D-9ECD-575CB9DD2A79@ericsson.com> <103f01cd2fc4$e5c80980$b1581c80$@com> <CAJNg7VLGFCKecujqyf8v3+S9bGNOcOKYQD1mLTJuHJ_Tq+Ry8g@mail.gmail.com>
In-Reply-To: <CAJNg7VLGFCKecujqyf8v3+S9bGNOcOKYQD1mLTJuHJ_Tq+Ry8g@mail.gmail.com>
Date: Fri, 11 May 2012 18:41:13 -0700
Message-ID: <10c501cd2fe0$5108bf80$f31a3e80$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0v3DCzU9ZyfVwAQ3aNijNYyKtCcQAAyCPg
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New use-case proposed
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: Sat, 12 May 2012 01:41:18 -0000

> -----Original Message-----
> From: Marshall Eubanks [mailto:marshall.eubanks@gmail.com]
> Sent: Friday, May 11, 2012 6:12 PM
> To: Dan Wing
> Cc: Göran Eriksson AP; Harald Alvestrand; rtcweb@ietf.org
> Subject: Re: [rtcweb] New use-case proposed
> 
> On Fri, May 11, 2012 at 6:24 PM, Dan Wing <dwing@cisco.com> wrote:
> >> Personally, I would like to us to ensure we have at least have a
> good
> >> foundation for multicast later.
> >
> > EKT, draft-ietf-avt-srtp-ekt, does that, and works with the initial
> > keying being Security Descriptions (should we allow that in RTCWEB)
> > and with DTLS-SRTP.
> 
> Note : This draft expired last week.  I presume that is not truly
> indicative of its status.

We are integrating the changes described in 
http://www.ietf.org/mail-archive/web/avt/current/msg15232.html,
which I summarized in my RTCWEB presentation, starting on
slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

In that deck, slide 28 shows the problem of interworking DTLS-SRTP
with Security Descriptions -- namely, that something needs to 
decrypt and re-encrypt SRTP packets in one direction.  This is shown
with flames coming out of that box.  (Its CPU is on fire.)

Slide 31 explains how EKT helps that interoperation.

Slide 33 shows how the interoperation, where the box no longer
has to decrypt/re-encrypt SRTP packets.

It was asked if we can do that interworking, between Security
Descriptions and DTLS-SRTP-EKT, without the media flowing through
a box.  Yes, we can -- except for EKT key changes (that is, key
changes from the WEBRTC side).  I have a design that will 
handle that.  But folks still need to digest the interop model
and decide if allowing SDESC on the WEBRTC side is worth the
permanent interoperation burden (on all WEBRTC endpoints) and
worth the permanent reduction of identity and of media 
encryption security.

-d


> Regards
> Marshall
> 
> >
> > -d
> >
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb