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

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Wed, 28 Mar 2012 21:41:49 +0200

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.

For SDES-SRTP it's reported that:
**
All implementations supported SDES for SRTP key exchange.
Good interop with many different combinations of endpoints.
**

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.

Anyone can provide some very strong and valuable point about using
DTLS-SRTP (considering it's weak diffusion and incompatibility risks)
rather than standardizing the transport/communication of SDES key
exchange over a Web medium (HTTPS/HTTPS/Javascript)?

-- 
Fabio Pietrosanti
Founder, CTO

Tel: +39 02 911930893 + ext: 907
Mobile: +39 340 1801049
E-mail: [email-masked]
Skype: fpietrosanti
Linkedin: http://linkedin.com/in/secret

PrivateWave Italia S.p.A.
Via Gaetano Giardino 1 - 20123 Milano - Italy
www.privatewave.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Mar 2012 21:53:13 +0200

> countries with 25 distinct VoIP implementations.

Right, but this is rtcweb, not SIP.

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

> 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ñaki Baz Castillo
<[email-masked]>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 09:05:40 +0200

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

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

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

So it would provide an advantage for the *few vendor* supporting it,
practically introducing a *technological entrance barrier*.

This is a bad practice already see in other standard bodies.

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

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

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.

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.

-- 
Fabio Pietrosanti
Founder, CTO

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 13:58:06 +0200

> 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 ;)

> DTLS-SRTP will be significantly higher than SDES-SRTP" .

I agree.

> I do not really see how we can rationally accept to follow this

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?

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

> 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
<[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 29 Mar 2012 08:05:56 -0400

+1

Igor

On 3/29/2012 7:58 AM, Iñaki Baz Castillo wrote:
> 2012/3/29 Fabio Pietrosanti (naif)<[email-masked]>:
>

---

From: Randell Jesup <[email-masked]>
Date: Sat, 31 Mar 2012 02:37:18 -0400

On 3/29/2012 3:05 AM, Fabio Pietrosanti (naif) wrote:
>> 2012/3/28 Fabio Pietrosanti (naif)<[email-masked]>:
>>> Hi all,
>>>

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.

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

> that reason i see the need to "easily" inter-operate with the SIP world

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.

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

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

> participants supporting, with good interoperability, SDES but with 0%

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.

> DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT .

I wasn't particularly enthused about EKT.

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

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

> no-one is using it and that SDES-SRTP is *widely diffused and

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.

> 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
[email-masked]