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

[Randell Jesup <[e-mail]>]

On 3/29/2012 3:05 AM, Fabio Pietrosanti (naif) wrote:
> On 3/28/12 9:53 PM, Iñaki Baz Castillo wrote:
>> 2012/3/28 Fabio Pietrosanti (naif)<[e-mail]>:
>>> Hi all,
>>>
>>> i read that 80% of Sipit participant support SDES-SRTP but 0% support
>>> DTLS-SRTP  https://www.sipit.net/SIPit29_summary .
>>>
>>> At SIPit there were 34 attendees from 17 companies visiting from 12
>>> countries with 25 distinct VoIP implementations.
>>
>> Right, but this is rtcweb, not SIP.
>>
>>
>>
>>> I do not really see which is the rationale in making DTLS-SRTP mandatory
>>> while plain SRTP with SDES key exchange is already so well know and used.
>>
>> That's a good reason to *also* allow (and mandate) SDES-SRTP support
>> in WebRTC clients, much better than the interoperability with SIP
>> (again: this is rtcweb, not SIP world).
>
> That's true, but it's also true that the "rtcweb world" will strictly
> inter-operate with the "sip world".

The meaning of this statement is unclear.  If you mean "some rtcweb 
clients will connect to SIP gateways", or "some rtcweb clients will 
translate JSEP into SIP and send it to a SIP server", then that's true. 
  Some (many) rtcweb clients will never talk to any sip equipment.

> It would be reasonable to expect that current existing PBX software
> would evolve also with support for Rtcweb, to provide Web phone systems.

Which is no problem, the PBX can act as a WebRTC server, and provide the 
WebRTC JS app to the browsers, and also act as a gateway to SIP. 
There's no reason it can't terminate DTLS-SRTP for calls that connect to 
SIP devices.

> 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.

Being able to gateway to SIP and to PSTN are both useful abilities for 
certain (popular) classes of potential apps.  Note the earlier 
discussions showed that one requirement (consent) makes it hard (though 
not impossible) to directly connect WebRTC clients to PSTN gateways or 
to other SIP devices, even if you allow SDES.  If consent forces you 
through a gateway (or some device that knows WebRTC), DTLS-SRTP-only 
becomes a much smaller hump.

> 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" .
>
> So it would provide an advantage for the *few vendor* supporting it,
> practically introducing a *technological entrance barrier*.

Given the expectation that there will be a quality open-source version 
available (and Mozilla's implementation is of course open source), the 
barrier should be quite low.

> This is a bad practice already see in other standard bodies.
>
>>
>>
>>> Anyone can provide some very strong and valuable point about using
>>> DTLS-SRTP (considering it's weak diffusion and incompatibility risks)?
>>
>> Lot of recent threads about this topic in this maillist. But also
>> check a recent presentation (yesterday in IETF Pairs):
>>
>> 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

That is not an rtcweb requirement.  The only mention of SIP in the 
use-case and requirements doc is the ability to use SIP to provide 
federation (F27).

> This is confirmed by the October 2011 SIPit data, with 80% of
> participants supporting, with good interoperability, SDES but with 0%
> supporting DTLS-SRTP .

As discussed, this is an only partially-relevant fact. SIPit is 
self-selected; most devices there are not representative of average 
devices in use, and devices deployed may not enable options used in 
SIPit tests.

> 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 .

I wasn't particularly enthused about 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

I have no belief that LTE devices will ever connect directly to WebRTC 
devices directly (even if they're the same device); that's just not how 
they work.

> 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.
>
> I mean, we are discussing about a "new standard" that's based on "new
> technologies" rather than using existing, widely implemented technology.
>
> Do we really understand how much effort we are going to cause on the
> overall technological and security ecosystem by selecting DTLS-SRTP
> rather than SDES-SRTP?
>
> All US Federal Government will not be able to use WebRTC because NSA
> standardized SDES-SRTP for use in Classified communication:
> http://www.nsa.gov/ia/programs/mobility_program/index.shtml

They realize SDES is fundamentally insecure, and secure it by running it 
over a VPN link to their protected servers (and my understanding is that 
they consider even that a compromise).  And the devices must be TOTALLY 
locked down to any unencrypted network access.  These will not be using 
WebRTC anytime soon, under any circumstance.

> 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*.

Widely diffused and interoperable may be (mostly) true, though I'll tell 
you that probably 99.x% of *deployed* VoIP devices do not *use* SDES 
(even if they support it), so arguments about deployment numbers are 
mostly irrelevant.  Not totally irrelevant, of course.

> All Internet operators will have to introduce Protocol Gateway.

Due to the 'consent' requirement and other issues, this is likely 
anyways.  And who are the "internet operators" in your estimation?

> All mobile operators will have to introduce Protocol Gateway.

They will anyways I believe.

> All that subjects, if using just SDES-SRTP, would just need to "update
> the software they already use to run VoIP infrastructure" with no need
> to handle modification to the Media for Interworking.
>
> 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.

There certainly is an argument for SDES.  I don't agree about what it 
leads us to, but it's a reasoned argument.  However, many of your 
assertions here I would not accept.

-- 
Randell Jesup
[e-mail]