Re: [rtcweb] SRTP not mandatory-to-use

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 05 January 2012 07:42 UTC

Return-Path: <bernard_aboba@hotmail.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 40AE221F85D4 for <rtcweb@ietfa.amsl.com>; Wed, 4 Jan 2012 23:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.309
X-Spam-Level:
X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 A69VkXnVBkpM for <rtcweb@ietfa.amsl.com>; Wed, 4 Jan 2012 23:42:27 -0800 (PST)
Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48C21F85BE for <rtcweb@ietf.org>; Wed, 4 Jan 2012 23:42:27 -0800 (PST)
Received: from BLU152-W63 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 23:42:27 -0800
Message-ID: <BLU152-W639789FD5D98B9B8FAEA5593940@phx.gbl>
Content-Type: multipart/alternative; boundary="_d85fc532-a32b-452b-9974-70ff7d63566f_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: randell-ietf@jesup.org, rtcweb@ietf.org
Date: Wed, 04 Jan 2012 23:42:26 -0800
Importance: Normal
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com>
References: <CAErhfrwu322=HTS0JZhum9EGfb73KmYS6CU_KMESyzEWhtvg2w@mail.gmail.com>, <CABcZeBOeg-O+6===5tk0haxC8nLxUQyEUFRES2FAoFEf00fKng@mail.gmail.com>, <CAErhfrxTKdo7Z+61x5ZcDt5ZM7C7ob5LNxMzwng_kk3Uqrp2_Q@mail.gmail.com>, <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, <E44893DD4E290745BB608EB23FDDB762141EF8@008-AM1MPN1-042.mgdnok.nokia.com>, <4F035DD5.3050305@jesup.org>, <CAOJ7v-1dziaA_ePCuMxjn6uhBgOH=ZVybUmLBwQi5qiuyOzDMA@mail.gmail.com>, <BLU152-W469B2EB104C104547FC42393960@phx.gbl>, <CAD5OKxuE0VhSsjKggj1mLOseLeDXarujvAG44yHkuZttagJggw@mail.gmail.com>, <CAKhHsXHnT2p7yncha5-BQ=-Lzk3-N+tuijM-UqwfP1mPUi173A@mail.gmail.com>, <CAD5OKxuH4v2Cs4Wx2SermhqX0SdH_rXUYgMms1UV3xo1_EsN-Q@mail.gmail.com>, <CA+9kkMCXACEo0QOLR-pw0AHuRJzKuKEiL7E5Oh8va9wWuFmbow@mail.gmail.com>, <BLU152-W587F56E976F80F9BA6308493940@phx.gbl>, <CAD5OKxtkKxUC2RNibk-9+R8LqVdsaY_19DCgB=rFDjpxQVGCnQ@mail.gmail.com>, <4F052B03.8090101@jesup.org>, <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jan 2012 07:42:27.0259 (UTC) FILETIME=[924A38B0:01CCCB7D]
Subject: Re: [rtcweb] SRTP not mandatory-to-use
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, 05 Jan 2012 07:42:28 -0000


> If you mandate SRTP (and use DTLS-SRTP), then the application and the
> website never have access to the keys, and you have end-to-end security
> (modulo gateways).  

[BA] That depends very much on the exact design of the system.  Within
RTCWEB the term "DTLS/SRTP" is potentially describing a system
different from the framework used in SIP, if signaling is done out of band (e.g.
we're not assuming that RFC 4474 is being implemented). 

If signalling is out of scope (e.g. SIP is handled in Javascript), then one cannot make 
the same claims about overall system security as one could with a SIP implementation. 
The same thing is true with respect to ICE, by the way -- once you remove signalling
from the scope, the security properties change (e.g. the browser doesn't get to examine
the SDP offer/answer exchange if signaling is done out-of-band).  

> If you combine that with the identity mechanisms
> from ekr's draft/presentation at Taipei, and you have verified, no MITM,
> end-to-end encryption.  

[BA] I would characterize the current draft as lacking in details, frankly.   Do we 
really think that this will be implemented in version 1.0?  If not, then what keying
mechanism do we use along with the "mandatory to use SRTP"?   From my
perspective, making SRTP "mandatory to use" is not very helpful unless we
are clear about how the keying is done.  We don't need to repeat the IPsec/IPv6
experience.