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

[Iñaki Baz Castillo <[e-mail]>]

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.

-- 
Iñaki Baz Castillo
<[e-mail]>