Subject: [Perc] PERC LIte

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 24 May 2017 19:11:50 +0200

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 May 2017 10:56:11 -0700

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 <
[email-masked]> wrote:

> Hi all again,
>
> Also to start the discussion about 5), I would like to introduce again my
> proposal for a "PERC Lite" approach.
>
>    - 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
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 24 May 2017 21:46:33 +0200

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 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all again,
>
>     Also to start the discussion about 5), I would like to introduce
>     again my proposal for a "PERC Lite" approach.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/perc>
>
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 25 May 2017 07:14:16 +1000

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 <
[email-masked]> 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.
>
> * const pc = new RTCPeerConnection({ mediaCrypto : { key :
> 'VEhJUyBJUyBUSEUgMzIgS0VZIFdJVEggMTIgU0FMVCBET1VCTEUgUEVSQyE=', suite  :
> 'AEAD_AES_256_GCM' } });*
>
> 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
>
>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 24 May 2017 21:42:38 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Alexandre GOUAILLARD <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 24, 2017 at 5:14 PM
To: Sergio Murillo <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bernard Aboba <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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.

mediaCrypto : {

key : 'VEhJUyBJUyBUSEUgMzIgS0VZIFdJVEggMTIgU0FMVCBET1VCTEUgUEVSQyE=',

}

});

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

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi all again,

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

  *   RTX/FEC/RED is supported HBH without any change to current standards/implementations.

Best regards

Sergio

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

_______________________________________________
Perc mailing list
[email-masked]<mailto:[email-masked]>
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>

  *

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 25 May 2017 07:51:01 +1000

you re' right, those API are not to be exposed to the pass-by internet.

<rant> Alas, as Martin and ear stated in 2014 when asking about making the
screensharing mechanism consistant across browsers, "it's a security
matter, and the security matters are the prerogative of the browser
vendors". So we might end up with extensions in chrome, and profile in
Firefox. </rant> But normal webpages' JS won't have the capacity to set
keys.

The security aspects are not forgotten, and were/are included in the
proposal that was circulated to Chrome and Mozilla teams back in November
last year.

I just wanted to give an heads-up to Bernard about it coming his way in the
immediate future.

;-)

On Thu, May 25, 2017 at 7:42 AM, Mo Zanaty (mzanaty) <[email-masked]>
wrote:

> 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 <[email-masked]> on behalf of Alexandre GOUAILLARD <
> [email-masked]>
> To: Sergio Murillo <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Bernard Aboba <
> [email-masked]>
>> add an object to the IDL and worry about how to retrieve later on the c++
>> code.
>>

   -

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 25 May 2017 07:51:40 +1000

also, it would only be the E2E keys. so it does not change anything to
existing DTLS-SRTP / webrtc mechanisms.

On Thu, May 25, 2017 at 7:51 AM, Alexandre GOUAILLARD <[email-masked]

> I just wanted to give an heads-up to Bernard about it coming his way in
> the immediate future.
>
> ;-)
>
>> 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
>>
>>> 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.
>>>

   -

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 24 May 2017 23:55:28 +0200

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:
> DTLS-SRTP / WebRTC apps, if JS can inject keys to ignore DH, defeat 
> PFS, etc.
>
> Confused,
> Mo
>
> From: Perc <[email-masked] <mailto:[email-masked]>> on 
> behalf of Alexandre GOUAILLARD <[email-masked] 
> <mailto:[email-masked]>>
> To: Sergio Murillo <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Bernard Aboba <[email-masked] 
> <mailto:[email-masked]>>
> 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 
> 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 
>     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.
>
>     });* 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
>>         Also to start the discussion about 5), I would like to
>>         introduce again my proposal for a "PERC Lite" approach.
>>
>>         _______________________________________________ Perc mailing
>>         list [email-masked] <mailto:[email-masked]>
>     _______________________________________________ Perc mailing list
> sg.linkedin.com/agouaillard <http://sg.linkedin.com/agouaillard>
>
>  *
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 25 May 2017 15:26:41 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Sergio Murillo <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 24, 2017 at 5:55 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

Confused,
Mo

bernard,

Good point.

mediaCrypto : {

}

}); 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi all again,

Best regards

Sergio

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

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

  *

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 25 May 2017 17:36:32 +0200

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
>
>
> behalf of Sergio Murillo <[email-masked] 
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> solution) as it could clone all the media streams and sent it to a 
> rogue MD with a different PC.
>
>>     });* 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
>> [email-masked]://www.ietf.org/mailman/listinfo/perc

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 May 2017 12:36:51 -0400

Hey Sergio,

Emil said on the call yesterday that this has been implemented in Chrome.
Is your patch some place public?  It might help folks understand your
proposal here if they could see the code.

Thanks,
--Richard

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 25 May 2017 18:51:20 +0200

Hi Richard,

Yes, it is public:

https://github.com/agouaillard/perc-webrtc

We used chrome 57 as the base for our changes, here are the full changes

https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master

Note that most of the changes are due to the implementation of frame 
marking header extension, supporting variable length header extensions 
and passing the key from the peerconnection to the rtp sender/receivers.

The modifications required to encrypt/decrypt the media are in

modules/rtp_rtcp/source/rtp_receiver_audio.cc 
<https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-c5cf31c9ff685c103d9f0c2f406a55f5>
https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-c5cf31c9ff685c103d9f0c2f406a55f5
modules/rtp_rtcp/source/rtp_receiver_video.cc 
<https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-75f36e7452edf5ba9231d5817a14f7bb>
https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-75f36e7452edf5ba9231d5817a14f7bb
modules/rtp_rtcp/source/rtp_sender_audio.cc 
<https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-3ca482263cebacd292343743d732bd3b>
https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-3ca482263cebacd292343743d732bd3b
modules/rtp_rtcp/source/rtp_sender_video.cc 
<https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-a1231f68963ac881e630a460df9fe972>
https://github.com/agouaillard/perc-webrtc/compare/275c7b012d0d3f08d8ba7360784d731a62d32318...master#diff-a1231f68963ac881e630a460df9fe972

The class used for encrypt/decrypt an rtp packet given the shared key is:
https://github.com/agouaillard/perc-webrtc/blob/0fc30dba17f65d66d65a95b2664654a958e6c3f8/modules/rtp_rtcp/source/media_crypto.cc

Note that no code for FEC/RTX/RED or DTLS has been modified at all. 
Also, we required no modifications on Jitsi/master except a minor bug 
fix on framemarking handling.

Best regards
Sergio

On 25/05/2017 18:36, Richard Barnes wrote:
> Hey Sergio,
>
> Emil said on the call yesterday that this has been implemented in 
> Chrome.  Is your patch some place public?  It might help folks 
> understand your proposal here if they could see the code.
>
> Thanks,
> --Richard
>
> On Wed, May 24, 2017 at 1:11 PM, Sergio Garcia Murillo