Re: What would you like to see in WebRTC next? A low-level API?

Den 29. jan. 2018 09:43, skrev Sergio Garcia Murillo:
> On 28/01/2018 18:05, Harald Alvestrand wrote:
>> Den 26. jan. 2018 19:29, skrev Cullen Jennings (fluffy):
>>>
>>>> On Jan 25, 2018, at 5:45 AM, Emil Ivov <emcho@jitsi.org
>>>> <mailto:emcho@jitsi.org>> wrote:
>>>>
>>>>
>>>> A way to set e2e encryption keys (for something like SRTP double)
>>>> would be great!
>>>>
>>>> Obviously doing that from the regular API wouldn’t make much sense,
>>>> but giving that option to browser extensions would be nice!
>>>>
>>> Let me generalize this a bit … I think the WG thinking about what APIs
>>> it might have for browser extensions as well as what API for JavaScript
>>> would be a good thing. This keying is one, codecs is another, and
>>> handling the policy around what IP addresses get disclosed is another.
>>>
>>>
>> Remember that exposing the session keys to Javascript means that anyone
>> who can get to your Javascript context can decrypt your communications,
>> and that anyone who's able to get or set your public/private keypair can
>> impersonate you in a man-in-the-middle attack.
>>
>> Of course anyone who can get at your raw communication can get at your
>> communication anyway, so this might not seem like a big deal. But think
>> through the security model before you ask to set keys.
> 
> If we are talking about exposing e2e crypto keys in the context fo
> double/perc-lite, there are two crypto context, the end to end and the
> hop by hop one.
> 
> Setting just the e2e crypto key in javascript will not have any impact
> on the hoop by hoop encryption (which will be the normal DTLS/SRTP one),
> so there is no security impact.

Well, it does weaken the security guarantee that the MCU won't be able
to decrypt your traffic (the MCU will get your e2e key if it can collude
with something that has access to your Javsacript), which is kind of a
security impact.

 Also, in my original mail I proposed
> that we could investigate how to couple this mechanism with the identity
> one, so even if the javascript is compromised there is no way of doing a
> man in the middle attack.

That might be feasible - that there might be a way of leveraging the
identity mechanism to generate and set keys without ever exposing them
to Javascript, just like we'd do for RSA/ECDSA keys.

Identifying such a key handling mechanism (and data encryption/signing
interfaces that use them) might be something useful for WebCrypto to
address (if it doesn't already).

> 
> Best regards
> Sergio
> 
>

Received on Monday, 29 January 2018 10:47:26 UTC