How is PFS relevant here? You won't be able to decrypt the traffic even in non-PFS modes.

As far as we see it PFS does not allow private keys. Other methods allows private keys which in turn will allow(if knowing the private key) decrypting and intercept the trafic.

I understand PFS being a great method for the consumer side

Do you control the clients?

Yes, we control the clients on our end, as well as the proxy. We will not however control the clients joining the meetings(e.g anyone on the internet)

To be sure, the choice of ciphersuites with PFS makes life harder for *all* potential eavesdropppers, even the good guys. To the extent that Chrome+WebRTC encourages or mandates such ciphers, though, they're in good company -- for example, we see similar decisions being made for TLS 1.3. I don't see the trend stopping any time soon.

Relying on a small set of the best ciphers helps keep implementations simple, which tends to mean more secure. Past events suggest that adding complexity in order to enable less capable ciphersuites will result in an exploitable security vulnerability with a punny name like I-Can-RTC-You.

I understand the necessities of network monitoring and intrusion detection, but changing protocols to facilitate MitM cannot be the answer.

I do understand the benefits for PFS, dont get me wrong. :) 

Based on your answer I interpret that we will not see any features allowing network monitoring and intrusion through this method.

What would be the recommendation for us(and other enterprises) going forward?

This is Working As Intended.

If you are content with watching how much traffic goes by, and allowing/denying traffic to certain destinations, there are some allowances in the standard for configuring a set of TURN proxies that can be configured by the admins; see the end of this section for a hint:

https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.4

In order to decrypt the traffic you need access to the session keys; it was a design choice to not provide any mechanism for such access.

Is your goal to limit WebRTC usage to approved sites, or do you want to actually collect unencrypted media to meet compliance requirements?

Can you explain how you make this work for WebRTC with non-PFS ciphers?

Our current compliance requirements say,among other things,that any trafic going IN towards our clients needs to be incercepted in order to guarantee no malicious code gets in to our network. We can do this today with e.g HTTPS

One solution to this) could be to limit webRTC to approved sites, but this will not work if the webRTC app/site is designed to allow e.g citizens(=we cannot trust/approv their devices) to interact with our employees. 

This is where we see great benefit of webRTC as it is plattform independent and requires no plugins. The downside is how to handle the security aspect?

Will this https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.4 help in this regard?

Echoing hta@ in #12. We're not planning any work on this.

In response to #14: No, IP location privacy controls won't help with interception of content. There have been discussions in W3C about having site configuration parameters that require all traffic to go (encrypted) via an organization-mandated proxy, but the consensus seemed to be that this wouldn't be surfaced in the API, so it's out of scope for the standards process.