Subject: [rtcweb] Support of SDES in WebRTC

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 10:54:28 +0200

On the topic of SDES vs DTLS-SRTP a very nice analysis has been done on:
http://www.potaroo.net/ietf/idref/draft-ohlsson-rtcweb-sdes-support/

Considering how vague are the security implementation consideration of
DTLS-SRTP and how widely diffused in SDES-SRTP, i'm wondering whenever
we should not mandate the use of SDES-SRTP.

That way we would be able to see:

- All implementation will start with SDES (simpler and quicker)
- For who want enhanced security, greater implementation and
interoperability complexity, implement also DTLS-SRTP

But for the industry a full cycle of:
- Implementation
- Stabilization
- Interoperability

for DTLS-SRTP (that nobody use) may require from 2 up to 4-5 years of time.

If we goes for SDES-SRTP by default, as early choice, probably within
1-2 years at maximum we can expect the overall technological ecosystem
to be stable and interoperable.

Because it will be built on top of existing stable framework.

We may save dozens millions of USD of investments costs for the industry
and gain some hundreds millions of users year in advance, just because
we would save several years of time.

I think that those consideration are valuable enough to strongly
consider arguments in making SDES-SRTP a preferred, mandatory
implementation for WebRTC.

-- 
Fabio Pietrosanti
Founder, CTO

Tel: +39 02 85961748 (direct)
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: Oscar Ohlsson <[email-masked]>
Date: Thu, 29 Mar 2012 15:19:11 +0200

Hi Fabio,

My assumption has always been the following:

- DTLS-SRTP is the default
- DTLS-SRTP + identity can be turned on via the JavaScript API if the webapp wishes to do so
- SDES can be turned on by a manipulated SDP offer/answer provided the entire webapp was retrieved over HTTPS

BTW I'm also in favor of _only_ allowing the SRTP NULL encryption algorithm in browser debug/developer mode.

Regards,

Oscar Ohlsson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fabio Pietrosanti (naif)
> Sent: Thursday, March 29, 2012 10:54 AM
> To: <[email-masked]>
> Subject: [rtcweb] Support of SDES in WebRTC
> 
> Considering how vague are the security implementation 
> consideration of DTLS-SRTP and how widely diffused in 
> SDES-SRTP, i'm wondering whenever we should not mandate the 
> use of SDES-SRTP.
> 
> 1-2 years at maximum we can expect the overall technological 
> ecosystem to be stable and interoperable.
> 
> We may save dozens millions of USD of investments costs for 
> the industry and gain some hundreds millions of users year in 
> advance, just because we would save several years of time.
> 
> I think that those consideration are valuable enough to 
> strongly consider arguments in making SDES-SRTP a preferred, 
> mandatory implementation for WebRTC.
> 
> --
> Fabio Pietrosanti
> Founder, CTO
> 
> www.privatewave.com _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Mar 2012 15:54:35 +0200

> - SDES can be turned on by a manipulated SDP offer/answer provided the entire webapp was retrieved over HTTPS

