Re: [Perc] PERC LIte

Hi Mo,

I would expect the app to decide the location of the js, the same as it 
is currently specified in the IdP solution:

    In order to communicate with the IdP, the user agent loads the IdP
    JavaScript from the IdP. The URI for the IdP script is a well-known
    URI formed from the domain and protocol fields, as specified in
    [RTCWEB-SECURITY-ARCH].

    The IdP may generate an HTTP redirect to another "https" origin, the
    browser must treat a redirect to any other scheme as a fatal error.

    The user agent instantiates an isolated interpreted context, a
    JavaScript realm that operates in the origin of the loaded
    JavaScript. Note that a redirect will change the origin of the
    loaded script.

    The realm is populated with a global that implements both the
    RTCIdentityProviderGlobalScope and WorkerGlobalScope [WEBWORKERS]
    interfaces.

    The user agent provides an instance of RTCIdentityProviderRegistrar
    named rtcIdentityProvider in the global scope of the realm. This
    object is used by the IdP to interact with the user agent.

Whether it is hosted by the MD/KD or another system is up to the 
service/app to decide, as long as the user knows who/what is he trusting.

Best regards
Sergio

On 25/05/2017 17:26, Mo Zanaty (mzanaty) wrote:
> 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 <perc-bounces@ietf.org <mailto:perc-bounces@ietf.org>> on 
> behalf of Sergio Murillo <sergio.garcia.murillo@gmail.com 
> <mailto:sergio.garcia.murillo@gmail.com>>
> Date: Wednesday, May 24, 2017 at 5:55 PM
> To: "perc@ietf.org <mailto:perc@ietf.org>" <perc@ietf.org 
> <mailto:perc@ietf.org>>
> 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 <perc-bounces@ietf.org <mailto:perc-bounces@ietf.org>> on 
>> behalf of Alexandre GOUAILLARD <agouaillard@gmail.com 
>> <mailto:agouaillard@gmail.com>>
>> Date: Wednesday, May 24, 2017 at 5:14 PM
>> To: Sergio Murillo <sergio.garcia.murillo@gmail.com 
>> <mailto:sergio.garcia.murillo@gmail.com>>
>> Cc: "perc@ietf.org <mailto:perc@ietf.org>" <perc@ietf.org 
>> <mailto:perc@ietf.org>>, Bernard Aboba <bernard.aboba@gmail.com 
>> <mailto:bernard.aboba@gmail.com>>
>> 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 
>> <sergio.garcia.murillo@gmail.com 
>> <mailto:sergio.garcia.murillo@gmail.com>> 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 regardsSergio
>>     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
>>>     <sergio.garcia.murillo@gmail.com
>>>     <mailto:sergio.garcia.murillo@gmail.com>> 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 Perc@ietf.org <mailto:Perc@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/perc
>>>         <https://www.ietf.org/mailman/listinfo/perc> 
>>>
>>     _______________________________________________ Perc mailing list
>>     Perc@ietf.org <mailto:Perc@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/perc
>>     <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
>> Perc@ietf.orghttps://www.ietf.org/mailman/listinfo/perc