Re: [Perc] PERC LIte

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

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>

  *