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

Randell Jesup <> Thu, 05 April 2012 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6987321F8702 for <>; Thu, 5 Apr 2012 10:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Z2EG-it+SrC for <>; Thu, 5 Apr 2012 10:45:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 94D9221F869D for <>; Thu, 5 Apr 2012 10:45:53 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1SFqkq-0004rg-GS for; Thu, 05 Apr 2012 12:45:52 -0500
Message-ID: <>
Date: Thu, 05 Apr 2012 13:42:21 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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 17:45:54 -0000

On 4/5/2012 9:53 AM, Roman Shpount wrote:
> On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <
> <>> wrote:
>     2012/4/5 Roman Shpount < <>>:
>      > On the more serious note, very few SIP end points offer working
>     ICE support.
>      > So, in a large sense, interop with them is not an option.
>     For me there is a BIG difference when a kind of B2BUA is required
>     (which involves signaling "transaction"). That's the barrier IMHO.
>     ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see:
> This picture is not entirely correct -- ICE Lite proxy should be on both
> SIP and Media path.

I agree.

>     The problem arises when media encrypt/decrypt is required, and evenr
>     more when a key update in RTP (like the DTLS EKT update) must be
>     converted into a signaling re-INVITE by a super Signaling+Media B2BUA:
> Not sure why key update needs to be converted into signaling if media is
> re-encrypted. Key updates on both sides of the proxy are independent.
> Such proxy can also change SDES-SRTP key on each re-INVITE initiated by
> either side, but apart from doing actual encryption/decryption,
> operation wise it should not be any different then ICE-Lite proxy.

I think he's assuming the gateway/B2BUA would not decrypt/re-encrypt, 
but would proxy keys from one protocol to the other.  That's obviously 
lower overhead, but a more complex protocol.  I have never assumed that 
proxying of keys would be the default.

>      > Out of the ones
>      > that do support ICE and SRTP, very few are actually connected
>     directly to a
>      > public internet. Most of them are connected to some sort of PBX
>     or an IP PBX
>      > type service. So, in reality you do not need to bridge every IP
>     phone with
>      > WebRTC.
>     That is a *very* limited scope of what WebRTC can provide. An IT
>     department should be able to deploy its own WebRTC infrastructure (a
>     Web+WebSocket server) within its "local" network, so browsers
>     accessing to such a local website share the network with SIP/XMPP
>     phones/devices/softphones.
>     Please don't imagine WebRTC and SIP interop as the communication
>     between two islands ;)
> I actually do imagine WebRTC/SIP interop as two islands. If we need to
> proxy media and convert Web+WebSocket into SIP this is a definition of
> island bridge for me.
>      > If a few PBX and hosted centrex vendors will add support for WebRTC
>      > required features, we will get compatibility with existing end
>     points.
>     Pure SIP proxies do exist. A PBX is not always needed, so again, SIP
>     world does not require to be "an island".
> Once  again, if SIP proxy is combined with media proxy, you can bridge
> SIP and WebRTC, even if DTLS-SRTP is used.
>      > To support the rest you will need to deploy some sort of gateway.
>     Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent
>     mails about SDES and DTLS).
> Once again, we still need a gateway to support ICE. If end point is
> adding ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.
>      > hurdle (I am trying to be politically correct here). WebRTC
>     enabled end
>      > points, on the other hand, will offer significant benefits to
>     traditional
>      > SIP phones, since they will allow development of higher quality
>     integrated
>      > real time communications services. I hope this will drive a much
>     quicker
>      > standard adoption.
>     The problem is that there is a *NEW* SRTP related spec for WebRTC:
>     Maybe it could also become a standard for SIP? I hope, but currently
>     it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a
>     island.
> Same as above.
> P.S. I actually do not like DTLS-SRTP, since it does not have a large
> installed base, comes with too many features, slows down call setup,
> will requirecomplex interop and such. At the same time I do not think
> that interop with legacy SDES-SRTP is a reason not to use it. I believe
> we should design a new key exchange method, that can be mapped to
> SDES-SRTP via signaling alone, addresses SDES-SRTP issues (transmitting
> keys over clear channel in signaling, replay of signaling) without
> introducing all the problems related to DTLS-SRTP. Any number of methods
> using public key based exchange over signaling and ICE should do the trick.

I find this argument more compelling than the previous one.  Call setup 
is certainly an issue (though I believe there are answers to it).  If 
there's a good alternative (and of course I remember the IETF 
presentation from a number of years ago that showed all 14 or so extant 
key-exchange methods, none of which was an obvious choice (witness all 
the problems actually ever agreeing on one, which is why SDES has become 
the lowest-common-denominator exchange, even though most don't actually 
use it).

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.

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.

Randell Jesup