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

[Randell Jesup <[e-mail]>]

On 1/3/2012 7:55 AM, [e-mail] wrote:
> Hi,
>
> Randell Jesup wrote:
>>
>> I'll also note a 180MHz MIPS processor is very slow by modern standards.
>>   Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM
>> (and that's arguably too low, perhaps significantly too low).
>>
>
> Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connectivity, even the low-end ones seem to have at least 600 MHz ARM. Anything that I could imagine running WebRTC, in terms of real products, will have an even faster CPU.
>
> Nokia has had phones with SIP and SRTP for several years, so I doubt that will be an issue. It's all the other stuff that WebRTC will need that will be much more challenging.

I chose 300MHz because that's the speed of the ARM in a first-generation 
DaVinci and some of the older OMAPs I believe.  Agreed, not really 
current devices likely to get webrtc - though support for lower-spec 
devices does enable people wanting to build really inexpensive web 
devices (wired or wireless).  And lower overhead also means lower 
battery use (though Justin reminds me that the CPU isn't the limiting 
factor here usually; it's the display and wireless link).

I should note that audio SRTP overhead isn't really the issue; it's the 
overhead for encrypting/decrypting far larger streams of video, and the 
SRTP overhead is (mostly) proportional to bitrate, so large resolution 
and/or low-compression streams will use more overhead.

Note: while I'm discussing nits here, I am in overall favor of 
SRTP-required, if for no other reason than to head off bid-down attacks. 
  I'd love to have the option of not using it in very specific scenarios 
(PSTN gateway, internal corporate network or one with an PBX that 
doesn't support a keying scheme we do), but I've yet to see a solution 
for those that doesn't hurt other use-cases.  (And I've tried to find a 
way.)

(And yes, SRTP doesn't help you much if you're MITM'd - see ekr's 
identity stuff & BrowserID for that.)

-- 
Randell Jesup
[e-mail]