Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

Roman Shpount <> Thu, 05 April 2012 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D90C621F860E for <>; Thu, 5 Apr 2012 11:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uYG1CNrUv49T for <>; Thu, 5 Apr 2012 11:14:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 365A821F8604 for <>; Thu, 5 Apr 2012 11:14:08 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1716939pbb.31 for <>; Thu, 05 Apr 2012 11:14:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4HxyOPPOZ/O5Qlnt630omUp+C32c/MqmgjnS1/vlYsc=; b=DqWlKRfFfL1rBHyicn+ANvu95SZ9hGsSKIqHR7z2SxiJqWbT/FI00FE2pyWNapHfQq JUOea3yjnWpkXZQ63Tsf/FquKhoqzBkIrdSXgSAu7fqKpTh0U0HkFhK2+iaveAMW4ICj jtfceMFJChXuYjsrHgTz21FU3tOgYAEX9eIdiacLkw6oQT6p74gipuP6J+RsBVWI1CYF 8YnZZdWnFXw4H5oNMzPV5w6Zr96FGzAFl/2E1QfucVpO+aSTH1KwgNpR3gS8x5mCwn/l a9XM7AeiJq3+QdTP99byS47QoXlFmF3Nt8drjbMHMvIfMjgCfsXIbLMrj4EMwml+Lwlt RfaA==
Received: by with SMTP id nw5mr8736894pbb.159.1333649648001; Thu, 05 Apr 2012 11:14:08 -0700 (PDT)
Received: from ( []) by with ESMTPS id l1sm3872560pbs.34.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 11:14:07 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1716911pbb.31 for <>; Thu, 05 Apr 2012 11:14:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id pk8mr8767809pbb.99.1333649646446; Thu, 05 Apr 2012 11:14:06 -0700 (PDT)
Received: by with HTTP; Thu, 5 Apr 2012 11:14:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 5 Apr 2012 14:14:06 -0400
Message-ID: <>
From: Roman Shpount <>
To: Randell Jesup <>
Content-Type: multipart/alternative; boundary=047d7b10d0676e679904bcf2812b
X-Gm-Message-State: ALoCoQnyUbf4cWWgTGEKoWqybFDRMawNYV4I5rcn7bkrfa1YYSaegH4WXU95X+wqr8tUpYW+0fvH
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Apr 2012 18:14:09 -0000

On Thu, Apr 5, 2012 at 1:42 PM, Randell Jesup <>wrote:

> However, the bar for introducing Yet Another Key Exchange Protocol at this
> late date is pretty darn high, unless it's amazingly simple (and likely
> insecure or with other unwelcome properties) or a modification of an
> existing protocol.
> My issue is that patching DTLS-SRTP also comes with a fairly high cost now
and for the foreseeable future, since each of the patches will require an
independent interop. We either need to define and make all of those patches
a requirement, or each end point communicating with WebRTC will need to
verify if public-key exchange is supported, if ICE key exchange is
supported , and such. Each option provides a different key exchange path,
which would be a challenge for interop and provide a potential attack
vector (from my experience, protocols with a lot of complex scenarios
serving the same purpose are typically easier to break into).

> I strongly dislike SDES for a number of reasons - not solely that the key
> is exposed to the server (as in the server/app may be evil or hacked), but
> exposure of the keys will likely engender requirements from authorities to
> record keys to allow for later decryption of media. That's a direct threat
> to privacy (especially given many organizations willingness to provide
> access without legal orders).  Also, once those keys are recorded, the
> database of such keys becomes a tempting target in of itself (though it's
> only of use to someone tapping the raw packets, which limits the exposure -
> governments generally have no problem getting that; individuals have more
> problems (but can)).  And as mentioned earlier, it makes the servers much
> more of a target for hacking and requests/orders from authorities.

I dislike SDES for being a "somewhat secure" protocol. This is a very
dangerous territory where end user is under impression of being protected,
but reality is different. IMHO, in such situations it is better to have no
security at all, so that users know not to do anything they will regret.
Roman Shpount