Re: [Perc] PERC LIte

["Mo Zanaty (mzanaty)" <[e-mail]>]

Hi Sergio,

I was not thinking of compromised js (yet), just the real webrtc service js. What origin do you expect for this js? I expect the MD provider, or maybe KD.MD subdomain (e.g. ietf.webex.com) where the MD provider still controls the js while the KD subdomain is just for vanity and demux not operational control. But seems like you expect the KD provider for this js.

What do you mean by "independent context" below? Are you referring to the IdP Proxy within the browser? So this key object would be restricted to the IdP Proxy and not accessible from the real webrtc js or DOM?

Thanks,
Mo


From: Perc <[e-mail]<mailto:[e-mail]>> on behalf of Sergio Murillo <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 24, 2017 at 5:55 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Perc] PERC LIte

Hi Mo,

The key in JS is just for the media cencryption, DTLS/SRTP is setup normally on top, so it is in no way less secure than current DTLS/SRTP.

If JS is compromised, and an attacker gets the key, he will still be unable to access the media data as is encrypted HBH by DTLS. To gain access to the media, he would need to get the key AND break HBH DTLS.

Also, if JS is compromised, PERC will be defeated completely (any solution) as it could clone all the media streams and sent it to a rogue MD with a different PC.

To prevent that is why IdP was introduced into WebRTC, and a similar solution could be done for setting the key (just run a js script from the KD on an independent context and restrict the usage of that stream to the required identity).

Anyway, I understand this will be a sensible topic, so I am willing to discuss this in detail.

Best regards
Sergio



On 24/05/2017 23:42, Mo Zanaty (mzanaty) wrote:
Keys in JS app signaling/APIs??? Have we come full circle back to SDES???

Seems like PERC lite would weaken not strengthen the security of DTLS-SRTP / WebRTC apps, if JS can inject keys to ignore DH, defeat PFS, etc.

Confused,
Mo

From: Perc <[e-mail]<mailto:[e-mail]>> on behalf of Alexandre GOUAILLARD <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 24, 2017 at 5:14 PM
To: Sergio Murillo <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Bernard Aboba <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Perc] PERC LIte

bernard,

Good point.

i'm discussing with peter T, and proposal for webrtc WG and ORTC CG API extensions are coming your way this week.  Sergio did it at the PeerConnection level while peter is advocating an Api at the RTPSender/Receiver level. Of course, the crypto-algorithm needs to be an input variable as well.

On Thu, May 25, 2017 at 5:46 AM, Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>> wrote:
Hi Bernard,

Yes, the example API is just the lazy approach I have taken on my modified chromium, hardcoding the key to AES-GCM 256 so I didn't have to add an object to the IDL and worry about how to retrieve later on the c++ code.

The API should allow to set the key and look more like:


const pc = new RTCPeerConnection({

mediaCrypto : {

key : 'VEhJUyBJUyBUSEUgMzIgS0VZIFdJVEggMTIgU0FMVCBET1VCTEUgUEVSQyE=',

suite  : 'AEAD_AES_256_GCM'

}

}); Anticipating the security comments, I don't expect that to be the final API for WebRTC, which IMHO should be a similar mechanism as the one in place for IdP (or even integrated with it), but I feel that that discussion should take place on the RTCWeb group and not here. Best regards Sergio
On 24/05/2017 19:56, Bernard Aboba wrote:
Thanks for posting this.
Question:  In terms of API support, how is the crypto-algorithm specified?  So far, the proposed API just has the key.
On Wed, May 24, 2017 at 10:11 AM, Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>> wrote:

Hi all again,

Also to start the discussion about 5), I would like to introduce again my proposal for a "PERC Lite" approach.

The main objectives and key points of this proposal are:

  *   Minimum viable PERC implementation
  *   Minimize impact on both endpoints and MD
  *   OHB is carried in the RTP payload (Encrypted Payload Header).
  *   No changes to the DTLS/SRTP code/api/standards
  *   No RTP E2E Header extensions
  *   RTX/FEC/RED is supported HBH without any change to current standards/implementations.

Best regards

Sergio

_______________________________________________ Perc mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/perc

_______________________________________________ Perc mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/perc
--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard<http://sg.linkedin.com/agouaillard>

  *

_______________________________________________
Perc mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/perc