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

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 05 January 2012 01:13 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 C44BD21F879F for <rtcweb@ietfa.amsl.com>; Wed, 4 Jan 2012 17:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.264
X-Spam-Level:
X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.334, 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 rijNUCI9tA3G for <rtcweb@ietfa.amsl.com>; Wed, 4 Jan 2012 17:13:58 -0800 (PST)
Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id B6BB721F85AF for <rtcweb@ietf.org>; Wed, 4 Jan 2012 17:13:57 -0800 (PST)
Received: from BLU152-W11 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 17:13:57 -0800
Message-ID: <BLU152-W1140980759D89AC3C1D0CA93940@phx.gbl>
Content-Type: multipart/alternative; boundary="_0c93deb6-fcea-466a-9f33-f50ef0ab7a7f_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: alan.b.johnston@gmail.com, roman@telurix.com
Date: Wed, 04 Jan 2012 17:13:56 -0800
Importance: Normal
In-Reply-To: <CAKhHsXHnT2p7yncha5-BQ=-Lzk3-N+tuijM-UqwfP1mPUi173A@mail.gmail.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>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jan 2012 01:13:57.0088 (UTC) FILETIME=[4C586600:01CCCB47]
Cc: rtcweb@ietf.org
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 01:13:58 -0000

> Here is the problem - allowing RTP opens up WebRTC to a bid down
> attack on media security. 

[BA]  There are a number of potential approaches that can minimize the
potential for bid-down while still preventing interoperability failure. 

Even if we assume all hosts implement SRTP with perfect interoperability
such approaches would still be necessary, if only to permit debugging and
minimize interop problems with respect to key management. 

As an example, it is possible to constrain an initial offer (e.g.
require RTP/SAVP(F) with some key management scheme), while
allowing fallback in the event of failure. 

The fallback could be to a scheme with lesser but still passable security
(e.g. from RTP/SAVP(F) with ZRTP or DTLS/SRTP to SDES), or it could
be all the way to RTP/AVP(F) if policy permits it and the user approves.  

> Mandating SRTP avoids both these problems.

[BA] If the problem were so easy to solve, why is AVT moving forward on
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ?

The reality is that RTCWEB cannot avoid grappling with the issues articulated
in that document, given the wide range of RTCWEB usage scenarios and the 
current state of implementations.   

By itself, mandating SRTP accomplishes as little (or even less) than mandating IPsec 
did within IPv6.  At the time of that debate, IKEv1 was widely implemented and even
IKEv2 was more widely implemented than either ZRTP or DTLS/SRTP
are today.  Yet because of the wide range of usage scenarios
"one size fits all" key management didn't work there, and as AVT has already 
recognized, it isn't likely to work here either. 

So yes, we can mandate SRTP.  In theory it isn't hard to implement and the
computational cost is low.  But let's not kid ourselves that this gets us very far
down the road to security and interoperability  in a wide range of RTCWEB 
scenarios.  Accomplishing this is with a single key management scheme is 
unlikely, for the reasons draft-ietf-avt-srtp-not-mandatory describes.   And if
you accept that (as AVT WG appears to), then we are left with the same question,
just one layer up.