[BA[ Unless SDES is indicated as supported in the SDP blob provided by createAnswer(), "manipulating" the SDP offer to add it probably isn't a good idea. 

That's one reason why we need understand the precise semantics of createAnswer().  To (mis)quote Christer:  does createAnswer() indicate a (subset) of what the browser can do, what it would prefer to do, or all that it is capable of doing?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 17:33:26 +0200

> - SDES can be turned on by a manipulated SDP offer/answer provided the entire webapp was retrieved over HTTPS

Please check this mail in which I explain that retrieving the web app
by means of HTTPS means nothing:

  http://www.ietf.org/mail-archive/web/rtcweb/current/msg03914.html

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 18:56:32 +0200

>   http://www.ietf.org/mail-archive/web/rtcweb/current/msg03914.html

Yeah, but that's an issue that relate to general web and Javascript
trust issue.

Javascript trust issue is a problem that's already discussed and
evaluated in other area and context of w3c, there are several solutions
on-going.

This kind of issue is the same considered for Javascript encryption.

Trusted javascript can be verified/loaded today trough plug-ins and by
trusting the 'application delivery source', so that's not an issue.

>From 0 up to 100 of security with Javascript you can stay at 0 or reach
100, depending on the way you deploy and use web.

Imho making SDES SDP offer/answer available to Javascript it's a great
achievement as it will be able to unlock the creativity of the
technological ecosystem.

People will probably manipulate SDP, sign it, re-encrypt it, pass it
trough OOB channels via CORS or as many other options we may envision.

-- 
Fabio Pietrosanti
Founder, CTO

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 19:27:08 +0200

> evaluated in other area and context of w3c, there are several solutions

It's nice to know that the issue is already being addressed.

> achievement as it will be able to unlock the creativity of the

Sure, I agree.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Oscar Ohlsson <[email-masked]>
Date: Thu, 29 Mar 2012 23:13:30 +0200

Hi,

That's why I wrote "the entire webapp" below. If it was not clear I meant that the

- main HTML page
- all external CSS files, JavaScript files, images, etc 
- all XmlHttpRequests
- all WebSocket connections

are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content). 

/Oscar

> From: Iñaki Baz Castillo [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2012 5:33 PM
> To: Oscar Ohlsson
> Cc: Fabio Pietrosanti (naif); <[email-masked]>
> Subject: Re: [rtcweb] Support of SDES in WebRTC
> 
> > - DTLS-SRTP + identity can be turned on via the JavaScript 
> API if the 
> > webapp wishes to do so
> > - SDES can be turned on by a manipulated SDP offer/answer 
> provided the 
> > entire webapp was retrieved over HTTPS
> 
> Please check this mail in which I explain that retrieving the 
> web app by means of HTTPS means nothing:
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 23:53:39 +0200

> are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content).

Good point.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 29 Mar 2012 14:59:03 -0700

> are protected with TLS. This is obviously verifiable and it's a feature supported by all modern browsers (no mixed content).

Even this is insufficient.

First, even if it is in principle possible to provide adequate
cryptographic security inside the JS applications a great many of them
won't (for many reasons). We can't eliminate inconsistency in the security
of webrtc applications— but we can certainly make it hard to go below
a certain level of security especially by accident.   In particular,
if JS applications provide only authentication services (e.g. by giving
them access to hashes of the ephemeral session keys, but not the session
keys themselves) then a cryptographically-incompetent application can
only fail the user by failing to provide the authentication it promised
over and above the platform baseline capability.

With HTTPS applications are currently free to do dumb things (mixed
content, esp scripts) but at least the browser can detected this and
alerts the user with varying degrees of loudness.  In a SDES/SRTP
world the browser will not be generally able to detect insecure
behavior by applications— creating something of a lemon market
for webrtc based application security. As a resutl its important to
narrow the amount of insecurity possible.

This is effectively a repeat of the arguments against supporting
plaintext. If plaintext is supported it will be commonly used because it's
easiest, because users can't easily tell how insecure their connection
is, and because users often don't have a good feel for the threat model
(e.g. things like firesheep were _very_ surprising to most people)...
Because of this the platform should provide the highest level of security
that can reasonably be provided in the platform, and that means (among
other things) perfect-forward-secrecy— while allowing applications to
add things like authentication on top (because while strong ephemerally
keyed crypto can be done very low in the stack, meaningful authentication
needs layer-7/8 hooks).

There is also the application/library split issue— if a vulnerability
is found in a common negotiation procedure what secures users
better? Updating a few easily identified browsers / softphone apps?
or a much larger base of webapps, many of which would be run by security
ignorant/clueless people?  (and at least if the webserver is clueful but
the client operator is not the app could yell about the insecure client,
the other way around doesn't work as well).  —   Really, cryptographic
negotiation is not properly an application feature, it belongs lower in
the stack, and many applications that roll their own crypto have done
a poor job of it.

It's also inadequate on purely technical grounds: Javascript provides
no mechanism for working with mlocked memory,  no mechanism to ensure
that garbage collected data gets zeroized.  Your crypto app in JS could
easily have its long term keying material pulled out of free ram by
malware long after it runs, or pulled off the disk from swap.
The breakneck pace of fancy JIT systems makes it seem unlikely to me
that javascript will provide for that any time soon.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 23:29:58 -0400

> that javascript will provide for that any time soon.
I guess what you are saying (and I believe everybody on this list agree) is
that SDES-SRTP in combination with JavaScript signaling negotiation does
not and cannot provide any meaningful security above preventing simple
network sniffing.
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Mar 2012 17:44:31 -0400

> Even this is insufficient.

[long nice analysis of security in JS vs in the stack deleted]

>  Really, cryptographic

I rarely do this sort of reply for obvious reasons, but:

I agree!  :-)

-- 
Randell Jesup
[email-masked]