Subject: [rtcweb] SDES-SRTP as a platform for multiple key management

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 21:53:30 +0200

Hi all,

i've been thinking that one of the very interesting elements about the
support of SDES-SRTP, is that, other than providing compatibility with
existing telephony ecosystem, it may allow the implementation of custom
key managegement systems.

Basically if WebRTC would introduce support for SDES-SRTP and w3c would
define API to handle SDES SDP call keys, it would become possible to
further implement in Javascript additional key management systems.

For example someone may implement a javascript application to be
provided from an https source or browser extension additional to
implement OpenPGPJS based identity verification (http://openpgpjs.org/)
or integration with DH based key exchange
(https://github.com/kaepora/cryptocat/).

So basically a side-effect of introducing SDES-SRTP, could be to let
HTML5 application developers, to effectively be able to implement custom
security mechanisms for voice applications.

-- 
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 23:23:07 +0200

Hi,

While I'm in favour of SDES I don't believe this is a particularly strong argument. To provide any real security gain, any additional signing or encryption that you may think of has to be performed outside of the webapp's control.

Regards,

Oscar

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fabio Pietrosanti (naif)
> Sent: Thursday, March 29, 2012 9:54 PM
> To: <[email-masked]>
> Subject: [rtcweb] SDES-SRTP as a platform for multiple key management
> 
> Hi all,
> 
> i've been thinking that one of the very interesting elements 
> about the support of SDES-SRTP, is that, other than providing 
> compatibility with existing telephony ecosystem, it may allow 
> the implementation of custom key managegement systems.
> 
> Basically if WebRTC would introduce support for SDES-SRTP and 
> w3c would define API to handle SDES SDP call keys, it would 
> become possible to further implement in Javascript additional 
> key management systems.
> 
> For example someone may implement a javascript application to 
> be provided from an https source or browser extension 
> additional to implement OpenPGPJS based identity verification 
> (http://openpgpjs.org/) or integration with DH based key 
> exchange (https://github.com/kaepora/cryptocat/).
> 
> HTML5 application developers, to effectively be able to 
> implement custom security mechanisms for voice applications.
> 
> --
> Fabio Pietrosanti
> Founder, CTO
> 
> www.privatewave.com _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Fri, 30 Mar 2012 09:30:00 +0200

Hi Oscar,

i totally agree that it's not one of the stronger argument, however when
a technology is open and will let third party to work on it, third party
WILL work on it applying their creativity.

I am confident that we would see inside the crypto-nerds environments a
lot of JS-based key management extensions to extend SDES with customer
crypto semantic.

Then, for security purpose, this must be done outside the webapp, and
this can be done in many way such as:
- Javascript written browser plugin
- Javascript pinned to Browser Cache
- Locally loaded javascript

Javascript encryption is the next frontieer for Web security and there's
a lot of work from that side also from browser manufacturer (DOMCrypt,
JS-signing, JS RNG, etc) to provide secure crypto.

We are in 2012 and if we speak of an argument that Browser+Crypto we
just cannot not consider that Javascript will have a role in that
context, one way or another way.

Fabio