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

["Ravindran, Parthasarathi" <[e-mail]>]

Cullen,

Nice to see the last few statements from legacy perspective.

<snip> Clearly the UI needs the ability of indicating in a secure way if the call is secure or not and the identity of who is at the other end of secure part. I can imagine Browser to Browser perhaps always being secure, I agree secure should be preferred to insecure where both are possible, but have a hard time imagining that we won't wish we had RTP for Browser to Legacy. 

Part of me believes that not having the option of using RTP in fallback legacy cases would be about equally insane to not supporting IPv4 and only doing v6. Sorry for all the nots.
</snip>

I look for configuration in browser for RTP traffic to get the user consent while sending/receiving the media.  

Apart from this, SRTP-DTLS is the only proposed standard RFC in IETF for current WebRTC security trust model. SRTP-SDES breaks the model by trusting JS app and ZRTP is the informational draft. I agree with you that implementing  SRTP-DTLS in middle box like SBC is possible if standard and market adopts. So, I'll prefer to have SRTP-DTLS as long as there is no alternative standard proposal or new proposal exists.  

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Cullen Jennings
>Sent: Thursday, January 12, 2012 9:20 AM
>To: Roman Shpount
>Cc: Randell Jesup; [e-mail]
>Subject: Re: [rtcweb] SRTP not mandatory-to-use
>
>
>Inline answer with my Cisco hat on .... I've mostly given up mention
>this because I sent it to RAI lists too many times before but ...
>
>On Jan 11, 2012, at 3:50 PM, Roman Shpount wrote:
>>
>> Can you name a single soft-phone, hard-phone, SBC, or gateway that
>currently supports DTLS-SRTP?
>
>Yes, Yes, Yes, and Yes respectively. For example, pretty much all the
>Cisco high end tele presence stuff with includes endpoints, conference
>bridges, protocol conversion devices etc supports it. The bulk of the
>platforms that are newer than 5 years old from Cisco support DTLS-SRTP.
>It interoperates with other vendors. We don't go to SIPIT because with
>this sort of stuff as it does not seem to be the best way to test it. We
>find that many of the vendors to test with at SIPIT are just getting
>going and are still trying to get their spiral loops to work. Don't get
>me wrong - I love SIPIT and strongly support it, but it's not the place
>to test everything. I've been told a lot of IMS systems can do MiKEY
>though I don't recall seeing a test of that at SIPIT. Different folks,
>different places.
>
>>
>> The reason I am asking is libsrtp, despite being widely used, is
>extremely buggy (last official release for instance crashes with GPF),
>and does not even provide full DES-SRTP implementation (no
>F8_128_HMAC_SHA1_8 support).
>
>I have no idea how much our internal version have diverged from the
>version you are using but the libSRTP is being used for a huge number of
>calls by enterprises, movements, and military systems. There's not a lot
>of bugs reported. I'm certainly not claiming there are bugs in any given
>piece of software but you can look at release notes of cisco products
>and see this is pretty stable. I realize this does not help much but
>DTLS-SRTP is not real complicated if you already have a good TLS stack
>and crypto engine - regardless of the quality of any given
>implementation, it should not be hard to make a good one.
>
>>
>> As far as DTLS (non-SRTP) implementations are concerned, can anybody
>provide an indication on how widely they are used? I know that OpenSSL
>supported DTLS for a while, but what commonly used software is using
>this?
>
>I note most the good deployed SSL VPN in the world are DTLS . Check out
>the market share of SSL VPN to traditional IPSec. DTLS is widely used.
>Heck, at the next IETF, just check out the amount of DTLS traffic coming
>from IETF participants.
>
>>
>> Also, what would be the impact of adding DTLS to SBC? It would be
>interesting to hear from SBC implementers before decision is made.
>
>I've been on the design and implementation team for multiple SBCs - I
>was even a co-founder of an SBC company. But it's really easy to figure
>out - you don't need to know much about SBC - it more or less the same
>as it would be for any UA.
>
>Lets say you have nice SBC that will do 10,000 concurrent sessions.
>These are not cheap. If you are doing RTP on one side and DTLS-SRTP on
>the other side of each call. Lets just use a pessimistic estimate of
>average call duration of 3 minutes. So this device is doing 10000 / 3 /
>60 = 55 session setups per second. The expensive part of this is the RSA
>private key operation. A single core on the crappy computer I am sending
>this email from does about 850 rsa1024 private key operations on a
>single core. Try out your machine with "openssl speed rsa1024". It
>roughly equivalent to two private key ops - So a big SBC needs 110 per
>second under pessimistic assumption and a small CPU can do 850. As you
>can imagine, an SBC like that is using some pretty beefy processors -
>they impact of the DTLS is often hard to measure it is so little. The
>amount of processing you need to process the all the SIP for a single
>call greatly exceeds the amount of processing to set up the DTLS
>connection. D  TLS also requires much less per connection state than SIP
>although SBC are typically more constrained by CPU than memory.
>
>
>>
>> How many additional round trips does DTLS require for connection
>setup?
>
>A drop in the bucket compared to ICE :-) It depends on how you assume
>the ICE ends up going and if you do early media or not. There are many
>ways to overlap lots of this processing to minimize impact so it a
>slightly hard question to answer but if you draw some call flows with
>ICE, you will probably agree with my sort of flip "drop in the bucket"
>answer.
>
>> Are we planning to support certificate validation?
>
>Uh, don't think I am following you here - it's just a dummy X.509 record
>to carry the public keys. There's no CA to validate it at.
>
>> _____________
>> Roman Shpount
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>Thought I sound like I might be arguing for DTLS-SRTP to be the only
>thing - I'm not sure what I think. I want to see what the whole security
>systems looks like. If the weakest link is weak, well no point in making
>other links super strong.  Clearly the UI needs the ability of
>indicating in a secure way if the call is secure or not and the identity
>of who is at the other end of secure part. I can imagine Browser to
>Browser perhaps always being secure, I agree secure should be preferred
>to insecure where both are possible, but have a hard time imagining that
>we won't wish we had RTP for Browser to Legacy.
>
>Part of me believes that not having the option of using RTP in fallback
>legacy cases would be about equally insane to not supporting IPv4 and
>only doing v6. Sorry for all the nots.
>
>
>
>
>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb