Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP?

[Igor Faynberg <[e-mail]>]

+1

Igor

On 3/29/2012 7:58 AM, Iñaki Baz Castillo wrote:
> 2012/3/29 Fabio Pietrosanti (naif)<[e-mail]>:
>
>> That's true, but it's also true that the "rtcweb world" will strictly
>> inter-operate with the "sip world".
>>
>> It would be reasonable to expect that current existing PBX software
>> would evolve also with support for Rtcweb, to provide Web phone systems.
> Right, but it also reasonable to expect that those SIP PBX do
> implement some security, at least SDES-SRTP.
>
> NOTE: I do know you are not talking about allowing plain RTP in WebRTC ;)
>
>
>
>> In particular all opensource software will setup the path for the
>> adoption of the standard, as we know history will repeat.
>>
>> It appear me as natural behavior of diffusion of implementation, and for
>> that reason i see the need to "easily" inter-operate with the SIP world
>> is a key value point.
>>
>> Creating an incompatible "media format" would require a lot of more
>> effort because the "amount of compatibility testing to be done with
>> DTLS-SRTP will be significantly higher than SDES-SRTP" .
> I agree.
>
>
>
>>> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf
>> I would like to strongly argue against the SLIDE 3 statement that
>> "DTLS-SRTP meets RTCWEB's technical requirements" .
>>
>> DTLS-SRTP doesn't meet the RTCWEB's technical requirements because:
>>
>> - It does NOT provide inter-operation with existing SIP endpoints
>>
>> This is confirmed by the October 2011 SIPit data, with 80% of
>> participants supporting, with good interoperability, SDES but with 0%
>> supporting DTLS-SRTP .
>>
>> In order to try to "try to improve it's non-interoperability issue" the
>> DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT .
>>
>> To speaking about the fact that even EKT draft explain that:
>> " Today, Security Descriptions [RFC4568] is used for distributing SRTP
>>    keys in several different IP PBX systems and is expected to be used
>>    by 3GPP's Long Term Evolution (LTE). "
>>
>> http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1
>>
>> So:
>> - Internt is using SDES-SRTP
>> - 3GPP LTE is using SDES-SRTP
>> - WebRTC is going to use DTLS-SRTP
>>
>> I do not really see how we can rationally accept to follow this
>> different direction.
> Well, AFAIK the decision for WebRTC is one of the following options
> (assuming that plain RTP is not allowed, for which there was consensus
> yesterday in Paris):
>
> 1) Mandate DTLS-SRTP(-EKT?) implementation and dissalow SDES-SRTP.
>
> 2) Mandate DTLS-SRTP(-EKT?) implementation and allow SDES-SRTP (optional).
>
> 3) Mandate DTLS-SRTP(-EKT?) implementation and also SDES-SRTP.
>
>
> I vote for option (3) so WebRTC can *already* interop with well tested
> SDES-SRTP environments. Is option (3) good for you?
>
>
>
>
>> The argument that DTLS is *more secure* must face the reality that
>> no-one is using it and that SDES-SRTP is *widely diffused and
>> interoperable*.
>>
>> All Internet operators will have to introduce Protocol Gateway.
>> All mobile operators will have to introduce Protocol Gateway.
> It's worse than that. If you read slides 34 and 35 in
> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf, the
> "Media Gateway" MUST be also a *signaling* B2BUA (cannot be a proxy)
> since it needs to generate re-INVITE in one leg (for crypto key
> updates) !!
>
> I hope I will not need that annoying stuff in order to make WebRTC to
> interoperate with SIP networks (assuming SDES-SRTP in those SIP
> networks, of course).
>
>
>
>
>> So definitely the choice to go for DTLS-SRTP is imho a wrong choice,
>> against any rationale for the diffusion of WebRTC standard, introducing
>> artificially complexity where it may be possible to keep it simple.
> Worse, it's not just choosing a non tested standard, but creating a
> new specification. The slide 39 says:
>
> ------------------------
> Do part of DTLS handshake in ICE connectivity checks
> – draft-thomson-rtcweb-ice-dtls
> -----------------------
>
> So if that *new* spec is mandatory for WebRTC, then forget
> interoperability with any other network.
>
>
> Regards.
>